Re: merging branches confusion

Ryan Schmidt wrote:
>
> On Aug 15, 2006, at 21:18, blackwater dev wrote:
>
>> I have two repositories with development going on in each. One is a
>> stable branch where we periodically make small changes and the other
>> is our beta branch where we do larger development projects. When we
>> make a small change to our stable branch, we want those changes to our
>> beta branch as well. So, for example, if I have a file in beta with a
>> lot of changes named allergies.cfm and someone else has made small
>> changes for a quick bug fix in the stable branch to allergies.cfm,
>> they need to get merged. I find that when I go to my working dev
>> sandbox and do the command below, it gives me the latest stuff in my
>> working copy from prod but removes all my dev changes in my local copy
>> that are commited to dev but not yet to prod. I need to keep all the
>> dev stuff and add the new changes from prod.
>>
>> svn merge http://10.1.1.15/svn/eDig/dev/include/allergies.cfm
>> http://10.0.1.15/svn/eDig/prod/include/allergies.cfm
>>
>> If find if I switch the merge to do prod then dev, nothing happens at
>> all.
>
> Subversion is doing exactly what you told it to do, a.k.a. that's not
> how you use the merge command.
>
> The merge command is a kind of diff-and-patch. That means, first it
> constructs a diff between two locations in the repository, then it
> applies that to a third place -- your working copy. You've asked for a
> diff between the version of a file on dev and the same file on prod.
> That's not what you want, because it results in the problem you observed.
>
>
> Rather, you have some changes that were made to
> dev/include/allergies.cfm. You would like to apply these changes to the
> prod branch. So get a working copy of the prod branch:
>
> svn co http://10.0.1.15/svn/eDig/prod
> cd prod
>
> Discover the revision number(s) in which the change(s) occurred that you
> want to merge.
>
> svn log http://10.1.1.15/svn/eDig/dev/include/allergies.cfm
>
> Let's say you discover by reading the log that changes were made in
> revision 5, 15, and 20, and that you want all of these changes merged
> over. So you need to ask Subversion to compute the diff between revision
> 4 (the revision before the first change took place) and 20 (the revision
> after all the changes you want have taken place) and apply that to the
> copy of the file in the current working copy (of prod):
>
> svn merge -r4:20 http://10.1.1.15/svn/eDig/dev/include/allergies.cfm
> include/allergies.cfm
>
> Then you test the changes in your working copy. Then you commit the
> working copy, making note in the log message that you've merged from 4
> thru 20 of this file in dev into prod.
>
> Usually I think people don't merge individual files like that, though it
> should work fine. In Subversion, changes are usually revision-based, not
> file-based. (Revision 5 might include changes to files other than
> allergies.cfm, and since it was part of the same commit, and you're
> supposed to use 1 commit for 1 task, then that other change likely
> belongs with this one.) So if you read the log messages of dev and
> decide that revisions 5, 15 and 20 are the three fixes that you want to
> merge to prod, and you don't want to merge any of the intervening
> revisions because they are for other unrelated new features for example,
> then you would merge just those revisions into the prod working copy:
>
> svn co http://10.0.1.15/svn/eDig/prod
> cd prod
> svn merge -r4:5 http://10.1.1.15/svn/eDig/dev .
> svn merge -r14:15 http://10.1.1.15/svn/eDig/dev .
> svn merge -r19:20 http://10.1.1.15/svn/eDig/dev .
> # test test test
> svn ci -m "Merging revisions 5, 15 and 20 from dev into prod"
>
> It's important to note in the log message exactly what you merged, so
> that when you look at the log later you'll know, and you won't try to
> merge the same thing twice. Subversion does not currently have merge
> tracking so you have to keep track yourself of what you've already merged.

Now that Ryan described merging so clearly, I would recommend using the
svnmerge.py script to take all the hassle out of managing the revision numbers
and the log message. You need to know the how's and what's of merging, but once
you do, then using svnmerge.py makes one's life much easier and reduces the
chance for errors, or forgetting to note which revisions were merged over.

Regards,
Blair

-- 
Blair Zajac, Ph.D.
http://www.orcaware.com/svn/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org