Scott Lawrence wrote:
>On Mon, 2004-10-11 at 13:06, Greg Goodrich wrote:
>>Why is it that prior to each commit I need to do an update/merge
>>process? I can understand the necessity if there are conflicts, but
>>this seems like a bit of a pain if the changes that happened are not in
>>conflict with each other. It seems to me that if I change a file, I
>>should be able to just commit it, and then if someone else had snuck a
>>change in "under" me, that subversion would quietly merge the files
>>together, and assuming no conflict, go about its business.
>On my projects, the developer is expected to have tested what is being
>checked in - if there were an automatic merge, then there's been no
>opportunity for that testing.
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.
1025 Ashworth Road, Suite 222
West Des Moines, IA 50265
Phone: 515.327.8850 ext. 251/
*Charting Plus - "The Best EMR Value on the Market!"
Received on Mon Oct 11 19:33:43 2004