You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Romain Francoise <ro...@orebokech.com> on 2006/11/20 19:05:35 UTC
Subversion vs. non-writable dirs
Hi,
Subversion seems to get into trouble when trying to add non-writable
directories. I have skimmed through the list of open issues and even
though #2113 and #2425 look similar in their effects, this particular
bug has apparently not been reported yet. I'd like to get feedback from
the list before opening a new issue in the tracker.
I'm using:
$ svn --version
svn, version 1.4.2 (r22196)
compiled Nov 10 2006, 17:39:50
Consider the following scenario:
$ svnadmin create /tmp/test
$ svn co file:///tmp/test
Checked out revision 0.
$ cd test; mkdir -m 0555 bad # create non-writable dir
test$ svn add bad
svn: Can't create directory 'bad/.svn': Permission denied
test$ svn revert bad
Reverted 'bad'
test$ ls -ld .svn
ls: .svn: No such file or directory
test$
The revert operation has removed the admin directory from my working
copy.
Worse, if you try this in a working copy where at least one directory is
under version control, the working copy gets wedged:
$ svnadmin create /tmp/test
$ svn co file:///tmp/test
Checked out revision 0.
$ cd test; mkdir -m 0755 foo; svn add foo; svn ci -m "Add foo."
A foo
Adding foo
Committed revision 1.
test$ mkdir -m 0555 bad
test$ svn add bad
svn: Can't create directory 'bad/.svn': Permission denied
test$ svn revert bad
svn: Try 'svn revert --recursive' instead?
svn: Unable to lock 'foo'
test$ svn revert --recursive bad
svn: Try 'svn revert --recursive' instead?
svn: Unable to lock 'foo'
test$ svn cleanup
svn: 'bad' is not a working copy directory
test$ svn diff
svn: Directory 'bad/.svn' containing working copy admin area is missing
test$
If I remove the 'bad' directory manually, then 'svn cleanup', then
'svn rm bad', the working copy returns to normal (probably because the
bad directory then gets removed from the top-level entries file).
Thanks,
--
Romain Francoise <ro...@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. non-writable dirs
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 20, 2006, at 16:20, Romain Francoise wrote:
> Tim Hill <dr...@comcast.net> writes:
>
>> Well, as you note, Subversion needs to create the .svn directory
>> inside each directory in a working copy, so in this case you really
>> need rw access.
>
> Sorry if I have been unclear; I don't expect Subversion to succeed
> here.
> I'm aware that having write permission is a hard requirement when
> putting stuff under Subversion's control.
Implementing support for opaque collections a.k.a. document bundles
in Subversion could be a solution to this problem as well.
http://subversion.tigris.org/issues/show_bug.cgi?id=707
> However, I would like Subversion to handle this situation gracefully.
> It should certainly not just wipe the admin directory on 'svn
> revert' as
> in my first scenario, and it should definitely not wedge the working
> copy as in the second scenario.
Agree.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. non-writable dirs
Posted by Romain Francoise <ro...@orebokech.com>.
Tim Hill <dr...@comcast.net> writes:
> Well, as you note, Subversion needs to create the .svn directory
> inside each directory in a working copy, so in this case you really
> need rw access.
Sorry if I have been unclear; I don't expect Subversion to succeed here.
I'm aware that having write permission is a hard requirement when
putting stuff under Subversion's control.
However, I would like Subversion to handle this situation gracefully.
It should certainly not just wipe the admin directory on 'svn revert' as
in my first scenario, and it should definitely not wedge the working
copy as in the second scenario.
My naive approach to the problem is that Subversion could first check if
it *can* put the 'bad' directory under version control, and *then* add
it to the entries file...
Thanks,
--
Romain Francoise <ro...@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
| ever free! --Bryan W. Procter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. non-writable dirs
Posted by Tim Hill <dr...@comcast.net>.
Well, as you note, Subversion needs to create the .svn directory
inside each directory in a working copy, so in this case you really
need rw access. There is no workaround I'm aware of, nor do I expect
a bug to get a "fix" other than "by design".
Do you have a usage scenario where this is necessary? Working copies
are tacitly assumed to be scratch data with full access by the user.
--Tim
On Nov 20, 2006, at 11:05 AM, Romain Francoise wrote:
> Hi,
>
> Subversion seems to get into trouble when trying to add non-writable
> directories. I have skimmed through the list of open issues and even
> though #2113 and #2425 look similar in their effects, this particular
> bug has apparently not been reported yet. I'd like to get feedback
> from
> the list before opening a new issue in the tracker.
>
> I'm using:
>
> $ svn --version
> svn, version 1.4.2 (r22196)
> compiled Nov 10 2006, 17:39:50
>
> Consider the following scenario:
>
> $ svnadmin create /tmp/test
> $ svn co file:///tmp/test
> Checked out revision 0.
> $ cd test; mkdir -m 0555 bad # create non-writable dir
> test$ svn add bad
> svn: Can't create directory 'bad/.svn': Permission denied
> test$ svn revert bad
> Reverted 'bad'
> test$ ls -ld .svn
> ls: .svn: No such file or directory
> test$
>
> The revert operation has removed the admin directory from my working
> copy.
>
> Worse, if you try this in a working copy where at least one
> directory is
> under version control, the working copy gets wedged:
>
> $ svnadmin create /tmp/test
> $ svn co file:///tmp/test
> Checked out revision 0.
> $ cd test; mkdir -m 0755 foo; svn add foo; svn ci -m "Add foo."
> A foo
> Adding foo
>
> Committed revision 1.
> test$ mkdir -m 0555 bad
> test$ svn add bad
> svn: Can't create directory 'bad/.svn': Permission denied
> test$ svn revert bad
> svn: Try 'svn revert --recursive' instead?
> svn: Unable to lock 'foo'
> test$ svn revert --recursive bad
> svn: Try 'svn revert --recursive' instead?
> svn: Unable to lock 'foo'
> test$ svn cleanup
> svn: 'bad' is not a working copy directory
> test$ svn diff
> svn: Directory 'bad/.svn' containing working copy admin area is
> missing
> test$
>
> If I remove the 'bad' directory manually, then 'svn cleanup', then
> 'svn rm bad', the working copy returns to normal (probably because the
> bad directory then gets removed from the top-level entries file).
>
> Thanks,
>
> --
> Romain Francoise <ro...@orebokech.com> | The sea! the sea! the open
> it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh,
> the
> | ever free! --Bryan W.
> Procter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org