You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Mun Johl <Mu...@Emulex.Com> on 2014/07/28 23:38:20 UTC
SVN is ignoring needs-lock property
Hi,
I'm using:
SNV version 1.6.17
CentOS 6.4
I have an XML file checked in with the svn:needs-lock property set. I
verified that the permissions on the file in the filesystem do not
include write permission.
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?
Here is the output of proplist for the file in question:
------------------------------ Delimiter BEGIN --------------------------------
$ svn -v proplist test.xml
Properties on 'test.xml':
svn:executable
*
svn:needs-lock
*
------------------------------- Delimiter END ---------------------------------
Thanks,
--
Mun
Re: SVN is ignoring needs-lock property
Posted by Mun Johl <Mu...@Emulex.Com>.
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 <Mu...@Emulex.Com> 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
Re: SVN is ignoring needs-lock property
Posted by Andreas Stieger <an...@gmx.de>.
Hi,
> On 28 Jul 2014, at 22:38, Mun Johl <Mu...@Emulex.Com> wrote:
>
> I have an XML file checked in with the svn:needs-lock property set. I
> verified that the permissions on the file in the filesystem do not
> include write permission.
>
> 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?
See http://svnbook.red-bean.com/en/1.7/svn.advanced.locking.html#svn.advanced.locking.lock-communication
The property indicates to clients that the item should, not must, be locked. It is, along with locks, a communication tool to synchronise edits to files which are not textually merge-able. Most clients support this and prompt the use to acquire a lock.
> That is, am I doing something
> incorrectly if I want a user to have to lock the file prior to check-in?
You mean prior to editing?
You may attempt to enforce locking via hooks but that would undermine the concepts of breakable / steal-able locks in svn.
Andreas
Re: AW: SVN is ignoring needs-lock property
Posted by Mun Johl <Mu...@Emulex.Com>.
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.Johl@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
Posted by Mun Johl <Mu...@Emulex.Com>.
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@codesys.com]
MS> > Von: Niemann, Hartmut [mailto:hartmut.niemann@siemens.com]
MS> > > > -----Ursprüngliche Nachricht-----
MS> > > > Von: Mun Johl [mailto:Mun.Johl@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
AW: SVN is ignoring needs-lock property
Posted by Markus Schaber <m....@codesys.com>.
Hi,
Von: Markus Schaber [mailto:m.schaber@codesys.com]
> Von: Niemann, Hartmut [mailto:hartmut.niemann@siemens.com]
> > > -----Ursprüngliche Nachricht-----
> > > Von: Mun Johl [mailto:Mun.Johl@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.schaber@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
Posted by Markus Schaber <m....@codesys.com>.
Hi,
Von: Niemann, Hartmut [mailto:hartmut.niemann@siemens.com]
> > -----Ursprüngliche Nachricht-----
> > Von: Mun Johl [mailto:Mun.Johl@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.schaber@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
Posted by "Niemann, Hartmut" <ha...@siemens.com>.
> -----Ursprüngliche Nachricht-----
> Von: Mun Johl [mailto:Mun.Johl@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