I've brought this issue up before, and I'll mention it again here, even
though it's a touchy subject on this list:
If tags were simply aliases for revision numbers like they are in CVS,
then we'd all be more comfortable. Look, this idea has much precedence.
DNS names are simply aliases (albeit complex ones) for IP addresses, for
instance. Look how much value we get from DNS names on the Internet. I
can remember dozens of IP addresses indirectly through their "tag"
aliases.
In all the arguing I've seen on this and the dev list regarding why
tags should NOT be used as simple aliases for revision numbers in SVN, I
still have yet to see a truly valid reason for this point of view. I
keep hearing about vague features that MIGHT be implemented in the
future on top of the current "tags as branches" approach, but I don't
get any satisfaction from these arguments.
On the other hand, I hear time and time again about the frustration the
people experience with not being able to use tags as aliases in SVN.
Well, fine. If we must insist on not implementing tags as they were
done in CVS (as mere aliases for revision numbers (or revision number
sets in the case of CVS)), then the least we can do is provide a brand
new feature called "names" or something. Let's go ahead and reserve the
"tags" concept for that esoteric set of super SVN features that we'll
all be able to ooooh and aaaaah over some day. In the mean time, we can
get something done with the new "revision name" feature, that allows us
to treat revision numbers as easy-to-remember names.
Just a suggestion.
John
>>> <Chris.Fouts@qimonda.com> 8/16/2006 9:05 AM >>>
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 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.
>
>
>---------------------------------------------------------------------
>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 20:48:08 2006