Robert,
if I understand correctly, what you need to find out automatically is the origin of a branch, correct? So isn't the log giving you that information?
Mit freundlichem Gruss / With kind regards
Markus KARG, Staatl. gepr. Inf.
Entwicklung / R & D
QUIPSY QUALITY GmbH
________________________________
Von: Robert Cronk [mailto:rcronk@altiris.com]
Gesendet: Do 06.10.2005 17:31
An: users@subversion.tigris.org
Betreff: RE: Nested Branches
Thanks for the reply. I see now that I should have been a bit clearer in my description of the problem. I already have scripts written in python that detect changes in each branch, build each branch, and then merge each group of changesets automatically into the trunk. I have been doing this with svn for about a year and a half. Since these scripts always merge to the trunk, they have never had to figure out which branch to merge into - it's always the trunk. If I start nesting the branches, then the script needs to auto-detect not only which changesets need to be merged (that's already done) but also which branch to merge the changesets into (not done yet - this is what I'm after).
I do not know if automating all of this makes me smart or just plain lazy, but I know it can be done. I am just asking for experience from others in figuring out programmatically the easiest way to find out where something was copied from so I can merge changes into the HEAD of that branch. Does that make sense?
So in the following structure, I need the scripts to know that I am wanting to merge changes from 1.1 down to 1 and then from 1 down to the trunk. What is missing is the code that will find out where the current branch I am working on was copied from when that branch was created. For example, I copied the trunk to branch 1 then a bit later I copied branch 1 to branch 1.1. Knowing that, I can then merge changes each time I build from 1.1 to 1 and from 1 to the trunk.
+--------- branch 1.1
/
+-----+----------- branch 1 +----branch 2
/ /
-----------+---------------------------------+----------- trunk
Robert
________________________________________
From: Markus Karg [mailto:markus.karg@quipsy.de]
Sent: Wednesday, October 05, 2005 11:32 PM
To: Robert Cronk; users@subversion.tigris.org
Subject: AW: Nested Branches
Robert,
no panic, actually you don't merge branches but patches (change sets). This means, If you take a bit care when merging, there is no different in the results of either merging branch 1.1 into branch 1 into trunk compared to merging branch 1 into trunk and branch 1.1 into trunk. You just need to take care of the the revision numbers when branching. Also it would be beneficial to do the branches in the correct time sequence (1, 1.1) because you might prevent some merge problems. then.
Following this rule I don't see that you need a special directory structure or organizational hint. Again, remember, SVN branches patches, not branches.
Mit freundlichem Gruss / With kind regards
Markus KARG, Staatl. gepr. Inf.
Entwicklung / R & D
QUIPSY QUALITY GmbH
________________________________________
Von: Robert Cronk [mailto:rcronk@altiris.com]
Gesendet: Mi 05.10.2005 23:35
An: users@subversion.tigris.org
Betreff: Nested Branches
Recently, our company has decided to work with concurrent development in
a slightly different way than it has in the past. In the past, we have
had the following style of branching (1 level deep):
+-------- branch 1 +------ branch 2
/ /
-----------+-----------------------+---------------------- trunk
And so the branches that appear in the branches directory are siblings
and not leveled or nested or anything. All changes made in branches are
merged directly to the trunk and are assumed to be branches of the
trunk.
And now, they want to change it to this:
+--------- branch 1.1
/
+-----+----------- branch 1 +----branch 2
/ /
-----------+---------------------------------+----------- trunk
So that I can't just put branch 1 and branch 1.1 into the branches
directory because they are nested and related so that I would want to
merge changes from branch 1.1 into branch 1 and then from branch 1 into
the trunk. This way, the developers only have to put their changes in
one time and it will cascade merge down from the furthest out branch
toward the trunk.
I have thought of a few ways to do this. I have thought of setting up
some kind of directory structure in the branches that would indicate
which branch came from which. I have also thought of just trying to
figure out which branch came from which programmatically by looking at
logs, etc.
I currently don't want to make it more complex than 2 levels deep, but
if I'm going to set it up for 2 levels deep, it would seem to be just as
easy to make it generic and make it n-levels deep.
I want feedback from anyone out there that has had success in
implementing this type of structure successfully or have run into
problems with certain methods of doing it. Please let me know what you
all think. Of course, we'll be throwing this new structure into a live
build system within the next week or two. ;-)
Thanks,
Robert
---------------------------------------------------------------------
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 Oct 7 09:27:29 2005