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

[Grierson, David]

From: Doug Robinson [mailto:doug.robin...@wandisco.com]
Sent: 13 June 2016 21:49
To: Johan Corveleyn 
Cc: Mark McKeown ; Andreas Stieger 
; users@subversion.apache.org
Subject: Re: which version control supports file locking and who has it locked

Johan:

On Mon, Jun 13, 2016 at 2:30 PM, Johan Corveleyn 
mailto:jcor...@gmail.com>> wrote:
On Mon, Jun 13, 2016 at 5:29 PM, Doug Robinson
mailto:doug.robin...@wandisco.com>> wrote:
>

I'm not sure about Perforce's implementation.  However, just for
comparison: with ClearCase Dynamic Views you can *not* edit the file
without a checkout.
[David Grierson] Not true … The default action for a checkout is reserved 
(locked), however there is nothing preventing users from checking out items 
unreserved and editing them.

In order to check a file back in, a reservation must be achieved before it will 
allow the checkin.

Information in this email including any attachments may be privileged, 
confidential and is intended exclusively for the addressee. The views expressed 
may not be official policy, but the personal views of the originator. If you 
have received it in error, please notify the sender by return e-mail and delete 
it from your system. You should not reproduce, distribute, store, retransmit, 
use or disclose its contents to anyone. Please note we reserve the right to 
monitor all e-mail communication through our internal and external networks. 
SKY and the SKY marks are trademarks of Sky plc and Sky International AG and 
are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited 
(Registration No. 2067075) and Sky Subscribers Services Limited (Registration 
No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 
2247735). All of the companies mentioned in this paragraph are incorporated in 
England and Wales and share the same registered office at Grant Way, Isleworth, 
Middlesex TW7 5QD.

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

[Johan Corveleyn]

On Mon, Jun 13, 2016 at 10:49 PM, Doug Robinson
 wrote:
>
> Johan:
>
> On Mon, Jun 13, 2016 at 2:30 PM, Johan Corveleyn  wrote:
>>
>> On Mon, Jun 13, 2016 at 5:29 PM, Doug Robinson
>>  wrote:
>> >
>> > Johan:
>> >
>> > The "svn lock" enables all people considering working with a file to
>> > be able to see who currently has the file locked.  But they cannot see
>> > anyone who is working on the file but does not own the lock.
>> >
>> > Reading the "p4 edit" man page:
>> >
>> > https://www.perforce.com/perforce/r16.1/manuals/cmdref/p4_edit.html
>> >
>> > we see that the expected use is "p4 edit; ; p4 submit" and that
>> > "p4 edit" updates the Perforce database to mark the file as being edited
>> > by that account in that workspace.  That means that any other Perforce
>> > user can see *all* of the other accounts working on that file (this is 
>> > *not*
>> > the same as a lock) by issuing the "p4 opened -a file" command.
>> >
>> > The ClearCase Dynamic View situation is pretty much the same as what
>> > I have described above for Perforce.
>>
>> Okay, so IIUC with "p4 edit" multiple users can start editing the file
>> (Alice, John and Jim), and they can all indicate concurrently that
>> they're editing the file, and other users can see that Alice, John and
>> Jim all have the file opened for editing. Interesting, but I fail to
>> see how that helps with non-mergeable files, where you want to lock it
>> out for one person to work on it at the same time.
>
>
> Or they can check to see who's editing it before checking it out.

Ah yes, that's true.

>>
>> Remember the question from the OP: "in Tortoise SVN, there is no
>> method of locking a file until it has been changed .
>> or knowing who is actually working on a file. is this feature
>> available on any other version control , GIT , CVS ?"
>
>
> There are 2 parts to that question:
> 1. no method of locking
> 2. no way to see who's actually working on the file
>
> The former is just wrong: SVN has locking and TortoiseSVN definitely
> has that implemented.

Agreed.

>>
>> He seems to be asking for locks, i.e. one developer locks it until he
>> has completed his change.
>
>
> I just didn't assume that the OP only was talking about locking.
> If they were then the 2nd comment is strange, but, well, ok.  Done.

Ack.

>> Apart from that: AFAICS the remark "But they cannot see anyone who is
>> working on the file but does not own the lock" applies to all systems
>> under discussion. With Perforce, I'm guessing that I can just as well
>> start editing the file with some text editor, outside of p4's
>> knowledge, right? That's just the same as starting to edit an
>> svn:needs-lock file without taking the svn lock (note that an
>> "svn:needs-lock file" is by default read-only on the filesystem in an
>> svn working copy, so you have to explicitly make it writeable).
>
>
> I'm not sure about Perforce's implementation.  However, just for
> comparison: with ClearCase Dynamic Views you can *not* edit the file
> without a checkout.  The Dynamic View implementation is via an actual
> OS file system so you can't beat it.  And everyone can see that checkout.

Okay, thanks for explaining.

-- 
Johan

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

[Doug Robinson]

Andrew:

Ah, eclipsed files. Yes, you can get truly creative with your config spec
and enable an eclipsed file.
And I agree there's always the person who copies things out and then back
in again.

You can't beat the MVFS simply by using file system commands (my point)...
but, you're right, with
enough knowledge you can work around the system.

In this case, they're likely being "smarter than themselves" - since
ultimately they're just delaying
the pain.

But nice points!

Doug

On Tue, Jun 14, 2016 at 1:10 PM, Andrew Reedick  wrote:

> > From: Doug Robinson [mailto:doug.robin...@wandisco.com]
> > Sent: Monday, June 13, 2016 4:49 PM
> > To: Johan Corveleyn
> > Cc: Mark McKeown; Andreas Stieger; users@subversion.apache.org
> > Subject: Re: which version control supports file locking and who has it
> locked
> >
> >
> > I'm not sure about Perforce's implementation.  However, just for
> > comparison: with ClearCase Dynamic Views you can *not* edit the file
> > without a checkout.  The Dynamic View implementation is via an actual
> > OS file system so you can't beat it.  And everyone can see that checkout.
>
>
> What about eclipsed files?
>
> And never forget that Someone can always copy the file out of the
> view/workspace to make changes to it because they're in a rush to leave for
> vacation.  Of course such a person, after coming back from vacation, would
> *never* copy their week old modified file back in to the workspace/view in
> order to check in their changes after the lock is released thus undoing the
> previous week's work of commits.
>
> Point is, you can't completely idiot proof anything because there's always
> one idiot who's smarter than you.
>
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@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 
<http://www.bloomberg.com/quote/WAND:LN>

THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.

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

[Andrew Reedick]

> From: Doug Robinson [mailto:doug.robin...@wandisco.com] 
> Sent: Monday, June 13, 2016 4:49 PM
> To: Johan Corveleyn
> Cc: Mark McKeown; Andreas Stieger; users@subversion.apache.org
> Subject: Re: which version control supports file locking and who has it locked
>
>
> I'm not sure about Perforce's implementation.  However, just for
> comparison: with ClearCase Dynamic Views you can *not* edit the file
> without a checkout.  The Dynamic View implementation is via an actual
> OS file system so you can't beat it.  And everyone can see that checkout.


What about eclipsed files?

And never forget that Someone can always copy the file out of the 
view/workspace to make changes to it because they're in a rush to leave for 
vacation.  Of course such a person, after coming back from vacation, would 
*never* copy their week old modified file back in to the workspace/view in 
order to check in their changes after the lock is released thus undoing the 
previous week's work of commits. 

Point is, you can't completely idiot proof anything because there's always one 
idiot who's smarter than you.

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

[Doug Robinson]

Johan:

On Mon, Jun 13, 2016 at 2:30 PM, Johan Corveleyn  wrote:

> On Mon, Jun 13, 2016 at 5:29 PM, Doug Robinson
>  wrote:
> >
> > Johan:
> >
> > The "svn lock" enables all people considering working with a file to
> > be able to see who currently has the file locked.  But they cannot see
> > anyone who is working on the file but does not own the lock.
> >
> > Reading the "p4 edit" man page:
> >
> > https://www.perforce.com/perforce/r16.1/manuals/cmdref/p4_edit.html
> >
> > we see that the expected use is "p4 edit; ; p4 submit" and
> that
> > "p4 edit" updates the Perforce database to mark the file as being edited
> > by that account in that workspace.  That means that any other Perforce
> > user can see *all* of the other accounts working on that file (this is
> *not*
> > the same as a lock) by issuing the "p4 opened -a file" command.
> >
> > The ClearCase Dynamic View situation is pretty much the same as what
> > I have described above for Perforce.
>
> Okay, so IIUC with "p4 edit" multiple users can start editing the file
> (Alice, John and Jim), and they can all indicate concurrently that
> they're editing the file, and other users can see that Alice, John and
> Jim all have the file opened for editing. Interesting, but I fail to
> see how that helps with non-mergeable files, where you want to lock it
> out for one person to work on it at the same time.
>

Or they can check to see who's editing it before checking it out.


> Remember the question from the OP: "in Tortoise SVN, there is no
> method of locking a file until it has been changed .
> or knowing who is actually working on a file. is this feature
> available on any other version control , GIT , CVS ?"
>

There are 2 parts to that question:
1. no method of locking
2. no way to see who's actually working on the file

The former is just wrong: SVN has locking and TortoiseSVN definitely
has that implemented.


> He seems to be asking for locks, i.e. one developer locks it until he
> has completed his change.
>

I just didn't assume that the OP only was talking about locking.
If they were then the 2nd comment is strange, but, well, ok.  Done.

Apart from that: AFAICS the remark "But they cannot see anyone who is
> working on the file but does not own the lock" applies to all systems
> under discussion. With Perforce, I'm guessing that I can just as well
> start editing the file with some text editor, outside of p4's
> knowledge, right? That's just the same as starting to edit an
> svn:needs-lock file without taking the svn lock (note that an
> "svn:needs-lock file" is by default read-only on the filesystem in an
> svn working copy, so you have to explicitly make it writeable).
>

I'm not sure about Perforce's implementation.  However, just for
comparison: with ClearCase Dynamic Views you can *not* edit the file
without a checkout.  The Dynamic View implementation is via an actual
OS file system so you can't beat it.  And everyone can see that checkout.

Doug


>
> --
> Johan
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.

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

[Johan Corveleyn]

On Mon, Jun 13, 2016 at 5:29 PM, Doug Robinson
 wrote:
>
> Johan:
>
> The "svn lock" enables all people considering working with a file to
> be able to see who currently has the file locked.  But they cannot see
> anyone who is working on the file but does not own the lock.
>
> Reading the "p4 edit" man page:
>
> https://www.perforce.com/perforce/r16.1/manuals/cmdref/p4_edit.html
>
> we see that the expected use is "p4 edit; ; p4 submit" and that
> "p4 edit" updates the Perforce database to mark the file as being edited
> by that account in that workspace.  That means that any other Perforce
> user can see *all* of the other accounts working on that file (this is *not*
> the same as a lock) by issuing the "p4 opened -a file" command.
>
> The ClearCase Dynamic View situation is pretty much the same as what
> I have described above for Perforce.

Okay, so IIUC with "p4 edit" multiple users can start editing the file
(Alice, John and Jim), and they can all indicate concurrently that
they're editing the file, and other users can see that Alice, John and
Jim all have the file opened for editing. Interesting, but I fail to
see how that helps with non-mergeable files, where you want to lock it
out for one person to work on it at the same time.

Remember the question from the OP: "in Tortoise SVN, there is no
method of locking a file until it has been changed .
or knowing who is actually working on a file. is this feature
available on any other version control , GIT , CVS ?"

He seems to be asking for locks, i.e. one developer locks it until he
has completed his change.

Apart from that: AFAICS the remark "But they cannot see anyone who is
working on the file but does not own the lock" applies to all systems
under discussion. With Perforce, I'm guessing that I can just as well
start editing the file with some text editor, outside of p4's
knowledge, right? That's just the same as starting to edit an
svn:needs-lock file without taking the svn lock (note that an
"svn:needs-lock file" is by default read-only on the filesystem in an
svn working copy, so you have to explicitly make it writeable).

-- 
Johan

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

[Doug Robinson]

Johan:

The "svn lock" enables all people considering working with a file to
be able to see who currently has the file locked.  But they cannot see
anyone who is working on the file but does not own the lock.

Reading the "p4 edit" man page:

https://www.perforce.com/perforce/r16.1/manuals/cmdref/p4_edit.html

we see that the expected use is "p4 edit; ; p4 submit" and that
"p4 edit" updates the Perforce database to mark the file as being edited
by that account in that workspace.  That means that any other Perforce
user can see *all* of the other accounts working on that file (this is *not*
the same as a lock) by issuing the "p4 opened -a file" command.

The ClearCase Dynamic View situation is pretty much the same as what
I have described above for Perforce.

Doug

On Sun, Jun 12, 2016 at 4:48 PM, Johan Corveleyn  wrote:

> [ Please no top-posting on this list. Preferably put your reply inline
> or at the bottom. I've reshuffled your replies a bit. More below. ]
>
> >> On Fri, Jun 10, 2016 at 8:15 PM, Doug Robinson <
> doug.robin...@wandisco.com> wrote:
> >>>
> >>> The dichotomy is due to the expression of "knowing who is actually
> working on a file".
> >>>
> >>> I agree that if locking is used then (assuming nobody breaks the lock)
> you know who will checkin next.  And, yes, agreed, when they check in is a
> social issue.
> >>>
> >>> However, you really don't know who is working on the file.  This may
> all seem meta-physical but I've seen requirements for SCM systems where it
> really was necessary to know exactly who was actually working on the file
> in their sandbox.  None of the discussed SCMs here support those semantics.
> >>>
> > On Fri, Jun 10, 2016 at 4:36 PM, Mark McKeown 
> wrote:
> >>
> >> Hi Doug,
> >>So if I remember correctly p4 supports this, when you
> "p4 edit" a file it will tell you if anyone else has already done "p4 edit"
> on the file.
> >>
> >> cheers
> >> Mark
> >>
> On Fri, Jun 10, 2016 at 10:42 PM, Doug Robinson
>  wrote:
> >
> > Mark:
> >
> > Nice.  And ClearCase with Dynamic Views as Brane reminded me.
> >
> > Doug
>
> I fail to see the difference between "p4 edit" and "svn lock" (or your
> IDE invoking "svn lock" automatically when you start editing a file
> marked with svn:needs-lock). Can someone explain?
>
> I don't know Perforce, but from an "information transfer" point of
> view it sounds the same to me.
>
> If a developer has a file locked in SVN (indicated by a lock token
> noted on the server), I suppose they have the intention to edit, and
> commit sometime later. I'm guessing p4 also holds some lock token
> centrally when someone has 'p4 edit'ed the file (which sounds like an
> intention to edit the file), until the developer commits. Tomatoes,
> tomatoes ...
>
> (I know even less about ClearCase Dynamic Views than I know about
> Perforce, so I won't try to guess what that does ...)
>
> --
> Johan
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.

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

[Johan Corveleyn]

[ Please no top-posting on this list. Preferably put your reply inline
or at the bottom. I've reshuffled your replies a bit. More below. ]

>> On Fri, Jun 10, 2016 at 8:15 PM, Doug Robinson  
>> wrote:
>>>
>>> The dichotomy is due to the expression of "knowing who is actually working 
>>> on a file".
>>>
>>> I agree that if locking is used then (assuming nobody breaks the lock) you 
>>> know who will checkin next.  And, yes, agreed, when they check in is a 
>>> social issue.
>>>
>>> However, you really don't know who is working on the file.  This may all 
>>> seem meta-physical but I've seen requirements for SCM systems where it 
>>> really was necessary to know exactly who was actually working on the file 
>>> in their sandbox.  None of the discussed SCMs here support those semantics.
>>>
> On Fri, Jun 10, 2016 at 4:36 PM, Mark McKeown  
> wrote:
>>
>> Hi Doug,
>>So if I remember correctly p4 supports this, when you "p4 
>> edit" a file it will tell you if anyone else has already done "p4 edit" on 
>> the file.
>>
>> cheers
>> Mark
>>
On Fri, Jun 10, 2016 at 10:42 PM, Doug Robinson
 wrote:
>
> Mark:
>
> Nice.  And ClearCase with Dynamic Views as Brane reminded me.
>
> Doug

I fail to see the difference between "p4 edit" and "svn lock" (or your
IDE invoking "svn lock" automatically when you start editing a file
marked with svn:needs-lock). Can someone explain?

I don't know Perforce, but from an "information transfer" point of
view it sounds the same to me.

If a developer has a file locked in SVN (indicated by a lock token
noted on the server), I suppose they have the intention to edit, and
commit sometime later. I'm guessing p4 also holds some lock token
centrally when someone has 'p4 edit'ed the file (which sounds like an
intention to edit the file), until the developer commits. Tomatoes,
tomatoes ...

(I know even less about ClearCase Dynamic Views than I know about
Perforce, so I won't try to guess what that does ...)

-- 
Johan

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

[Doug Robinson]

Mark:

Nice.  And ClearCase with Dynamic Views as Brane reminded me.

Doug

On Fri, Jun 10, 2016 at 4:36 PM, Mark McKeown 
wrote:

> Hi Doug,
>So if I remember correctly p4 supports this, when you "p4
> edit" a file it will tell you if anyone else has already done "p4 edit" on
> the file.
>
> cheers
> Mark
>
> On Fri, Jun 10, 2016 at 8:15 PM, Doug Robinson  > wrote:
>
>> The dichotomy is due to the expression of "knowing who is actually
>> working on a file".
>>
>> I agree that if locking is used then (assuming nobody breaks the lock)
>> you know who will checkin next.  And, yes, agreed, when they check in is a
>> social issue.
>>
>> However, you really don't know who is working on the file.  This may all
>> seem meta-physical but I've seen requirements for SCM systems where it
>> really was necessary to know exactly who was actually working on the file
>> in their sandbox.  None of the discussed SCMs here support those semantics.
>>
>> On Mon, Jun 6, 2016 at 12:17 PM, Andreas Stieger 
>> wrote:
>>
>>> Doug,
>>>
>>> Doug Robinson wrote:
>>> > 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).
>>>
>>> I am not sure why you would introduce this dichotomy here, it is
>>> irrelevant. OP asked for locking support. Subversion supports locking, lock
>>> hinting (svn:needs-lock), lock communication/discovery (display of who,
>>> when and why). In the cli, hooks and GUI clients. Whether or not actual
>>> changes were done in any working copy is irrelevant, and a delay in
>>> submission a mere social/project problem.
>>>
>>> > 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.
>>>
>>> Rather, if the project policy is such that locking is required, it
>>> should be implemented accordingly. lock-modify-unlock for the whole project
>>> is a supported option, albeit not a commonly used one.
>>>
>>> Andreas
>>>
>>
>>
>>
>> --
>> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>>
>> *T *925-396-1125
>> *E* doug.robin...@wandisco.com
>>
>> *www.wandisco.com *
>>
>>
>> Learn how WANdisco Fusion solves Hadoop data protection and scalability
>> challenges 
>>
>> Listed on the London Stock Exchange: WAND
>> 
>>
>> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY
>> BE 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 passed.
>>
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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

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

[Mark McKeown]

Hi Doug,
   So if I remember correctly p4 supports this, when you "p4
edit" a file it will tell you if anyone else has already done "p4 edit" on
the file.

cheers
Mark

On Fri, Jun 10, 2016 at 8:15 PM, Doug Robinson 
wrote:

> The dichotomy is due to the expression of "knowing who is actually
> working on a file".
>
> I agree that if locking is used then (assuming nobody breaks the lock) you
> know who will checkin next.  And, yes, agreed, when they check in is a
> social issue.
>
> However, you really don't know who is working on the file.  This may all
> seem meta-physical but I've seen requirements for SCM systems where it
> really was necessary to know exactly who was actually working on the file
> in their sandbox.  None of the discussed SCMs here support those semantics.
>
> On Mon, Jun 6, 2016 at 12:17 PM, Andreas Stieger 
> wrote:
>
>> Doug,
>>
>> Doug Robinson wrote:
>> > 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).
>>
>> I am not sure why you would introduce this dichotomy here, it is
>> irrelevant. OP asked for locking support. Subversion supports locking, lock
>> hinting (svn:needs-lock), lock communication/discovery (display of who,
>> when and why). In the cli, hooks and GUI clients. Whether or not actual
>> changes were done in any working copy is irrelevant, and a delay in
>> submission a mere social/project problem.
>>
>> > 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.
>>
>> Rather, if the project policy is such that locking is required, it should
>> be implemented accordingly. lock-modify-unlock for the whole project is a
>> supported option, albeit not a commonly used one.
>>
>> Andreas
>>
>
>
>
> --
> *DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER
>
> *T *925-396-1125
> *E* doug.robin...@wandisco.com
>
> *www.wandisco.com *
>
>
> Learn how WANdisco Fusion solves Hadoop data protection and scalability
> challenges 
>
> Listed on the London Stock Exchange: WAND
> 
>
> THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
> 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 passed.
>

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.

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

[Doug Robinson]

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  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  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."
>>
>
>


-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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

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

[Doug Robinson]

Jan:

Thanks for the note about CVS watches.  I was unaware of that feature.
Interesting.

I agree, such a feature would tend to go directly against the requirements
for a DVCS.

Doug

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."
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.

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

[Doug Robinson]

Brane:

You're right!  ClearCase with dynamic views would provide that data (files
could not be modified unless checked out and the checkouts left markers in
the database).  You could even see "who" from other replicas (assuming
proper synchronization).

Agreed: you could not see what changes they were making unless you had
access to their view.

Thank you.

Doug

On Tue, Jun 7, 2016 at 9:54 AM, Branko Čibej  wrote:

> On 06.06.2016 15:47, Doug Robinson wrote:
> > Andreas:
> >
> > On Mon, Jun 6, 2016 at 3:50 AM, Andreas Stieger
> > mailto: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.
>
>
> I believe ClearCase with dynamic views could do that, but even that
> couldn't show diffs from someone else's view (since while the view was
> stored on the server, the actual changes were only stored locally on the
> client).
>
> -- Brane
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.

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

[Doug Robinson]

The dichotomy is due to the expression of "knowing who is actually working
on a file".

I agree that if locking is used then (assuming nobody breaks the lock) you
know who will checkin next.  And, yes, agreed, when they check in is a
social issue.

However, you really don't know who is working on the file.  This may all
seem meta-physical but I've seen requirements for SCM systems where it
really was necessary to know exactly who was actually working on the file
in their sandbox.  None of the discussed SCMs here support those semantics.

On Mon, Jun 6, 2016 at 12:17 PM, Andreas Stieger 
wrote:

> Doug,
>
> Doug Robinson wrote:
> > 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).
>
> I am not sure why you would introduce this dichotomy here, it is
> irrelevant. OP asked for locking support. Subversion supports locking, lock
> hinting (svn:needs-lock), lock communication/discovery (display of who,
> when and why). In the cli, hooks and GUI clients. Whether or not actual
> changes were done in any working copy is irrelevant, and a delay in
> submission a mere social/project problem.
>
> > 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.
>
> Rather, if the project policy is such that locking is required, it should
> be implemented accordingly. lock-modify-unlock for the whole project is a
> supported option, albeit not a commonly used one.
>
> Andreas
>



-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.

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

[Mark Phippard]

On Mon, Jun 6, 2016 at 9:47 AM, 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.
>
>
I am surprised this was left unchallenged.  I assumed someone would correct
this, so I did not.

SVN does support this feature .. if you use locking.

http://svnbook.red-bean.com/nightly/en/svn.advanced.locking.html

If you are using this feature and someone locks a file before editing it,
then you can in fact see this information.  The issue is that the SVN
client and working copy is still more or less disconnected from the
server.  So you do have to manage lock communication in some manner.  If
the user chooses to connect to the server they can see that there is an
active lock on a file but in the more normal disconnected state then they
would not see this until they attempted to acquire a lock on the file.

I would imagine using the lock hooks to post some kind of notification when
a file is locked to enable a more pro-active communication.

The only clients that can handle this better than SVN are ones where the
client is always connected to a central server.  Then the client can always
show the current lock state of a file and that it is being edited.  SVN
clients only connect when you ask them to (svn update etc.)

For a TSVN users that wants locking, they should set the svn:needs-lock
property on all files that should be locked before editing.  This will set
the file to read-only in the working copy so that you know to lock the file
before editing.  IDE integrations like Subclipse and AnkhSVN will do this
automatically when you attempt to edit the file.

TSVN can then see locks that are held on files if you look on the server.
I believe doing an update will also bring this information into the working
copy but I could be wrong.  Regardless, when you edit a file and thus try
to lock it you will see that it is locked to another user.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

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

[Andreas Mohr]

On Wed, Jun 08, 2016 at 09:42:10AM -0400, Boris Epstein 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.

Binary files, I guess.

Not that you would want to have all too many of these in an SCM, but...
(...if even Red Hat seems to think that it's fashionable to do project
collaboration via binary files... -
https://opensource.com/open-organization/16/6/introducing-open-decision-framework
)

Andreas Mohr

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

[Boris Epstein]

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."
>

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

[Branko Čibej]

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


I believe ClearCase with dynamic views could do that, but even that
couldn't show diffs from someone else's view (since while the view was
stored on the server, the actual changes were only stored locally on the
client).

-- Brane

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

[Andreas Stieger]

Doug,
 
Doug Robinson wrote:
> 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). 

I am not sure why you would introduce this dichotomy here, it is irrelevant. OP 
asked for locking support. Subversion supports locking, lock hinting 
(svn:needs-lock), lock communication/discovery (display of who, when and why). 
In the cli, hooks and GUI clients. Whether or not actual changes were done in 
any working copy is irrelevant, and a delay in submission a mere social/project 
problem.

> 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.

Rather, if the project policy is such that locking is required, it should be 
implemented accordingly. lock-modify-unlock for the whole project is a 
supported option, albeit not a commonly used one.

Andreas

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

[Ræstad Atle Eivind]

> 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.
> 
> Doug
>

The original question was:
> in Tortoise SVN, there is no method of locking a file until it has been 
> changed .
> or knowing who is actually working on a file.
> is this feature available on any other version control , GIT , CVS ?

If you are using the locking feature it is possible to see who is working on 
the file. See  
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html for a 
description for TortoiseSVN.

/Atle

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

[Jan Keirse]

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."

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

[Doug Robinson]

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.

Doug
-- 
*DOUGLAS B. ROBINSON* SENIOR PRODUCT MANAGER

*T *925-396-1125
*E* doug.robin...@wandisco.com

*www.wandisco.com *

-- 


Learn how WANdisco Fusion solves Hadoop data protection and scalability 
challenges 

Listed on the London Stock Exchange: WAND 


THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE 
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 
passed.