Very helpful question and answer -- thanks. So, a followup question
to solidify my understanding:
Background: we are currently running 1.4. We follow svnbook's basic
recommended practices, performing weekly syncs of trunk->feature
branch. In addition, we sometimes find that a particular revision,
Nf, on a feature branch is of some use on trunk. We thus do a simple
merge of just Nf to trunk, creating revision Nt, and all is well.
However, the next time (e.g. weekly) that we want to re-sync the
feature branch with trunk, we want to skip the revision in question
since the feature branch already has it. One way to accomplish this
with 1.4 is to merge down the week's range and manually resolve
conflicts; another method is to merge two revision ranges, carefully
skipping Nt.
With 1.5, will a 1.5-style re-sync (i.e. no revision range specified)
cleanly skip Nt, knowing that the feature branch already has this (as
revision Nf)? or is special care to skip the revision still required?
And back to the OP's topic, will a subsequent merge-back just pass
--reintegrate as per normal?
Thanks!
Kylo
On Fri, May 30, 2008 at 7:55 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> Subversion's merge feature is generally based on revisions. Either
> you include or exclude a revision in the merge. The Merge Tracking
> feature is about recording which revisions you have already merged and
> potentially allowing you to just merge all the revisions you do not
> have.
>
> This general merge concept does not work correctly when you get into a
> "cyclic" or "reflective" merge scenario. Meaning, you create a branch
> from trunk, make changes on branch. Merge changes from trunk to
> branch and then eventually merge from branch back to trunk.
>
> The problem is the step where you merged changes from trunk to the
> branch. When you did this, it created a revision on your branch.
> When you want to merge that branch back to trunk, Subversion is only
> capable of doing one of two things. Include the revision, or do not
> include the revision. Neither answer is generally correct because it
> is possible, even likely, that the revision contains other changes
> that go beyond the merge. For example, the merge might have required
> conflict resolution. If you simply exclude this revision, then you
> also exclude the conflict resolution.
>
> If you do not use the --reintegrate option, then these revisions are
> included in the merge back to trunk. In some, but not all cases, this
> will causes unnecessary conflicts because trunk already has the
> changes trying to be applied.
>
> So all of the above is the problem. Subversion already had in place a
> merge solution that is capable of producing the desired results. This
> is called a 2-URL merge because of the syntax it requires. For
> example, to merge a branch back to trunk.
>
> svn merge url://trunk@LAST-REV url://branch
>
> Where LAST-REV is the last revision from trunk that was merged to the branch.
>
> The --reintegrate option was added as a syntax shortcut to make this
> type of merge easier to use. The above merge becomes this:
>
> svn merge --reintegrate url://branch
>
> Internally, this code figures out and runs the above merge. It is
> worth pointing out that because it is doing a lot of logic for you, it
> was decided that it should also do a lot of safety checks and error
> out without doing the merge if these checks fail. Some of these
> checks might prevent you from using this syntax and you might then
> have to use the 2-URL syntax in place of it.
>
> Hopefully this answers your question.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-05-30 18:35:28 CEST