svnmerge.py looks almost right, but not quite. Branch-to-branch merges
do not seem to be supported unless you specify the -prop differently
for each maintenance branch. But it contains some useful ideas. Has
anyone tried using it on a repository with many revisions (>50.000) ?
Regards,
Ivan
2007/9/10, Ryan Schmidt <subversion-2007b@ryandesign.com>:
> 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?
>
> http://www.orcaware.com/svn/wiki/Svnmerge.py
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 11 08:43:55 2007