> The permissions on the /.svn/ dir are such that only root
can access them (file mode 0700.)
Don't Do That(tm). Write Subversion checkos for the parts of hte
filesystem individuall, not as a master based at /.
It's pretending that your entire filesystem is a Subversion checkout.
The extend to which this is a bad idea is..... really amazing.
There are chroot and other ways to get a working copy and ignore the /
based filesystem, or simply rsync'ing a working copy from somewhere
else.
On Thu, Aug 7, 2014 at 8:29 PM, Josh Cepek <josh.cepek_at_usa.net> wrote:
> It seems that if Subversion finds a .svn directory in any parent path up
> to the filesystem root, it requires access to the wc.db file or fails to
> perform a checkout operation.
>
> The use-case that caused this is a system where parts of the filesystem
> are checked into an SVN repo for operational management with a checkout
> at the root. The permissions on the /.svn/ dir are such that only root
> can access them (file mode 0700.) However, this means users cannot
> perform checkout operations anywhere on the system, including their own
> homedirs. Subversion sees the /.svn/ directory, attempts to open
> /.svn/wc.db, is denied access, and refuses to perform the checkout as a
> result.
>
> There was an old thread from 2010 with a much too-broad solution of
> ignoring all the WC sanity checks here:
> http://svn.haxx.se/dev/archive-2010-02/0431.shtml
>
> Is there no other way to allow Subversion to gracefully ignore a working
> copy database it does not have access to and allow a user to perform a
> checkout?
>
> Right now the only work-around I have is to rename the .svn dir in the
> filesystem root, and every name it back every time I have to update or
> commit files.
>
> svn, version 1.8.9 (r1591380)
>
> Thanks for any suggestions,
>
> --
> Josh
>
Received on 2014-08-08 05:47:26 CEST