[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: merging/branches practices

From: Vincent Starre <vstarre_at_comcast.net>
Date: 2006-03-08 23:05:39 CET

Garrett Rooney wrote:

>On 3/8/06, Vincent Starre <vstarre@comcast.net> wrote:
>
>
>
>>When you are certain you want a complete sync:
>>(first, merge branch changes into trunk, then...)
>>$ cd branch_wc
>>$ svn merge repos/branch repos/trunk .
>>(here examine changes with svn diff to be sure you aren't squashing any
>>branch changes you forgot to merge back to trunk)
>>$ svn ci
>>
>>
>
>This is actually not what you want to do. This will make your trunk
>working copy look exactly like your branch, and any changes that were
>made on the trunk since you initialy branched will be lost.
>
If I had done the opposite, sure, but I didnt, and I tripple checked and
commented on it, so I'm sure I did it right :)
The syntax of diff is:
$ diff old new > patch
"create a patch which turns old into new"
The syntax of patch is:
$ patch "old" < patch

svn diff and svn merge work the same way:
$ svn merge branch trunk branch_wc
will create a psuedo-patch which turns "branch" into "trunk" and apply
that to "branch"-> turning branch_wc into something identical to a
trunk_wc, but recieving updates from branch and having branch's history.
(losing any changes to BRANCH, not trunk, which haven't yet been merged
back to trunk)

>You want
>something like this:
>
>$ svn merge -rREV1:REV2 branch_url .
>
>
This is precisely what you do _not_ want. This is fine for incremental
merges as you are actively working in branch, but any time you want to
say "at this point, these are in perfect sync", you should run a command
which actually does just that. svn diff can then be used to ensure that
you aren't squashing anything you aren't trying to. If svn had merge
tracking, their might be other implications which would need to be taken
into account- but it doesnt, so you should be sure they're synchronized
by using a command which actually does so.
You might also want to use the "merge changes to trunk from trunk to
branch" method if you have made changes you actually want to keep, such
as config file changes which you want versioned. That's a matter of style.

I asked this exact question on IRC last week, so I've given it a bit of
thought. Doing a true sync of branch and trunk is simpler, gives you
another opportunity to catch errors, and will never cause
conflicts(*except those due to bugs- vote for 2501 ! :))

Having your branch and trunk go out-of-sync is no fun. Why use a command
which encourages the possibility?

and just in case anyone misunderstands: this is _NOT_ the way to merge
branch changes into trunk. This is _NOT_ the way to do your regular
incremental updates. This is _only_ for use when you've reached a point
where all your changes should be in trunk already and all your
development is essentially "ready to start fresh". That is to say: you'd
just delete and re-copy if it wouldnt make svn blame so much harder to read.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 8 23:07:22 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.