Mark Slade <markandrewslade_at_gmail.com> writes:
>Per your Issue Tracker Guidelines, I am seeking somebody who agrees
>that this is a bug before I submit it.
>
>Overview: For files, 'svn mv' does not properly inherit ACL
>permissions from the parent directory.
>
>Steps to reproduce (from a subversion working directory):
>1. setfacl -d -m user:$USER:r-x .
>2. touch foobar
>3. svn add foobar
>4. svn commit -m 'test' foobar
>5. svn mv foobar barfoo
>6. getfacl barfoo
>
>If you check the ACL for barfoo after steps 2, 3, and 4, you will see
>that it has properly inherited the user:jdoe:r-x permission. After
>step 5, you will see that barfoo has not. You can circumvent this
>behavior by using "mv" instead of "svn mv" in step 5. In this case,
>you need to "svn delete foobar" and "svn add barfoo" before you can
>commit the move.
>
>Details:
>CentOS release 5.4 (Final), svn 1.4.2 (from yum)
>
>I'm not sure what else is relevant, so fire away if you have questions.
So just to clarify:
The expectation is *not* that Subversion would version these ACLS, but
rather that, on the client side, an 'svn mv foo bar' would preserve
foo's ACLS so that bar has the same ACLs (locally).
IOW, you would not expect that when the 'svn mv' is committed and
someone *else* checks out a working copy with the new bar in it, that
bar to have the ACLs, right?
(Btw, I think it's better to just use "foo" and "bar" -- it's a bit hard
to keep track of "foobar" vs "barfoo", mentally :-) .)
Stephen Butler, I saw your later followup, but were you clear on how
limited Mark's proposal actually is?
-Karl
Received on 2010-05-04 08:39:47 CEST