"Simon Large" <simon.tortoisesvn_at_googlemail.com> writes:
> I am developing a new feature, so I create a branch from trunk and
> start hacking away. To avoid potential conflicts I want to keep it
> synced up to trunk and the easiest way to do that now is to merge from
> the trunk URL into my branch WC, merging all revisions from branch
> creation to HEAD. Merge tracking will ensure that only revisions not
> yet merged are included. Reintegrate is not appropriate in this
> situation. (But what happens if I specify reintegrate anyway?)
You're right that --reintegrate is not appropriate there, and actually,
I'm not sure what would happen if you specified it (I just haven't tried
it lately, and I know that code has changed since the last time I used
it).
> After much hacking my branch is done and I want to merge back to
> trunk. For this task I use the reintegrate merge. What is not clear is
> how this differs from merging the diff between branch tip and trunk
> tip, which is the method previously used. According to the svnbook
> nightly that is effectively what happens, so why a new command?
>
> Also, what happens in the reintegrate case if the branch is not fully
> in sync. Does it fail or does it silently undo the most recent trunk
> changes that were not synced back to the branch?
These two questions together get to the heart of what --reintegrate is
about, I think: the point of the option is that it does that check for
you. If the branch isn't complete (i.e., not sparse), all one revision
(i.e., not mixed revisions), and fully up-to-date w.r.t. merges from its
line-of-origin, then the reintegration will fail. Whereas a regular
merge might "succeed" (in the sense of the command succeeding, though
not necessarily in the sense of achieving the result you want).
Think of the "--reintegrate" flag as meaning "Check some common
conditions that one would normally want to be true before re-merging a
branch to trunk."
> In order for all this to work everyone working on the branch *must* be
> using a 1.5 client in order to record the mergeinfo. In order for this
> to work _efficiently_ we must also be using a 1.5 server. A pre-1.5
> will work, but possibly very slowly. And what about a 1.5 repository?
I *believe* you want all of the above, including the repository, to be
1.5, for greatest efficiency. I'm not too up on that myself, though.
> Merge 2 different URLs does what it always did and does not take
> account of merge tracking information?
I think that's right, but again, I've been paying attention to other
things, so please don't take my word for it.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-03-09 05:43:54 CET