On Mon, Oct 31, 2011 at 8:08 PM, mels630 <mels630_at_gmail.com> wrote:
> I maintain a personal SVN server on a separate partition of my hard drive
> (/media/SVN) (with both remote and local access). Recently, I blew up my
> main partition while trying to upgrade Ubuntu and am just getting everything
> working again.
>
> My data directories on my home partition were not affected after the last
> unsuccessful upgrade attempt. I ended up creating a new partition out of
> empty space and putting down a fresh Ubuntu install there. Then I copied my
> data directories onto this new partition. I reinstalled SVN and
> re-established access to my SVN server, seemingly with no problem.
>
> From my data (/home/XXX/Work) directory, I can successfully update my local
> copy of my "Work" repository, however, when I attempt to commit new data, I
> get the following error:
>
> XXX_at_YYY:~/Work$ svn commit -m "Test commit 2"
> svn: Commit failed (details follow):
> svn: Can't open file '/media/SVN/Work/db/txn-current-lock': Permission
> denied
How are you accessing it? And have you checked the group id's on that
'/media/SVN/Work/db/' directory to match what you want? For example,
if you're using Apache access, you'll need to set the group ownerships
of db and its subdirs as "2775", with the same gid as the Apache
daemon uses. And when you "commit data" , are you also using Apache?
Or are you using your own user, and your own user doesn't have the
same group membership?
> However, I don't think permissions are the issue. From this same data drive,
> I can checkout a new version of the repository (say, to ~/temp/Work), add a
> new file there, and successfully commit a new revision without any trouble.
>
> Is there are way to fix whatever ails my Work directory so that I can commit
> from there without starting over again? I've got a number of files I've
> changed since my last commit, along with a lot of "raw" data (pdfs, image
> files, etc.) that are kept out of the repository (I use svn:ignore so that I
> don't see them most of the time for svn purposes) and would rather not have
> to move them all carefully into a new copy of the repository.
>
> Thanks for any suggestions.
>
>
Received on 2011-11-01 03:17:39 CET