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
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 abl
binson [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
> >
> 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
>
>
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
> > any
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
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/p
[ 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
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
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 ac
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 fr
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:
>
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
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 t
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 pa
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 sce
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, J
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 c
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
> 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
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 pa
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 repos
Hi,
> in Tortoise SVN, there is no method of locking a file until it has been
> changed .
Incorrect. locking, requiring locking and lock communication are supported by
both plain svn and TortoiseSVN.
https://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-locking.html
http://svnbook.red-b
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 ?
Thanks
24 matches
Mail list logo
