You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Fergus Slorach <su...@gmail.com> on 2012/05/26 23:56:40 UTC
File permissions are incorrect after directory copy in 1.7
In Subversion 1.7.5:
If a directory containing svn:needs-lock files is copied and
committed, the needs-lock files are left writeable.
The writeable state can be resolved by running 'svn revert' on
the files, even though the status indicates there is nothing to
revert.
Recipe and run-through results below.
Thanks,
fergus
Recipe:
cd /tmp
svnadmin create repos
svn co file:///tmp/repos/ copy_test
cd copy_test
svn mkdir foo
touch foo/bar.txt
svn add foo/bar.txt
svn propset svn:needs-lock 1 foo/bar.txt
svn commit -m 'Added'
svn copy foo goo
svn commit -m 'Copied'
ls -l goo # goo/bar.txt is writeable
svn st -u -v goo # goo/bar.txt has no status
svn revert goo/bar.txt # goo/bar.txt is reverted
ls -l goo # goo/bar.txt is now read-only
Run of the recipe:
/tmp $ cd /tmp
/tmp $ svnadmin create repos
/tmp $ svn co file:///tmp/repos/ copy_test
Checked out revision 0.
/tmp $ cd copy_test
/tmp/copy_test $ svn mkdir foo
A foo
/tmp/copy_test $ touch foo/bar.txt
/tmp/copy_test $ svn add foo/bar.txt
A foo/bar.txt
/tmp/copy_test $ svn propset svn:needs-lock 1 foo/bar.txt
property 'svn:needs-lock' set on 'foo/bar.txt'
/tmp/copy_test $ svn commit -m 'Added'
Adding foo
Adding foo/bar.txt
Transmitting file data .
Committed revision 1.
/tmp/copy_test $ svn copy foo goo
A goo
/tmp/copy_test $ svn commit -m 'Copied'
Adding goo
Committed revision 2.
/tmp/copy_test $ ls -l goo
total 0
-rw-rw-r-- 1 fergus fergus 0 May 27 09:45 bar.txt
/tmp/copy_test $ svn revert goo/bar.txt
Reverted 'goo/bar.txt'
/tmp/copy_test $ ls -l goo
total 0
-r--r--r-- 1 fergus fergus 0 May 27 09:45 bar.txt
/tmp/copy_test $ svn revert goo/bar.txt
Re: File permissions are incorrect after directory copy in 1.7
Posted by Philip Martin <ph...@wandisco.com>.
Fergus Slorach <su...@gmail.com> writes:
> On 05/28/2012 09:06 PM, Philip Martin wrote:
>> Fergus Slorach<su...@gmail.com> writes:
>>
>>> If a directory containing svn:needs-lock files is copied and
>>> committed, the needs-lock files are left writeable.
>>
>> I think that is correct behaviour.
>
> The problem is that a needs-lock file should not be writeable without
> being locked.
Sorry, I misread your report and fixed a different bug. The bug I fixed
was that revert before commit made the file read-only, and it should
remain writetable since the copied file cannot be locked until it has
been committed.
There is still a commit bug: an svn:needs-lock file in a copied
directory should become read-only on commit. I've raised 4188:
http://subversion.tigris.org/issues/show_bug.cgi?id=4188
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: File permissions are incorrect after directory copy in 1.7
Posted by Fergus Slorach <su...@gmail.com>.
On 05/28/2012 09:06 PM, Philip Martin wrote:
> Fergus Slorach<su...@gmail.com> writes:
>
>> If a directory containing svn:needs-lock files is copied and
>> committed, the needs-lock files are left writeable.
>
> I think that is correct behaviour.
The problem is that a needs-lock file should not be writeable without
being locked.
Note that the behaviour is different when the file is copied:
/tmp/copy_test/foo> svn cp bar.txt baz.txt
A baz.txt
/tmp/copy_test/foo> ls -l
total 0
-r--r--r-- 1 fergus fergus 0 2012-05-28 22:44 bar.txt
-rw-rw-r-- 1 fergus fergus 0 2012-05-28 22:45 baz.txt
/tmp/copy_test/foo> svn commit -m 'Copied'
Adding baz.txt
Committed revision 2.
nexus:/tmp/copy_test/foo> ls -l
total 0
-r--r--r-- 1 fergus fergus 0 2012-05-28 22:44 bar.txt
-r--r--r-- 1 fergus fergus 0 2012-05-28 22:45 baz.txt
This is the correct behaviour - the new file is writeable after the
copy, but is made read-only by the commit.
>> The writeable state can be resolved by running 'svn revert' on
>> the files, even though the status indicates there is nothing to
>> revert.
>
> That looks wrong, the file should remain writeable. Fixed by r1343168.
>
Revert does the right thing by making the file read-only but that
should have been done by the commit, as in the file case above.
Thanks,
fergus
Re: File permissions are incorrect after directory copy in 1.7
Posted by Philip Martin <ph...@wandisco.com>.
Fergus Slorach <su...@gmail.com> writes:
> If a directory containing svn:needs-lock files is copied and
> committed, the needs-lock files are left writeable.
I think that is correct behaviour.
> The writeable state can be resolved by running 'svn revert' on
> the files, even though the status indicates there is nothing to
> revert.
That looks wrong, the file should remain writeable. Fixed by r1343168.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: File permissions are incorrect after directory copy in 1.7
Posted by Fergus Slorach <su...@gmail.com>.
Hi Bert,
Yes, the same recipe in 1.6.17 results in read-only files without the revert.
Actually, in that version, the files are read-only before the commit, which
isn't the desired behavior either - this thread seems to be related:
http://svn.haxx.se/users/archive-2010-10/0228.shtml
fergus
On 05/27/2012 10:53 AM, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Fergus Slorach [mailto:sugref@gmail.com]
>> Sent: zaterdag 26 mei 2012 23:57
>> To: dev@subversion.apache.org
>> Subject: File permissions are incorrect after directory copy in 1.7
>>
>> In Subversion 1.7.5:
>>
>> If a directory containing svn:needs-lock files is copied and
>> committed, the needs-lock files are left writeable.
>>
>> The writeable state can be resolved by running 'svn revert' on
>> the files, even though the status indicates there is nothing to
>> revert.
>>
>> Recipe and run-through results below.
>
> Did you check if this is a regression.
>
> If it is not, I'm not sure if we should call it a bug.
>
> The copied files are no longer unmodified and have a new (future) URL that
> is not locked and can't be locked.
>
> I assume that they get the read only flag after a commit makes them
> 'unmodified'?
>
> Bert
>>
>> Thanks,
>>
>> fergus
>>
>>
>> Recipe:
>>
>> cd /tmp
>> svnadmin create repos
>> svn co file:///tmp/repos/ copy_test
>> cd copy_test
>> svn mkdir foo
>> touch foo/bar.txt
>> svn add foo/bar.txt
>> svn propset svn:needs-lock 1 foo/bar.txt
>> svn commit -m 'Added'
>> svn copy foo goo
>> svn commit -m 'Copied'
>> ls -l goo # goo/bar.txt is writeable
>> svn st -u -v goo # goo/bar.txt has no status
>> svn revert goo/bar.txt # goo/bar.txt is reverted
>> ls -l goo # goo/bar.txt is now read-only
>>
>> Run of the recipe:
>>
>> /tmp $ cd /tmp
>> /tmp $ svnadmin create repos
>> /tmp $ svn co file:///tmp/repos/ copy_test
>> Checked out revision 0.
>> /tmp $ cd copy_test
>> /tmp/copy_test $ svn mkdir foo
>> A foo
>> /tmp/copy_test $ touch foo/bar.txt
>> /tmp/copy_test $ svn add foo/bar.txt
>> A foo/bar.txt
>> /tmp/copy_test $ svn propset svn:needs-lock 1 foo/bar.txt
>> property 'svn:needs-lock' set on 'foo/bar.txt'
>> /tmp/copy_test $ svn commit -m 'Added'
>> Adding foo
>> Adding foo/bar.txt
>> Transmitting file data .
>> Committed revision 1.
>> /tmp/copy_test $ svn copy foo goo
>> A goo
>> /tmp/copy_test $ svn commit -m 'Copied'
>> Adding goo
>>
>> Committed revision 2.
>> /tmp/copy_test $ ls -l goo
>> total 0
>> -rw-rw-r-- 1 fergus fergus 0 May 27 09:45 bar.txt
>> /tmp/copy_test $ svn revert goo/bar.txt
>> Reverted 'goo/bar.txt'
>> /tmp/copy_test $ ls -l goo
>> total 0
>> -r--r--r-- 1 fergus fergus 0 May 27 09:45 bar.txt
>> /tmp/copy_test $ svn revert goo/bar.txt
>
>
RE: File permissions are incorrect after directory copy in 1.7
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Fergus Slorach [mailto:sugref@gmail.com]
> Sent: zaterdag 26 mei 2012 23:57
> To: dev@subversion.apache.org
> Subject: File permissions are incorrect after directory copy in 1.7
>
> In Subversion 1.7.5:
>
> If a directory containing svn:needs-lock files is copied and
> committed, the needs-lock files are left writeable.
>
> The writeable state can be resolved by running 'svn revert' on
> the files, even though the status indicates there is nothing to
> revert.
>
> Recipe and run-through results below.
Did you check if this is a regression.
If it is not, I'm not sure if we should call it a bug.
The copied files are no longer unmodified and have a new (future) URL that
is not locked and can't be locked.
I assume that they get the read only flag after a commit makes them
'unmodified'?
Bert
>
> Thanks,
>
> fergus
>
>
> Recipe:
>
> cd /tmp
> svnadmin create repos
> svn co file:///tmp/repos/ copy_test
> cd copy_test
> svn mkdir foo
> touch foo/bar.txt
> svn add foo/bar.txt
> svn propset svn:needs-lock 1 foo/bar.txt
> svn commit -m 'Added'
> svn copy foo goo
> svn commit -m 'Copied'
> ls -l goo # goo/bar.txt is writeable
> svn st -u -v goo # goo/bar.txt has no status
> svn revert goo/bar.txt # goo/bar.txt is reverted
> ls -l goo # goo/bar.txt is now read-only
>
> Run of the recipe:
>
> /tmp $ cd /tmp
> /tmp $ svnadmin create repos
> /tmp $ svn co file:///tmp/repos/ copy_test
> Checked out revision 0.
> /tmp $ cd copy_test
> /tmp/copy_test $ svn mkdir foo
> A foo
> /tmp/copy_test $ touch foo/bar.txt
> /tmp/copy_test $ svn add foo/bar.txt
> A foo/bar.txt
> /tmp/copy_test $ svn propset svn:needs-lock 1 foo/bar.txt
> property 'svn:needs-lock' set on 'foo/bar.txt'
> /tmp/copy_test $ svn commit -m 'Added'
> Adding foo
> Adding foo/bar.txt
> Transmitting file data .
> Committed revision 1.
> /tmp/copy_test $ svn copy foo goo
> A goo
> /tmp/copy_test $ svn commit -m 'Copied'
> Adding goo
>
> Committed revision 2.
> /tmp/copy_test $ ls -l goo
> total 0
> -rw-rw-r-- 1 fergus fergus 0 May 27 09:45 bar.txt
> /tmp/copy_test $ svn revert goo/bar.txt
> Reverted 'goo/bar.txt'
> /tmp/copy_test $ ls -l goo
> total 0
> -r--r--r-- 1 fergus fergus 0 May 27 09:45 bar.txt
> /tmp/copy_test $ svn revert goo/bar.txt