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

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_at_subversion.tigris.org].
Received on 2009-09-14 12:37:17 CEST