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

Re: Subversion 101: To lock or not to lock..

From: Nico Kadel-Garcia <nkadel_at_comcast.net>
Date: 2006-06-09 01:19:07 CEST

Duncan Murdoch wrote:
> On 6/8/2006 5:18 PM, Michael March wrote:
>> I am the new guy on a young project.. the project has 10 -> 15 Java
>> developers. The app is a JBoss app that implements the JBoss Portal
>> (kinda like a Java version of PHPNUKE).
>> The project is only a few months old and the project is constantly
>> changing.. very much in flux.
>> Here is the problem, I am the SCM on the project and I am telling
>> everyone based on my experience no one should be locking of any files
>> (text) on check out. Everyone else on the project is insisting that
>> some files should be locked on check out.
>> I showed everyone THE page in the official manual and they don't seem
>> to care. I shared my previous expereiences on other projects and that
>> didn't move them. Their line is this: In the new way of fast paced
>> Java web programming.. you are going to have a ton of conflicts and
>> merges all the time and it thus it doesn't lend itself to the
>> 'non-locking' way of using Subversion.
>> Does anyone have any advice for what I should say or how to handle
>> this situation?
> If conflicts from concurrent edits would be a problem, then conflicts
> of the "Arrgh! Joe still has that file locked!" variety will be a
> problem when using locking.
> Both are reduced by telling people to update and commit frequently.
> Duncan Murdoch

And slapping them in the head and teaching them to use their own branches.
Simultaneous code editing is always an adventure, and that's why you merge
them back to the trunk when they're ready to be committed.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 9 01:19:56 2006

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.