[crossfire] Using svnmerge for backporting to branch?

[Raphaël Quinet]

On Wed, 20 Feb 2008 23:43:28 -0800, Mark Wedel <mwedel at sonic.net> wrote:
> 
>   Perhaps the biggest problem with using svnmerge is getting everyone to use it.

This is not a requirement.  It is easier if most developers use it, but
it can also cope with revisions that are merged by hand.

To be frank, when someone suggested last year that I start using svnmerge
for the gimp-related svn modules, I was a bit reluctant at first.  And I
was also wondering what would happen if some developers were not using it.
But after I started using it, I understood that it was just a smart
wrapper around 'svn merge' that makes revision tracking easier and does
not get in the way if you still want to do things by hand.  That's why I
am now convinced that such a tool is useful.  But it doesn't do miracles
either and I am not here for promoting it actively, so it is also fine for
me if we decide not to use it.

>   What happens if someone doesn't use svnmerge - makes change in trunk, and then 
> still does manual merge in branch?  I'm guessing it would try to re-merge it then?

In the background, the svnmerge script calls 'svn merge' anyway.  What
will happen in this case is that svnmerge will show you that this
revision is still 'available' for merging.  However, when merging it
will detect that the change was already merged, just like if you would
try 'svn merge' twice on the same revisions.  Once you commit, svnmerge
will mark that revision as already merged, so that it will not pop up
again when anybody else uses 'svnmerge avail' to list the candidates
for merging.

>   Given fairly big code changes in the server from trunk and client (item 
> refactoring, some others), one gets more cases of automatic merges not working. 
> I'm guessing this really doesn't change much (svnmerge won't get confused with 
> those changes?)

Since svnmerge uses 'svn merge' to merge the changes, it will not get
more or less confused.  The main difference is that one can explicitly
block some revisions if they are not bug fixes and should not be merged.

>   What about 'reverse' commits?  It doesn't happen very often, but sometimes I 
> make the bugfix first on the branch, and then commit back to server?

This is not very elegant, but it also works.  You can always merge
things by hand anyway, and then later mark the revisions as merged.

To give you an idea of how it works, I suggest that you have a look at
this page and read the sections "1 Features" and then "7 Quick Usage
Overview": http://www.orcaware.com/svn/wiki/Svnmerge.py

-Raphaël