Someone mentioned that there's branch work
already.
>-----Original Message-----
>From: John Calcote [mailto:jcalcote@novell.com]
>Sent: Friday, August 18, 2006 5:55 PM
>To: Fouts Christopher (QNA RTP PT PREV); users@subversion.tigris.org
>Subject: RE: Re: merging branches confusion
>
>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 Mon Aug 21 16:49:41 2006