AW: SVN is ignoring needs-lock property
> -Ursprüngliche Nachricht- > Von: Mun Johl [mailto:mun.j...@emulex.com] [...] > As a test, I made a small change to the file and attempted a check-in > (w/o first locking the file). To my surprise, the file update was > applied! > > Is this a known bug with the version of SVN I'm using? > > Are my expectations incorrect? That is, am I doing something > incorrectly if I want a user to have to lock the file prior to check- > in? I did some experiments recently. It looked like you don't need the lock for a commit, but if some other working copy has a lock, you won't be allowed to commit. (I am not totally sure, though) Mit freundlichen Grüßen Dr. Hartmut Niemann
AW: SVN is ignoring needs-lock property
Hi, Von: Niemann, Hartmut [mailto:hartmut.niem...@siemens.com] > > -Ursprüngliche Nachricht- > > Von: Mun Johl [mailto:mun.j...@emulex.com] > [...] > > As a test, I made a small change to the file and attempted a check-in > > (w/o first locking the file). To my surprise, the file update was > > applied! > > > > Is this a known bug with the version of SVN I'm using? > > > > Are my expectations incorrect? That is, am I doing something > > incorrectly if I want a user to have to lock the file prior to check- > > in? > > I did some experiments recently. It looked like you don't need the lock for a > commit, but if some other working copy has a lock, you won't be allowed to > commit. (I am not totally sure, though) The rule is: If the server (=repository) knows about a lock for that file, one can only commit with the matching lock token. Working copies store the lock token when one locks a file there. However, this information can get out of sync, for example by: - "stealing" a lock using "--force", the old working copy still has the stale lock token. - Removing a lock on the server using svnadmin. - Duplicating the working copy (e. G. using "copy" on the shell or zipping it together and unpacking on a different machine) - then the first one to commit or unlock has a valid token, while the other one does not have a valid token. - Restoring an old working copy from a backup - the working copy may still have stale lock tokens for locks which were removed in the meantime. (This list is non-exhaustive.) Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
AW: SVN is ignoring needs-lock property
Hi, Von: Markus Schaber [mailto:m.scha...@codesys.com] > Von: Niemann, Hartmut [mailto:hartmut.niem...@siemens.com] > > > -Ursprüngliche Nachricht- > > > Von: Mun Johl [mailto:mun.j...@emulex.com] > > [...] > > > As a test, I made a small change to the file and attempted a > > > check-in (w/o first locking the file). To my surprise, the file > > > update was applied! > > > > > > Is this a known bug with the version of SVN I'm using? > > > > > > Are my expectations incorrect? That is, am I doing something > > > incorrectly if I want a user to have to lock the file prior to > > > check- in? > > > > I did some experiments recently. It looked like you don't need the > > lock for a commit, but if some other working copy has a lock, you > > won't be allowed to commit. (I am not totally sure, though) > > The rule is: If the server (=repository) knows about a lock for that file, > one can only commit with the matching lock token. > > Working copies store the lock token when one locks a file there. However, > this information can get out of sync, for example by: > > - "stealing" a lock using "--force", the old working copy still has the stale > lock token. > > - Removing a lock on the server using svnadmin. > > - Duplicating the working copy (e. G. using "copy" on the shell or zipping it > together and unpacking on a different machine) - then the first one to commit > or unlock has a valid token, while the other one does not have a valid token. > > - Restoring an old working copy from a backup - the working copy may still > have stale lock tokens for locks which were removed in the meantime. > > (This list is non-exhaustive.) I forgot to tell the effects of the svn:needs-lock property: This tells most clients that this object should be locked before it can be modified. Some svn clients like the command line client honor it by setting the read-only flag (or removing the writeable-permission bit) on the file during checkout or update, and making the file writeable as a side-effect of acquiring a lock for that file. Best regards Markus Schaber CODESYS® a trademark of 3S-Smart Software Solutions GmbH Inspiring Automation Solutions 3S-Smart Software Solutions GmbH Dipl.-Inf. Markus Schaber | Product Development Core Technology Memminger Str. 151 | 87439 Kempten | Germany Tel. +49-831-54031-979 | Fax +49-831-54031-50 E-Mail: m.scha...@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com CODESYS forum: http://forum.codesys.com Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.
Re: AW: SVN is ignoring needs-lock property
Hi, Thank you for your reply. Please see my comments below. On Tue, Jul 29, 2014 at 07:30 AM PDT, Niemann, Hartmut wrote: NH> > -Ursprüngliche Nachricht- NH> > Von: Mun Johl [mailto:mun.j...@emulex.com] NH> [...] NH> > As a test, I made a small change to the file and attempted a check-in NH> > (w/o first locking the file). To my surprise, the file update was NH> > applied! NH> > NH> > Is this a known bug with the version of SVN I'm using? NH> > NH> > Are my expectations incorrect? That is, am I doing something NH> > incorrectly if I want a user to have to lock the file prior to check- NH> > in? NH> NH> I did some experiments recently. It looked like NH> you don't need the lock for a commit, but if some other working copy has a lock, NH> you won't be allowed to commit. (I am not totally sure, though) I have confirmed your results. My experiments had the same results. Knowing the behavior is helpful. Thanks. Regards, -- Mun
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.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
Re: SVN is ignoring needs-lock property
Hi Andreas, Please see my comments below. On Mon, Jul 28, 2014 at 03:04 PM PDT, Andreas Stieger wrote: AS>Hi, AS>On 28 Jul 2014, at 22:38, Mun Johl wrote: AS> AS> I have an XML file checked in with the svn:needs-lock property set. I AS> verified that the permissions on the file in the filesystem do not AS> include write permission. AS> As a test, I made a small change to the file and attempted a check-in AS> (w/o first locking the file). To my surprise, the file update was AS> applied! AS> Is this a known bug with the version of SVN I'm using? AS> Are my expectations incorrect? AS> AS>See http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html#svn.advanced.locking.lock-communication AS>The property indicates to clients that the item should, not must, be locked. It is, along with AS>locks, a communication tool to synchronise edits to files which are not textually merge-able. AS>Most clients support this and prompt the use to acquire a lock. AS> AS> That is, am I doing something AS> incorrectly if I want a user to have to lock the file prior to check-in? AS> AS>You mean prior to editing? AS>You may attempt to enforce locking via hooks but that would undermine the concepts of AS>breakable / steal-able locks in svn. I am in fact planning on using a pre-commit hook for our needs. Thanks, -- Mun
