[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 Küng <tortoisesvn_at_gmail.com>
Date: Sun, 13 Sep 2009 09:05:02 +0200

On 11.09.2009 17:33, Kristoffer Lundén wrote:
> 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… J
> 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.

Wouldn't the option "ignore ancestry" when merging ignore the mergeinfo
and just do the merge?


   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2009-09-13 09:05:24 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.