Re: AW: SVN is ignoring needs-lock property

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.schaber_at_codesys.com]
MS> > Von: Niemann, Hartmut [mailto:hartmut.niemann_at_siemens.com]
MS> > > > -----Ursprüngliche Nachricht-----
MS> > > > Von: Mun Johl [mailto:Mun.Johl_at_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