[ 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.robinson_at_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 <mark.mckeown_at_wandisco.com> 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
<doug.robinson_at_wandisco.com> 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
Received on 2016-06-12 22:48:30 CEST