lucene-java-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Lucene-java Wiki] Trivial Update of "SvnMerge" by SteveRowe
Date Tue, 11 Jan 2011 23:02:17 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Lucene-java Wiki" for change notification.

The "SvnMerge" page has been changed by SteveRowe.
http://wiki.apache.org/lucene-java/SvnMerge?action=diff&rev1=2&rev2=3

--------------------------------------------------

  = SVN Merge =
  
- To backport to `branch_3x/` a change you have committed to `trunk/`, change directory to
the top level directory in your `branch_3x/` working copy, and issue this command:
+ To backport a change you have committed on `trunk/` to `branch_3x/`, go to the top level
directory in your `branch_3x/` working copy, and issue this command:
  {{{
  svn merge -c XXXXXX https://svn.apache.org/repos/asf/lucene/dev/trunk
  }}}
@@ -19, +19 @@

  
  Subversion tracks merges using a property called `svn:mergeinfo`.  Detailed info on the
implementation here: http://www.collab.net/community/subversion/articles/merge-info.html
  
- In the Lucene/Solr source tree, as a result of Subversion's `svn:mergeinfo` implementation,
paths that were conflicted and had to be merged below the top level directory began to accumulate
revisions for every single merged commit, even though the commit did not directly change these
paths.  This is because paths with a `svn:mergeinfo` value that differs from their parent
have to keep their own private copy of '''everything''', including merged revisions that don't
directly affect it.
+ In the Lucene/Solr source tree, as a result of Subversion's `svn:mergeinfo` implementation,
paths that were conflicted and had to be merged below the top level directory began to accumulate
revisions for every single merged commit, even though the commit did not directly change these
paths.  This is because a path with a `svn:mergeinfo` value that differs from its parent has
to keep its own private copy of '''everything''', including merged revisions that don't directly
affect it.
  
  The Subversion book [[http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.advanced.finalword|says]]:
  || For long-lived release branches (as described in [[http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge.commonpatterns|the
section called "Common Branching Patterns"]]), perform merges only on the root of the branch,
not on subdirectories. ||
  
- Robert Muir came up with a solution to the `svn:mergeinfo` property value accumulation problem:
after running all of the `svn merge` commands necessary to handle conflicted paths, remove
`svn:mergeinfo` property values on all paths, except for ` / ` and the top-level directories
(`solr/` and `lucene/` under `branch_3x`).  `svn stat` indicates the paths with modified properties
with an '''{{{ M }}}''' in the second status column from the left.  For each of these paths
(except for ` / ` and the top-level directories), run the following command:
+ Robert Muir came up with a solution to the `svn:mergeinfo` property value accumulation problem:
after running all of the `svn merge` commands necessary to handle conflicted paths, remove
`svn:mergeinfo` property values on all paths, except for ` / ` and the top-level directories
(`solr/` and `lucene/` under `branch_3x/`).  ` svn stat ` indicates the paths with modified
properties with an '''{{{ M }}}''' in the second status column from the left.  For each of
these paths (except for ` / ` and the top-level directories), run the following command:
  {{{
  svn propdel svn:mergeinfo  path/to/remove/mergeinfo/from
  }}}

Mime
View raw message