merging/branches practices

[Aaron Montgomery <ee...@monsterworks.com>]

This is a (newbie) question about merging/branching. I have read the  
Subversion documentation but don't remember anything like this  
although I am guessing that the situation below isn't that uncommon  
so maybe I misunderstood something in the docs.

Here's the situation:

A main branch (/trunk) is shared by everyone in the project.

I create a personal branch called (/branches/aaron) at revision 100  
by copying /trunk and I work in that branch. Along the way, I  
occasionally merge changes occurring in /trunk back to /branches/ 
aaron (begin careful not to repeat a merge). Assume that the last  
merge of /trunk into /branches/aaron occurred at revision 200.

Now I've reached a milepost in /branches/aaron (at revision 300) and  
would like at this point to completely resync my personal branch  
with /trunk (porting my changes in the branch back to trunk and then  
basically starting the process over from scratch). I do not want to  
eliminate my personal branch since I will continue working on it.

Here is something like what I think should be done, but it looks  
somewhat convoluted and parts of it really make me wonder if I'm  
merging the correct patches. (The syntax here should be close enough  
for you to get the meaning, but it probably isn't exactly correct).

cd aaron_wc
svn merge -r200:300 repository/trunk .
[[ handle any conflicts ]]
svn commit .
[[ we're now at version 301, differences in aaron and trunk are the  
result of my changes in aaron ]]

cd trunk_wc
svn update .
svn merge -r200:301 repository/branches/aaron
[[ handle any conflicts ]]
[[ how should I handle it if someone commits a new revision in here? ]]
svn commit .
[[ we're now at version 302 ]]

svn copy repository/trunk repository/branches/aaron
cd trunk_wc
svn update .
[[ or should I merge trunk into aaron here insead of a copy and  
update?]]

Thanks in advance for any comments,
Aaron

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

Re: merging/branches practices

[Vincent Starre <vs...@comcast.net>]

Garrett Rooney wrote:

>On 3/8/06, Vincent Starre <vs...@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

Re: merging/branches practices

[Garrett Rooney <ro...@electricjellyfish.net>]

On 3/8/06, Vincent Starre <vs...@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.  You want
something like this:

$ svn merge -rREV1:REV2 branch_url .

Where REV1 is the last time you merged from that branch (or the
initial revision that created the branch if you've never merged from
it) and REV2 is the last revision on the branch you want to merge
(probably HEAD).

-garrett

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

Re: merging/branches practices

[Vincent Starre <vs...@comcast.net>]

Aaron Montgomery wrote:

> This is a (newbie) question about merging/branching. I have read the  
> Subversion documentation but don't remember anything like this  
> although I am guessing that the situation below isn't that uncommon  
> so maybe I misunderstood something in the docs.
>
> Here's the situation:
>
> A main branch (/trunk) is shared by everyone in the project.
>
> I create a personal branch called (/branches/aaron) at revision 100  
> by copying /trunk and I work in that branch. Along the way, I  
> occasionally merge changes occurring in /trunk back to /branches/ 
> aaron (begin careful not to repeat a merge). Assume that the last  
> merge of /trunk into /branches/aaron occurred at revision 200.
>
> Now I've reached a milepost in /branches/aaron (at revision 300) and  
> would like at this point to completely resync my personal branch  with 
> /trunk (porting my changes in the branch back to trunk and then  
> basically starting the process over from scratch). I do not want to  
> eliminate my personal branch since I will continue working on it.
>
> Here is something like what I think should be done, but it looks  
> somewhat convoluted and parts of it really make me wonder if I'm  
> merging the correct patches. (The syntax here should be close enough  
> for you to get the meaning, but it probably isn't exactly correct).
>
> cd aaron_wc
> svn merge -r200:300 repository/trunk .
> [[ handle any conflicts ]]
> svn commit .
> [[ we're now at version 301, differences in aaron and trunk are the  
> result of my changes in aaron ]]
>
> cd trunk_wc
> svn update .
> svn merge -r200:301 repository/branches/aaron
> [[ handle any conflicts ]]
> [[ how should I handle it if someone commits a new revision in here? ]]
> svn commit .
> [[ we're now at version 302 ]]
>
> svn copy repository/trunk repository/branches/aaron
> cd trunk_wc
> svn update .
> [[ or should I merge trunk into aaron here insead of a copy and  
> update?]]
>
> Thanks in advance for any comments,
> Aaron

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

and probably tag the syncpoint.

Note: be sure you do svn merge branch trunk, not the other way around. 
This drove me crazy last week and I just did it backwards /again/ when 
typing this message and only noticed as I was about to hit send :)

You are merging the Difference between Branch and Trunk into the working 
copy, resulting in a Working Copy which is the same as Trunk.

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

Re: merging/branches practices

[Raman Gupta <ro...@fastmail.fm>]

Aaron Montgomery wrote:
> This is a (newbie) question about merging/branching. I have read the
> Subversion documentation but don't remember anything like this although
> I am guessing that the situation below isn't that uncommon so maybe I
> misunderstood something in the docs.
> 
> Here's the situation:
> 
> A main branch (/trunk) is shared by everyone in the project.
> 
> I create a personal branch called (/branches/aaron) at revision 100 by
> copying /trunk and I work in that branch. Along the way, I occasionally
> merge changes occurring in /trunk back to /branches/aaron (begin careful
> not to repeat a merge). Assume that the last merge of /trunk into
> /branches/aaron occurred at revision 200.
> 
> Now I've reached a milepost in /branches/aaron (at revision 300) and
> would like at this point to completely resync my personal branch with
> /trunk (porting my changes in the branch back to trunk and then
> basically starting the process over from scratch). I do not want to
> eliminate my personal branch since I will continue working on it.

Try out svnmerge.py in the client-contrib directory. It will do all the
merge tracking for you (so you don't have to be careful to not repeat
merges), and bidirectional merging support has recently been added which
makes it easy to handle the situation you describe.

Cheers,
Raman


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