svn add read-only-dir fails unrevertably

[John Williams <wi...@tni.com>]

Setup:

   mkdir bad
   chmod -r bad

Note: Obviously one would not do this on purpose, but unless you 
recursively check that every directory is writable before adding it, 
this can happen when you least expect it.

   svn add bad
svn: Can't open file 'bad/.svn/lock': No such file or directory
   svn status
~      bad
   svn revert bad
svn: 'bad' is not a working copy
   svn cleanup
svn: 'bad' is not a working copy directory

Summary:
It fails to add the read-only directory.
The directory is left in the dreaded '~' state, apparently because it 
has an entry in ./.svn/entries but bad/.svn does not exist.
svn revert cannot fix it.
svn cleanup fails to complete running.

(tested with svn-1.1.0 and svn-1.1.1)

Questions:
Should I submit a bug for this?  Seems like it should detect the failure 
to create bad/.svn and avoid leaving the directory in the '~' state.

Is there any way to clean this up, besides editting ./.svn/entries by hand?

~ John Williams



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn add read-only-dir fails unrevertably

[kf...@collab.net]

John Williams <wi...@tni.com> writes:
> I've created issue 2113, but I don't have access to the keywords and
> milestone fields when adding, and I cannot edit issues either.

Hmm, if you're logged in (as some user with the 'Observer' role) on
project Subversion, you should be able to do these things.  Were you
logged in?

-Karl


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn add read-only-dir fails unrevertably

[John Williams <wi...@tni.com>]

On 3 Nov 2004 kfogel@collab.net wrote:

> John Williams <wi...@tni.com> writes:
> > Should I submit a bug for this?  Seems like it should detect the
> > failure to create bad/.svn and avoid leaving the directory in the '~'
> > state.
> >
> > Is there any way to clean this up, besides editting ./.svn/entries by hand?
>
> It appears that current head (r11743) of Subversion behaves a bit
> differently.  The 'svn status' never shows ~, instead it just gives an
> error.  But, 'svn revert' works!

So that should be in the 1.2 release then.  Something to look forward to.

> I think it's still a minor bug that the parent's .svn/entries file is
> left with the entry for the new directory, but that bug is fairly
> minor, given that 'svn revert' works on the bad directory and
> correctly cleans up the parent's .svn/entries file.
>
> So I'd say, file an issue, mark it as a P4 defect, put "bite-sized" in
> the keywords field, and drop the issue in the 'unscheduled' milestone.

I've created issue 2113, but I don't have access to the keywords and
milestone fields when adding, and I cannot edit issues either.

~ John Williams



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: svn add read-only-dir fails unrevertably

[kf...@collab.net]

John Williams <wi...@tni.com> writes:
> Setup:
> 
>    mkdir bad
>    chmod -r bad
> 
> Note: Obviously one would not do this on purpose, but unless you
> recursively check that every directory is writable before adding it,
> this can happen when you least expect it.
> 
>    svn add bad
> svn: Can't open file 'bad/.svn/lock': No such file or directory
>    svn status
> ~      bad
>    svn revert bad
> svn: 'bad' is not a working copy
>    svn cleanup
> svn: 'bad' is not a working copy directory
> 
> Summary:
> It fails to add the read-only directory.
> The directory is left in the dreaded '~' state, apparently because it
> has an entry in ./.svn/entries but bad/.svn does not exist.
> svn revert cannot fix it.
> svn cleanup fails to complete running.
> 
> (tested with svn-1.1.0 and svn-1.1.1)
> 
> Questions:
> Should I submit a bug for this?  Seems like it should detect the
> failure to create bad/.svn and avoid leaving the directory in the '~'
> state.
> 
> Is there any way to clean this up, besides editting ./.svn/entries by hand?

It appears that current head (r11743) of Subversion behaves a bit
differently.  The 'svn status' never shows ~, instead it just gives an
error.  But, 'svn revert' works!

I think it's still a minor bug that the parent's .svn/entries file is
left with the entry for the new directory, but that bug is fairly
minor, given that 'svn revert' works on the bad directory and
correctly cleans up the parent's .svn/entries file.

So I'd say, file an issue, mark it as a P4 defect, put "bite-sized" in
the keywords field, and drop the issue in the 'unscheduled' milestone.

Here's the script I used to discover the different r11743 behavior:

--------------------8-<-------cut-here---------8-<-----------------------
#!/bin/sh

### Edit these as necessary:
SVN=${HOME}/src/subversion/subversion/clients/cmdline/svn
SVNADMIN=${HOME}/src/subversion/subversion/svnadmin/svnadmin

if [ -d wc ]; then
   (cd wc; rmdir bad)
fi

rm -rf wc repos

${SVNADMIN} create repos
${SVN} mkdir -m "Create a top-level directory." file://`pwd`/repos/trunk

${SVN} co file://`pwd`/repos/trunk/ wc

cd wc

mkdir bad
chmod -r bad

echo ""
echo "Attempt to 'svn add' the bad directory:"
${SVN} add bad

echo ""
echo "Adding it failed.  Try 'svn status':"
${SVN} st

echo ""
echo "Hmmm, what about 'svn status -v':"
${SVN} st -v

echo ""
echo "Yuck.  But we can revert it:"
${SVN} revert bad

echo ""
echo "Now 'svn status -v' succeeds normally:"
${SVN} st -v

echo ""
echo "Done."


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org