On 12/5/2005 11:02 AM, Thompson, Graeme (AELE) wrote:
> Yes, we have been in the situation of having files locked when people
> have gone on vacation, but in these cases it is possible to forcibly
> unlock the files and leave the developer a note, thus not stopping other
> working on them.
>
> More seriously, from our perspective, is the issues we have had when
> people have tried to merge their changes in with other peoples changes
> and have reintroduced bugs that have already been fixed because they did
> not have a full understanding of what they were doing. These bugs then
> take the extra time for someone to track down and then fix them again!
You need to have the person fixing the bug add a regression test, and a
policy that nobody commits code that fails the regression tests. This
prevents the scenario you talk about, and also the one where someone
comes along later, after the lock has been released, and reintroduces
the bug.
Duncan Murdoch
>
> I can see both sides of the argument, and some of my colleagues have
> worked extensively with both methodologies, but for a project that is
> updated 30-40 times a day, and in lots of places that are common, then
> working with the locking methodology has in experience been less prone
> to time wasted merging files and refixing bugs.
>
> -Graeme
>
>
>> -----Original Message-----
>> From: Andy Levy [mailto:andy.levy@gmail.com]
>> Sent: 05 December 2005 15:26
>> To: Thompson, Graeme (AELE)
>> Subject: Re: Checking out files to default to read-only
>>
>> On 12/5/05, Thompson, Graeme (AELE)
>> <Graeme.Thompson@smiths-aerospace.com> wrote:
>>
>> > On a further point - are there any plans to enhance
>> subversion to allow
>> > it to work in a lock/unlock system exclusively. i.e. to
>> work using the
>> > methodology applied with PVCS, VSS and other version
>> control systems?
>> >
>> > We have had issues with the merge methodology.
>> >
>> > I have read http://svnbook.red-bean.com/
>>
>> PVCS, VSS and others use Pessimistic Locking (exclusive locks - only
>> one person may make changes at any time). CVS, SVN, and most other
>> open-source version control systems use Optimistic Locking (anyone may
>> check out, edit, etc. and changes get merged together). That's simply
>> their design philosophy. This isn't an "enhancement", it's a
>> fundamental change in how the software works - and how the users of
>> the system work. The books should explain this.
>>
>> Is your issue with the merge methodology technical, or procedural? If
>> the latter, you must unlearn what you have learned with VSS and other
>> exclusive-lock systems.
>>
>> Coming from a VSS background, I much prefer SVN's optimistic locking.
>> Surely you've been in situations with your current system where
>> developers/users have left on vacation (or worse, left the company)
>> with files checked out and locked, thus stopping others from working
>> on them. Or even just needed to work on one function in a source file
>> while someone else is working on another. It's a major hassle under
>> VSS and similar systems. That problem disappears with optimistic
>> locking.
>>
>
> ******************************************
> The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
> ******************************************
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 17:31:27 2005