[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Non-trivial branch+merge best practice?

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-09-10 23:20:51 CEST

On Sep 10, 2007, at 15:38, Ivan Skytte Jørgensen wrote:

> I am currently preparing for a conversion from CVS to Subversion. The
> conversion is not a problem, but the branching/tagging/merging
> practices may be.
> We are maintaining several old releases. We also use a few development
> branches. The main trunk is sometimes precious, sometimes not. We
> occasionally have feature branches. Whether a bugfix is first done in
> the oldest applicable maintenance version and then merged forward, or
> fixed in most recent maintenance branch and then selectively merged
> backward depends on the exact type of bug and the developer. And also
> sometimes the history of the bug (no need to fix it in old versions
> ... oops. on the other hand ...)
> I have read the most useful messages by Malcom Brown 14 Dec 2004
> 14:16:53 and Nick Thompson 12 Jul 2006 11:12:07, but I am not sure
> what the best practice is for doing the above with Subversion.
> Eg. for fix-in-old-maintenance-then-merge-forward scenario we do in
> CVS:
> 1: fix in old maintenance_1_0 branch
> 2: commit
> 4: for each newer maintenance branch and trunk do:
> 3: switch to maintenance_1_1 branch
> 4: cvs update -jmerged_1_0_to_1_1 -jmaintenance_1_0
> 5: commit
> 6: switch to maintenance_1_0
> 7: cvs tag -F merged_1_0_to_1_1
> So we keep a tag for the last revisions that were merged to newer
> branches. And we move the tag. This is not pretty, but it works, and
> avoids some ugly problems with double-patches etc.
> We can use the same method in Subversion (deleting tags and recreating
> them), but I am not sure if it is the best way to do it. Please keep
> in mind that steps described above are not done on the whole tree, but
> by each developer for his subtree(s). No-one has a global overview of
> the 20.000+ files in the source tree. And the steps are not done at
> the same time by all developers. Sometimes merging of a subtreee has
> to be delayed for various reasons.
> Do anyone have a better way to handle maintenance of multiple
> branches, subtrees, etc. that are not as ugly as in CVS?

There is work being done to get merge tracking in Subversion. Until
that's done, maybe you want to look into svnmerge.py?


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 10 23:19:13 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.