RE: Re: Why can't commit attempt a merge automatically?

Greg Goodrich:

> That is an interesting concept.  However, if developer A checks in one
> minute before developer B, then B has to test a situation that A didn't
> have to test.  The situation is reversed if the checkin order is
> reversed.  I guess what I'm saying is that I would assume that both A and
> B would test their code prior to either checking the code in.  It just
> seems like the poor person that happens to check in last loses.  B could
> go through another round of testing given the first scenario, and again
> have had A do another checkin, only to have to start all over again.  This
> type of testing seems to be a bit random to me, as to who has to test the
> combination of the changes of all the developers made at a given time on a
> given file.
>
> I do think, however, that one or both developers may like to know that a
> merge was done that could affect something that they have done.  I guess
> maybe this discussion points out one advantage of the lock-modify-unlock
> method of development over the copy-modify-merge method.

Any time there is a parallel need to edit a single file, some developer will be inconvenienced. However, using the lock-modify-unlock method for this scenario causes (in my opinion) even MORE pain for poor developer B. Instead of simply having to run a test once more, dev B will actually have to sit around and wait to START any changes to the common file until after dev A has FINISHED testing and committing all changes for A's ENTIRE TASK, finally unlocking the file that dev B needs. I hardly consider this an advantage.

S_E_D

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Oct 11 20:19:02 2004