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

RE: RE: Re: merging branches confusion

From: Irvine, Chuck R [LTD] <Chuck.R.Irvine_at_embarq.com>
Date: 2006-08-16 17:26:11 CEST

I have seen an indication that the subversion team is working on
enhancing subversion's merge capability. Hopefully, it will be history
sensitive, keeping track of what has been merged so you don't have to.
As I recall, "better merge support" was one of the original goals of
subversion. Does anyone know when this functionality might be targeted
for release?

Until this gets added to Subversion, two options are svnmerge and svk -
neither of which I've actually tried yet.


> -----Original Message-----
> From: Chris.Fouts@qimonda.com [mailto:Chris.Fouts@qimonda.com]
> Sent: Wednesday, August 16, 2006 10:06 AM
> To: users@subversion.tigris.org
> Subject: RE: Re: merging branches confusion
> 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
> >prod):
> >
> >svn merge -r4:20
> >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
> >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

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:39:45 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.