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

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

Better Games

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

From: Jan Hendrik [mailto:list.jan.hendrik_at_gmail.com]
Sent: den 14 september 2009 12:36
To: users_at_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_at_subversion.tigris.org].
Received on 2009-09-14 15:11:49 CEST