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

RE: Re: merging branches confusion

From: <Chris.Fouts_at_qimonda.com>
Date: 2006-08-16 17:05:30 CEST

Merging is a lackluster feature in Subversion IMHO, espcially
since one can NOT use tags to delineate from-to merge points,
as one can in CVS. I like the CVS philosophy where "users should
NOT care for revision numbers", but in Subversion users have
to as in the case for merging!

>-----Original Message-----
>From: Ryan Schmidt [mailto:subversion-2006c@ryandesign.com]
>Sent: Tuesday, August 15, 2006 5:49 PM
>To: blackwater dev
>Cc: users@subversion.tigris.org
>Subject: Re: merging branches confusion
>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
>> 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
>cd prod
>Discover the revision number(s) in which the change(s)
>occurred that you want to merge.
>svn log
>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
>svn merge -r4:20
>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
>cd prod
>svn merge -r4:5 .
>svn merge -r14:15 .
>svn merge -r19:20 .
># 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.
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 16 17:11:04 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.