Re: Merging and Banching (kind of) question.

From: Martin J. Stumpf <mjs_at_jhu.edu>
Date: 2005-07-07 20:15:11 CEST

Ron Gilbert wrote:

(posted this to dev by mistake the first time)
I have a repository that has four projects (Proj1, Proj2, Proj3 and Proj4) and I want to create a fifth project (Proj5) that is a copy of Proj4.  Most of the work will be done on the new Proj5, but over time I will need to merge all the relevant changes back to Proj4, because it will need to be kept up-to-date.  Very little work will happen on Proj4 independent of Proj5.
All the examples for creating copies and merging happen in release versions that sit at the same level as trunk, which is not what I need, so I am unclear if I can just copy Proj4 to Proj5 and then use merge?
If so, what would the merge command look like?
Proj4> svn merge svn://foo.com/trunk/Proj5
But I'm missing revision numbers.  I don't want to have to keep track of revision numbers, I just want to merge Proj5 with Proj4.  
Is this the best way to handle the situation?  The more I look at it, the more I wonder if I am thinking about this correctly.
I could just copy the files and add them as Proj5, but then I loose the history for Proj5, or I could rename Proj4 to Proj5 and add the files to a new Proj4.  Seems sloppy.
Thanks, Ron

Ron,
Having 4(5) projects in one repository is no different then having 4(5) directories in one repository and they of course can be named anything you like. The convention of trunk/branches/tags is a helpful semantic device to manage the directories within a repository. It sounds to me that you want to 'freeze' Proj4 for now and continue working on a copy soon to be called Proj5. If that is correct then you could certainly just cp Proj4 to Proj5 and begin working on a co of Proj5. Since you say that you will work on Proj5 and then port those changes into Proj4 it begins to sound like branches or tags are in order.

I find the conceptual layout of trunk/branches/tags to be very helpful as I branch the trunk at a particular point of stability and then tag the branch. So, I cp the trunk to branches/1.0.x and then tag 1.0.x to tags/1.0.0. The tag is treated as 'read-only', no commits. I continue to work on the trunk and when there are enough fixes that impact the 1.0.x branch I port those changes back into branches/1.0.x using merge. A branch is JUST a copy. You are going to branch to make Proj5 no matter what you call it. And the file heirarchy doesn't matter except to help you.

Also, you mention 'not keeping track of revision numbers'. You have to keep track of revision numbers when merging.
If you branch at rev 10 and then want to port changes from Proj5 which has evolved to rev 15, then you have to do your merge by specifying -r 11:15 on Proj5 so that only that changeset gets merged into your Proj4.

I may have misunderstood your intention but that is my 2 cents.

Hope it helps,

-Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org For additional commands, e-mail: users-help@subversion.tigris.org Received on Thu Jul 7 20:20:26 2005