accumulo-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From els...@apache.org
Subject svn commit: r1492032 - /accumulo/site/branches/git/content/git.mdtext
Date Wed, 12 Jun 2013 01:33:58 GMT
Author: elserj
Date: Wed Jun 12 01:33:58 2013
New Revision: 1492032

URL: http://svn.apache.org/r1492032
Log:
ACCUMULO-1498 Adding in section on merging from mailing list discussion.

Modified:
    accumulo/site/branches/git/content/git.mdtext

Modified: accumulo/site/branches/git/content/git.mdtext
URL: http://svn.apache.org/viewvc/accumulo/site/branches/git/content/git.mdtext?rev=1492032&r1=1492031&r2=1492032&view=diff
==============================================================================
--- accumulo/site/branches/git/content/git.mdtext (original)
+++ accumulo/site/branches/git/content/git.mdtext Wed Jun 12 01:33:58 2013
@@ -261,6 +261,32 @@ suggested to impose a "hierarchy" in whi
 with `feature/${USERNAME}/${JIRA_ISSUE}-description`. This is another decision
 that requires input from all developers who care.
 
+### Changes which affect multiple versions (a.k.a. merging)
+
+Merging can be a very confusing topic for users switching to Git, but it can be
+summarized fairly easily.
+
+0. Precondition: choose the right branch to start! (lowest, applicable version
+for the change)
+
+1. Get your changes fixed for that earliest version.
+
+2. Switch to the next highest version which future minor versions will be
+released (non-EOL major release series).
+
+3. `git-merge` the branch from #1 into the current.
+
+4. Treat your current branch as the branch from #2, and repeat from #2.
+
+When merging changes across major releases, there is always the possibility of
+changes which are applicable/necessary in one release, but not in any future
+releases, changes which are different in implementation due to API changes, or
+any number of other cases. Whatever the actual case is, the developer who made
+the first set of changes (you) is the one responsible for performing the merge
+through the rest of the active versions. Even when the merge may results in a
+zero-length change in content, this is incredibly important to record as you are
+the one who knows that this zero-length change in content is correct!
+
 ## Release Management
 
 Releases, although not a day to day task, have their own unique steps which are



Mime
View raw message