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

[Kristoffer Lundén <kr...@netent.com>]

Hello,

The below text has already been posted once to the tortoise list, because we are mainly using tortoise and I wanted to know if there was a GUI way to do what I want. However, they directed me over here since it's more of a basic issue with how Subversion works, so I hope I can gain some enlightenment on this list instead then. :)


I was wondering if you could help me with a use case I have.

We develop in several repositories that have interdependencies and also using multiple branches. Even so, the repositories are huge and merges take a long time and can be a bit on the complex side.

For these and other reasons, the repositories are kept under a certain amount of control, and when it is time to reintegrate changes, or to spread the same changes to other branches, we have one central “authority” (could be me) that makes all the merges across the board, and then distributes the not easily solved conflicts to the different people that should take care of them.

The way this is done currently is to do the merge, choose “resolve all later” when any conflict dialog appears and for all conflicts that are not obvious and easy we copy all the paths to send out to the experts on the respective areas.

We also commit everything that has already been properly merged, and then we turn over the list of conflicts to the experts.

And here is the problem – we haven’t found a good way for them to repeat the same merge, only getting these changes, so that they can easily fix it up using tortoise or other similar tool:

If we choose to resolve all conflicts so that we can commit them, then the changes are naturally marked as merged and fixed – not what we want.

But if we revert the conflicted files and commit all the rest, we also can not repeat the previous merge. I *think* that this is because svn:mergeinfo properties are inherited from parent paths, but I am not entirely sure.

The result is that the poor developers need to manually open both paths for each file in a merge tool, which is really really really tedious to do when you have 10, 20 or 50 files to have a look at… ☺


So, the question is if anybody has any good ideas on how we could solve this little workflow problem? We are happy enough with the process (although *ideas* are always welcome) as it fits our scenarios, but it would be extremely helpful if we could:

1. Do a complete merge
2. Ignore any harder conflict, making a note of the files to check that all are fixed later
3. Commit all that went well in the merge
4. Hand over a list of revisions merged and what branches + the above list to developers
5. The developers repeat the exact same merge interval and get the same remaining conflicted files

I can think of a few hackish methods to do this, involving manipulation of mergeinfo and other bad mojo, but I’d really rather not.

Many thanks for any enlightenment on this issue. ☺

/ Kristoffer



--------------------------------------------------------


Kristoffer Lundén
Configuration Manager

Net Entertainment NE AB, Birger Jarlsgatan 57 B, S-113 56 Stockholm, Sweden
T: , F: +46 8 556 967 07
kristoffer.lunden@netent.com, www.netent.com

Better Games

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394493

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Stefan Sperling <st...@elego.de>]

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@subversion.tigris.org].

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

[Kristoffer Lundén <kr...@netent.com>]

Hello Jan,


 


--------------------------------------------------------


Kristoffer Lundén
Configuration Manager

Net Entertainment NE AB, Birger Jarlsgatan 57 B, S-113 56 Stockholm, Sweden
M: , T: , F: +46 8 556 967 07
kristoffer.lunden@netent.com, www.netent.com

Better Games

 
-----Original Message-----

From: Jan Hendrik [mailto:list.jan.hendrik@gmail.com] 
Sent: den 14 september 2009 12:36
To: users@subversion.tigris.org
Subject: Re: Commit parts of a merge and leave the rest marked as unmerged for someone else

> However, I wonder if
> this would not be a case where using a shared working copy
> (between the experts related to the merge conflicts) would be
> beneficial.  It seems your internal communications are already
> good (at least when it comes to resolving conflicts), so sharing a
> working copy, otherwise not endorsed for good reason, might work
> fine for you.  Just take care that not two or more experts
> concurrently work on the same file, probably at two different
> conflicts.
>
> Another thing looking not so good in your current workflow is the
> partial commit of conflict-free stuff.  You will have stages (revisions)
> in your repository where the code is incomplete and probably not
> working at all.  In a way this reverses the general idea of having
> work done in branches until it is complete and ready to go.  So for
> this aspect first resolving all conflicts in one (shared) working copy
> and then committing everything at once would be beneficial as well.


You are, of course, absolutely right, and we have considered such strategies.

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.


BR / Kristoffer

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394608

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Jan Hendrik <li...@gmail.com>]

Concerning Commit parts of a merge and leave t
Kristoffer Lundén wrote on 14 Sep 2009, 11:12, at least in part:

> For these and other reasons, the repositories are kept under a certain
> amount of control, and when it is time to reintegrate changes, or to
> spread the same changes to other branches, we have one central
> “authority” (could be me) that makes all the merges across the
> board, and then distributes the not easily solved conflicts to the
> different people that should take care of them.
>
> The way this is done currently is to do the merge, choose “resolve
> all later” when any conflict dialog appears and for all conflicts
> that are not obvious and easy we copy all the paths to send out to the
> experts on the respective areas.
>
> We also commit everything that has already been properly merged, and
> then we turn over the list of conflicts to the experts.
>
> And here is the problem – we haven’t found a good way for them to
> repeat the same merge, only getting these changes, so that they can
> easily fix it up using tortoise or other similar tool:

I am not very familiar with this merging business, not least as we
practically gave up branching long ago for reasons which may have
been solved in the meantime or not (one: switching to a branch or
back took as much time as chicking out another working copy,
even if there was not modified anything yet).  However, I wonder if
this would not be a case where using a shared working copy
(between the experts related to the merge conflicts) would be
beneficial.  It seems your internal communications are already
good (at least when it comes to resolving conflicts), so sharing a
working copy, otherwise not endorsed for good reason, might work
fine for you.  Just take care that not two or more experts
concurrently work on the same file, probably at two different
conflicts.

Another thing looking not so good in your current workflow is the
partial commit of conflict-free stuff.  You will have stages (revisions)
in your repository where the code is incomplete and probably not
working at all.  In a way this reverses the general idea of having
work done in branches until it is complete and ready to go.  So for
this aspect first resolving all conflicts in one (shared) working copy
and then committing everything at once would be beneficial as well.

JH

---------------------------------------
Freedom quote:

     Freedom of religion, freedom of the press, and freedom of person
     under the protection of the habeus corpus, these are principles
     that have guided our steps through an age of revolution and reformation.
               -- Thomas Jefferson

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394520

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].