Hi Markus, Please see my comments below.
On Tue, Jul 29, 2014 at 07:59 AM PDT, Markus Schaber wrote: MS> Hi, MS> MS> Von: Markus Schaber [mailto:m.scha...@codesys.com] MS> > Von: Niemann, Hartmut [mailto:hartmut.niem...@siemens.com] MS> > > > -----Ursprüngliche Nachricht----- MS> > > > Von: Mun Johl [mailto:mun.j...@emulex.com] MS> > > [...] MS> > > > As a test, I made a small change to the file and attempted a MS> > > > check-in (w/o first locking the file). To my surprise, the file MS> > > > update was applied! MS> > > > MS> > > > Is this a known bug with the version of SVN I'm using? MS> > > > MS> > > > Are my expectations incorrect? That is, am I doing something MS> > > > incorrectly if I want a user to have to lock the file prior to MS> > > > check- in? MS> > > MS> > > I did some experiments recently. It looked like you don't need the MS> > > lock for a commit, but if some other working copy has a lock, you MS> > > won't be allowed to commit. (I am not totally sure, though) MS> > MS> > The rule is: If the server (=repository) knows about a lock for that file, MS> > one can only commit with the matching lock token. MS> > MS> > Working copies store the lock token when one locks a file there. However, MS> > this information can get out of sync, for example by: MS> > MS> > - "stealing" a lock using "--force", the old working copy still has the stale MS> > lock token. MS> > MS> > - Removing a lock on the server using svnadmin. MS> > MS> > - Duplicating the working copy (e. G. using "copy" on the shell or zipping it MS> > together and unpacking on a different machine) - then the first one to commit MS> > or unlock has a valid token, while the other one does not have a valid token. MS> > MS> > - Restoring an old working copy from a backup - the working copy may still MS> > have stale lock tokens for locks which were removed in the meantime. MS> > MS> > (This list is non-exhaustive.) MS> MS> I forgot to tell the effects of the svn:needs-lock property: This tells most MS> clients that this object should be locked before it can be modified. Some MS> svn clients like the command line client honor it by setting the read-only MS> flag (or removing the writeable-permission bit) on the file during checkout MS> or update, and making the file writeable as a side-effect of acquiring a lock MS> for that file. I appreciate you taking the time to explain the algorithms pertinent to my issue. The information provided was helpful. Thanks very much, -- Mun
