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

Re: which version control supports file locking and who has it locked

From: Doug Robinson <doug.robinson_at_wandisco.com>
Date: Fri, 10 Jun 2016 15:33:02 -0400

Agreed on ClearCase.

As for locking, it is normally considered "absolutely essential" for files
that "do not merge". Think checking in binaries. Or ugly generated XML
files (using unhappy algorithms). Pick your favorite non-merge-capable
file type(s). The point is to prevent multiple people from changing them
at the same time - or at least enable them to attempt to coordinate the
changes so nothing is lost.

On Wed, Jun 8, 2016 at 9:42 AM, Boris Epstein <borepstein_at_gmail.com> wrote:

> I believe ClearCase does that.
> If I may ask, why is it important? I believe CVS, SVN, Git and many others
> allow to get your edits in via merging mechanisms of various kinds, so I am
> just curious what the use case scenario would be where locking is
> absolutely essential.
> Cheers,
> Boris.
> On Mon, Jun 6, 2016 at 10:19 AM, Jan Keirse <jan.keirse_at_tvh.com> wrote:
>> On Mon, Jun 6, 2016 at 3:47 PM, Doug Robinson <doug.robinson_at_wandisco.com
>> > wrote:
>>> Andreas:
>>> On Mon, Jun 6, 2016 at 3:50 AM, Andreas Stieger <Andreas.Stieger_at_gmx.de>
>>> wrote:
>>>> > or knowing who is actually working on a file.
>>>> Incorrect, this is shown in both TortoiseSVN and svn cli.
>>> To be more precise, you can know who, in the past, has made changes to
>>> files
>>> *and*checked those change into the repository. You cannot know who has
>>> made changes
>>> in their working copy and has not yet checked them back into the
>>> repository (they
>>> may never do so).
>>> To know who is actually working on a file requires a level of
>>> integration that is not
>>> found in SVN, Git or CVS. I have a vague recollection of an SCM that
>>> did enable
>>> such information but I'm not remembering which one it is at the moment.
>> ​Whether it is possible to know who is working on a file is not the same
>> as what the changes made so far in the working copy are. This IS possible
>> without much problems with at least CVS with minor effort: By setting a
>> watch on a module alle files in that module are checked out read only.
>> Before changing a file one uses the CVS edit command, that takes care of
>> making the file read/write and keep track of who edits what. I'm not
>> entirely sure if this is the behavior the SVN implementation supports.
>> Off course it is possible to ignore the read-only flag and use operating
>> system tools to overwrite them without first using the edit command, but as
>> long as everyone involved knows the tools this works very well and
>> accidents are unlikely because files are read-only by default. The only
>> problem might be you only find out you had not yet edited a file the first
>> time you save changes and fixing that requires either a habit change (the
>> new habit being either first edit or save early, save often, which is a
>> good idea anyway) or a simple trigger in your IDE.
>> We have used this CVS feature with success in the past for source files
>> that require 'exclusive edits' because merging was next-to-impossible (as
>> would be the case for many binary file.) When we migrated to Subversion for
>> unrelated reasons I couldn't quite get it to work like we wanted (if I
>> remember correctly taking a lock was more on a voluntary basis, you
>> couldn't make the files read-only by default and therefore accidentally
>> forgetting to lock was far more likely.) So I ended up implementing an edit
>> trigger in the IDE to handle this, which works fine for our use case but
>> might not be possible in other setups.
>> I don't see how it could be implemented in a DVCS though, at least not
>> without a non-distributed part added to it which defeats at least some of
>> its purpose.
>> As for other systems supporting this functionality, to answer the
>> original question: At least Microsoft TFS and Roundtable TSMS (a platform
>> intended specifically for OpenEdge ABL) support it to some extent. This
>> being said, I wouldn't pick any of these or CVS over something like
>> Subversion, GIT or Mercurial if I were to make the choice.
>> **** DISCLAIMER ****
>> http://www.tvh.com/glob/en/email-disclaimer
>> "This message is delivered to all addressees subject to the conditions
>> set forth in the attached disclaimer, which is an integral part of this
>> message."

*T *925-396-1125
*E* doug.robinson_at_wandisco.com
*www.wandisco.com <http://www.wandisco.com/>*
Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges <http://www.wandisco.com/hadoop/wd-fusion>
Listed on the London Stock Exchange: WAND 
PRIVILEGED.  If this message was misdirected, WANdisco, Inc. and its 
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege. 
 If you are not the intended recipient, please notify us immediately and 
destroy the message without disclosing its contents to anyone.  Any 
distribution, use or copying of this e-mail or the information it contains 
by other than an intended recipient is unauthorized.  The views and 
opinions expressed in this e-mail message are the author's own and may not 
reflect the views and opinions of WANdisco, unless the author is authorized 
by WANdisco to express such views or opinions on its behalf.  All email 
sent to or from this address is subject to electronic storage and review by 
WANdisco.  Although WANdisco operates anti-virus programs, it does not 
accept responsibility for any damage whatsoever caused by viruses being 
Received on 2016-06-10 21:33:10 CEST

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.