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.kei...@tvh.com> wrote: > > On Mon, Jun 6, 2016 at 3:47 PM, Doug Robinson <doug.robin...@wandisco.com> > wrote: > >> Andreas: >> >> On Mon, Jun 6, 2016 at 3:50 AM, Andreas Stieger <andreas.stie...@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." >
