[ 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 <mark.mcke...@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.robin...@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
