[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Greg Goodrich <ggoodrich_at_medinotes.com>
Date: 2004-10-11 21:01:45 CEST

Steve Dwire wrote:

>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
>
>
>
That is assuming that you enforce a strict exclusive lock on the files,
which we typically don't, unless the file is of the nature that really
needs it (point for a different discussion). But at the very least,
both developers know that someone else is making changes to the same
file, and can take appropriate action PRIOR to having the issues.

-- 
*Greg Goodrich*
Development Manager
*MediNotes Corporation*
1025 Ashworth Road, Suite 222
West Des Moines, IA 50265
Phone: 515.327.8850 ext. 251/
/Fax: 515.327.8856
	
<http://www.medinotes.com>
*Charting Plus - "The Best EMR Value on the Market!"
**www.medinotes.com* <http://www.medinotes.com/>
 
Received on Mon Oct 11 21:02:31 2004

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

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