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:
http://www.collab.net/community/subversion/articles/merge-info.html
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.
Stefan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394626
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-14 15:57:44 CEST