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] Update of "SvnMerge" by SteveRowe
Date Tue, 11 Jan 2011 22:52:46 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

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

New page:
= SVN Merge =

If you have committed a change to `trunk/` and you want to backport it to `branch_3x/`, change
directory 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
}}}
where {{{XXXXXX}}} is the revision of the source `trunk/` commit.

== Conflicts ==

If your `trunk\` commit contained changes to files and/or directories that are not in exactly
the same place on both `trunk\` and `branch_3x` (i.e. renames, moves, deletions, or additions),
Subversion will report a merge conflict.  You can fix this by running the same merge command
given above at each point in the tree that differs, and then telling Subversion that you have
resolved the conflict:
{{{
svn resolve --accept=working  your/conflicted/path
}}}

== svn:mergeinfo ==

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.

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:
{{{
svn propdel svn:mergeinfo  path/to/remove/mergeinfo/from
}}}

Mime
View raw message