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]

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 *

-- 


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 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: Is there a way to 'sparsify' a working copy, without starting over?

[Johan Corveleyn]

On Mon, Jun 13, 2016 at 10:52 AM, Daniel Shahaf  wrote:
> Johan Corveleyn wrote on Mon, Jun 13, 2016 at 10:04:13 +0200:
>> But if you have local moves, it seems the 'Delete' part of the move is
>> lost when updating to depth empty, and the move is broken (converted
>> into just the A+ of the "Add" part).
>>
>> This looks like a bug in "update --set-depth" (losing information
>> about local deletes (potentially part of a move)).
>> Other than that, this technique seems to work fine.
>
> Is the bug specific to --set-depth?  It sounds like a delete-delete tree
> conflict, in which case, I would expect the following scenario to
> trigger the same behaviour:
>
> # greek tree
> svnadmin create r
> svn co -q file://$PWD/r wc
> cd wc
> touch iota
> svn add -q iota
> svn ci -q -m r1
> svn up -q
> # scenario:
> svn rm -q -m r2 ^/iota
> svn mv -q iota kappa
> svn up
>
> Sorry, I can't test this right now...

No it doesn't trigger this behaviour. This gives a delete-delete tree
conflict, as expected.

But watch this:

[[[
C:\svntest>svnadmin create r

C:\svntest>svn co -q file:///c:/svntest/r wc

C:\svntest>cd wc

C:\svntest\wc>touch iota

C:\svntest\wc>svn add -q iota

C:\svntest\wc>svn ci -q -m r1

C:\svntest\wc>svn up -q

C:\svntest\wc>svn mv iota kappa
A kappa
D iota

C:\svntest\wc>svn st
D   iota
> moved to kappa
A  +kappa
> moved from iota

C:\svntest\wc>svn up --set-depth empty
D iota
Updating '.':
Updated to revision 1.

C:\svntest\wc>svn st
A  +kappa
]]]

Oops. Delete information is lost, and with it also the move information.

I don't think this should raise a tree conflict (just like when iota
is 'M', and you execute 'svn up --set-depth empty', the modified iota
is just left there as a part of the sparse tree -- no delete-edit
conflict is raised). So I think it should just leave the 'D's (and
move information) there. The "emptying" seems to be optional, IIUC the
intention is that anything that's modified in some way should be left
alone (which is cool when sparsifying).

The above scenario looks like a bug, no?

-- 
Johan

Segmentation fault in "svn resolve"

[Gustavo Chaves]

I got a "segmentation fault" while performing a "svn resolve" to resolve a
conflict in a file with the svn:mime-type property set to
application/octet-stream. I got the same error using the WANdisco packages
for svn-1.9.4 at RHEL and using Ubuntu 16.04 native package for svn-1.9.3.

I was able to reproduce the problem in a small scale following the steps
below, in my Ubuntu 16.04 machine.

Should I open an issue?

-- 
Gustavo.

Script started on Tue Jun 14 19:26:20 2016

$ type svn
svn is /usr/bin/svn

$ dpkg -S /usr/bin/svn
subversion: /usr/bin/svn

$ dpkg -l subversion | tail -1
ii  subversion  1.9.3-2ubuntu1 amd64 Advanced version control system

$ ulimit -c unlimited

$ svnadmin create repo

$ svn mkdir file://$PWD/repo/{trunk,branches,tags} -m'start'
Committing transaction...
Committed revision 1.

$ svn co file://$PWD/repo/trunk wc
Checked out revision 1.

$ cd wc
/home/gustavo/tmp/svn/bug/wc

$ echo asdf >file

$ svn add file
A file

$ svn ps svn:mime-type application/octet-stream file
svn: warning: 'application/octet-stream' is a binary mime-type but file
'/home/gustavo/tmp/svn/bug/wc/file' looks like text; diff, merge, blame,
and other operations will stop working on this file
property 'svn:mime-type' set on 'file'

$ svn ci -m'add file'
Adding  (bin)  file
Transmitting file data .done
Committing transaction...
Committed revision 2.

$ svn cp ^/trunk ^/branches/b -m'create branch'
Committing transaction...
Committed revision 3.

$ echo trunk >>file

$ svn ci -m'add line in trunk'
Sendingfile
Transmitting file data .done
Committing transaction...
Committed revision 4.

$ svn switch ^/branches/b
Ufile
Updated to revision 4.

$ echo branch >>file

$ svn ci -m'add line in branch'
Sendingfile
Transmitting file data .done
Committing transaction...
Committed revision 5.

$ svn up
Updating '.':
At revision 5.

$ svn merge ^/trunk
--- Merging r3 through r5 into '.':
Cfile
--- Recording mergeinfo for merge of r3 through r5 into '.':
 U   .
Summary of conflicts:
  Text conflicts: 1

$ svn status
 M  .
C   file
?   file.merge-left.r2
?   file.merge-right.r5
Summary of conflicts:
  Text conflicts: 1

$ svn resolve --accept mine-conflict file
Segmentation fault (core dumped)

$ ls -l
total 3604
-rw--- 1 gustavo gustavo 3678208 Jun 14 19:31 core
-rw-rw-r-- 1 gustavo gustavo  12 Jun 14 19:29 file
-rw--- 1 gustavo gustavo   5 Jun 14 19:30 file.merge-left.r2
-rw--- 1 gustavo gustavo  11 Jun 14 19:30 file.merge-right.r5

$ gdb /usr/lib/debug/usr/bin/svn core
GNU gdb (Ubuntu 7.11-0ubuntu1) 7.11
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/debug/usr/bin/svn...done.
[New LWP 25527]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `svn resolve --accept mine-conflict file'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
106 ../sysdeps/x86_64/strlen.S: No such file or directory.
(gdb) bt
#0  strlen () at ../sysdeps/x86_64/strlen.S:106
#1  0x7faf2a27066d in check_cstring_utf8 (data=data@entry=0x0,
pool=pool@entry=0x7faf2b241028) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/utf.c:676
#2  0x7faf2a270c3c in svn_utf_cstring_from_utf8
(dest=dest@entry=0x7ffcb44752f0,
src=src@entry=0x0, pool=pool@entry=0x7faf2b241028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/utf.c:901
#3  0x7faf2a25cbe6 in svn_path_cstring_from_utf8
(path_apr=path_apr@entry=0x7ffcb44752f0, path_utf8=path_utf8@entry=0x0,
pool=pool@entry=0x7faf2b241028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/path.c:1141
#4  0x7faf2a24dfa8 in cstring_from_utf8 (pool=0x7faf2b241028,
path_utf8=0x0, path_apr=0x7ffcb44752f0) at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/io.c:221
#5  svn_io_file_open (new_file=new_file@entry=0x7ffcb44759f8, fname=0x0,
flag=flag@entry=1, perm=perm@entry=4095, pool=0x7faf2b241028)
at
/build/subversion-yttRtj/subversion-1.9.3/subversion/libsvn_subr/io.c:3654
#6  0x7faf2a525cd6 in datasources_open (baton=0x7ffcb44759a0,
prefix_lines=0x7ffcb44758d0, suffix_lines=0x7ffcb44758d8,
datasources=0x7ffcb44758e0, datasources_len=3)
at
/build/subv