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

Hello,

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_at_netent.com, www.netent.com

Better Games

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2393634

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-11 17:40:15 CEST