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

Re: Commit parts of a merge and leave the rest marked as unmerged for someone else

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 14 Sep 2009 14:56:47 +0100

On Mon, Sep 14, 2009 at 03:10:58PM +0200, Kristoffer Lundén wrote:
> However, the developers/conflict solvers may need a long time solving
> the conflicts at times, mainly because they need to compile, build and
> test, and several such "projects" may go on at the same time, so they
> thought it would be very unpractical in, well, practice to share a
> workspace in this manner.
> Also, our versioning strategy has no problems whatsoever with
> non-working revisions, that is common, and these merges can go both
> from stable to unstable (what we call "rebase") and from branch to
> trunk ("reintegrate").
> So yes, there's a lot in what you say, and we may try to go at least
> partly that way, but I would like to see what other options we may have.

If you really want to continue with half-done merges in the repository,
you could try a --record-only reverse-merge on all conflicted files
before committing. E.g. say you have merge r5, r6 and r7 into foo.c,
and r6 produced a conflict, which means you probably want to keep r5
recorded as merged but not r6 and r7, do something like
  svn merge --record-only -c-6 -c-7 foo.c
That should create subtree mergeinfo indicating that this file hasn't
gotten their changes from the revision range you have merged.
Now, people running the same merge as you did will get r6 and r7 into
foo.c merged again.
If you do this, you should understand the implications of having a lot
of subtree mergeinfo in your repository (performance might get worse,
search the archives for "merge performance" -- note that 1.6.6 might
get fixes for this.)

Keep in mind that you are probably pushing the boundaries of what most
people would consider the usual use case. You are really doing advanced
stuff. Merge tracking as it is now works very well for simple feature
and release branches as described in the Subversion book.
If you are doing anything beyond that you should understand the
mergeinfo machinery well enough to be able to understand and hopefully
fix problems during merges yourself, should they happen.
A good starting point is here:

And to keep in the loop, you might also want to check each Subversion
release for updates to the merge-tracking feature before upgrading.
Improvements and bugfixes are made in nearly every 1.6.x release.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-14 15:57:44 CEST

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.