Documenting the merge process for TortoiseSVN

[Simon Large <si...@googlemail.com>]

Hi folks,

I'm still trying to get my head around the reintegrate merge for
porpoises of updating the TSVN help file. Please stop me when I go
wrong.

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?)

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?

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?

Merge 2 different URLs does what it always did and does not take
account of merge tracking information?

Thanks,

Simon

-- 
       ___
  oo  // \\      "De Chelonian Mobile"
 (_,\/ \_/ \     TortoiseSVN
   \ \_/_\_/>    The coolest Interface to (Sub)Version Control
   /_/   \_\     http://tortoisesvn.net

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Documenting the merge process for TortoiseSVN

[Karl Fogel <kf...@red-bean.com>]

"Simon Large" <si...@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@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Documenting the merge process for TortoiseSVN

[Mark Phippard <ma...@gmail.com>]

On Sat, Mar 8, 2008 at 7:20 AM, Simon Large
<si...@googlemail.com> wrote:

>  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?)

Try it.  I believe reintegrate would catch this in one of its checks
and not do anything.

>  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?

It is mainly ease of use.  Reintegrate will figure out the right
revision arguments and it also does some checks to be sure the merge
is safe to do.  To be clear, it is still fine to do the 2-URL merge.
You just bypass the checks that reintegrate would do and of course it
is possible you can make a mistake in your arguments.


>  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?

It depends what you mean by fully-sycnhed.  It does not have to be
synched to the HEAD revision, but one of the checks reintegrate will
do is to verify that there have not been any partial tree merges
performed in the branch, or any cherry pick merges.

>  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?

It would be OK if some clients were not using 1.5 when working on the
branch as long as they are not doing merges to the branch.  You would
need a client, server AND repository at 1.5 to do a reintegrate merge
or any merge that uses the merge tracking feature.

>  Merge 2 different URLs does what it always did and does not take
>  account of merge tracking information?

Yes and no.  I think the underlying algorithm is the same in terms of
figuring out what to merge, but in 1.5 a 2-URL merge will still record
merge information.  This is important and is one of the things that
made the reintegrate merge option possible,

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org