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 wrote:
>
> On Mon, Jun 6, 2016 at 3:47 PM, Doug Robinson
> wrote:
>
>> Andreas:
>>
>> On Mon, Jun 6, 2016 at 3:50 AM, Andreas Stieger
>> 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."
>
