Chris,
I'm a little out of it lately - is there work on a "labels" feature
already going on?
Thanks,
John
>>> <Chris.Fouts@qimonda.com> 8/16/2006 1:34 PM >>>
Amen bro! Let's call the revision aliases "labels".
>-----Original Message-----
>From: John Calcote [mailto:jcalcote@novell.com]
>Sent: Wednesday, August 16, 2006 2:46 PM
>To: Fouts Christopher (QNA RTP PT PREV); users@subversion.tigris.org
>Subject: RE: Re: merging branches confusion
>
>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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 18 23:56:56 2006