I’m using Coda’s built-in controls to commit the changes but I doubt that’s the problem, I think I missed something when setting the group ownership of the svn directory with:
sudo chgrp -R admin /usr/local/svn
Should I delete everything and start over or is there a way to fix this from the Terminal?
Yes I did. I followed this tutorial, steps 1-4 only, to create the
repo and project directory. I did not import any files into the
“demo” project folder because I thought Coda would handle this
aspect. Right now I’m chasing my tail and am unclear as to how to fix
any of this. Any help or suggestions would be appreciated.
Todd
On Aug 28, 2008, at 10:16 AM, Walter Lee Davis wrote:
When you initially created your repository, did you use sudo? I
failed to do that once, and nothing at all would work.
Walter
On Aug 27, 2008, at 10:16 AM, Todd wrote:
Using svn 1.5.1 I get the following error when trying to commit a
change:
Yes I did. I followed this tutorial, steps 1-4 only, to create the
repo and project directory. I did not import any files into the
“demo” project folder because I thought Coda would handle this
aspect. Right now I’m chasing my tail and am unclear as to how to fix
any of this. Any help or suggestions would be appreciated.
Todd
On Aug 28, 2008, at 10:16 AM, Walter Lee Davis wrote:
When you initially created your repository, did you use sudo? I
failed to do that once, and nothing at all would work.
Walter
On Aug 27, 2008, at 10:16 AM, Todd wrote:
Using svn 1.5.1 I get the following error when trying to commit a
change:
That leaves your repository world-writable, and that doesn’t seem right. Does Coda ever prompt you for authentication? Is there anything in the Coda help files about how to integrate this new feature with your SVN workflow? I haven’t tried it yet myself.
It’s not, as far as I can tell, a Coda related issue since Coda doesn’t set repo permissions. It’s probably due to a mistake I made when creating the repo/project in the Terminal. For some reason the command I used (from the tutorial) to ensure that the svn folder and it’s sub-folders were writable did not work or else there’s something bigger afoot that’s causing problems, I don’t know. Originally the permissions on the repo were set to 755 but that was giving me the error. I’m open to suggestions to lock things down a bit more if possible.
Coda would prompt for authentication if I set a UN and PW although I’m unsure if it first needs to be established via the Terminal, I haven’t explored that aspect yet. Not much in the Help files.
Todd
On Aug 28, 2008, at 1:18 PM, waltd wrote:
That leaves your repository world-writable, and that doesn’t seem right. Does Coda ever prompt you for authentication? Is there anything in the Coda help files about how to integrate this new feature with your SVN workflow? I haven’t tried it yet myself.
Coda should prompt for authentication if the files it is attempting to access do not belong to the same user who saved them and the files are not set to be world (or group) readable. I don’t know if Coda tries for a write lock on the files when it opens them, or if it simply opens them and then waits until you try to write to see if it can save changes (like BBEdit and TextMate).
In any case, if you created the repository as root (via sudo) and then checked out your local working copy as you, then if you try to save changes over the working copy from Coda as you, there should be no issue.
Is the error happening when you try to update the repository, or when you try to save changes to your working copy?
I get the access denied error when I Commit to the repo, the working copy updates/saves fine.
Here’s what I used to create the repo,
sudo mkdir -p /usr/local/svn
to change the ownership,
sudo chgrp -R admin /usr/local/svn
and create the project folder,
sudo svnadmin create /usr/local/svn/test
Then I change the permissions of the repo to 777 and import the files after which it works.
Here’s how someone else explained it. I really don’t grasp most of it so I can’t say how accurate it is:
"The whole problem was that your repository was created with the svnadmin, which I believe is part of the wheel group. This group has more permissions than your regular user, “todd” or whatever. So when todd tried to write to the repository, OS X was like “uh uh”. It’s like you tried to edit a file in /System (or /usr for that matter!) directly. When the super user changed the permissions of the repo directory, todd could write to it.
One thing I want to clear up is that you created a directory at /usr/local/svn and then a repository in that directory /usr/local/svn/test . So the repository directory /usr/local/svn/test is a real directory that holds all the repository information. If you create and add a folder called images in Coda, you will not be able to go to /usr/local/svn/test/images because that is a virtual path to the virtual svn filesystem."
On Aug 28, 2008, at 1:53 PM, waltd wrote:
Is the error happening when you try to update the repository, or when you try to save changes to your working copy?
Try making a new repository inside your own Users/todd space somewhere. I have one in Documents, just to be Mac-like. Don’t use sudo to invoke svnadmin when you create the repository. That’s what gets you the permissions conflict.
Btw, there’s a new (beta) Mac svn GUI that’s by far the nicest out there at <http://www.versionsapp.com/>.
Todd
On Aug 28, 2008, at 3:29 PM, waltd wrote:
Try making a new repository inside your own Users/todd space somewhere. I have one in Documents, just to be Mac-like. Don’t use sudo to invoke svnadmin when you create the repository. That’s what gets you the permissions conflict.
No, don’t skip it, but don’t use it anywhere that you have to use sudo to get it to complete. The fact that you are creating your file in /usr/local means that you are well off the map as far as your regular user is concerned. You can’t even see that directory in Finder without some dedicated magic. The explanation you got was close to true, but while the svn server daemon might run as a special dedicated user in the wheel group, svnadmin is a regular Unix command, which means it runs as whichever user invokes it.
Try this in terminal:
cd ~/Documents
mkdir repoman
svnadmin create ./repoman/test
cd /path/to/your/files
svn import ./yourproject file:///Users/todd/Documents/repoman/test -m "Initial Import"
Obviously, adjust the last two lines to match your own file layout, but if any of that requires you to use sudo, I’ll be very surprised.
Then check out your repository somewhere else, and finally, open it with Coda and indicate to Coda that the files are in source control using the site setup panel.
No, don’t skip it, but don’t use it anywhere that you have to use
sudo to get it to complete. The fact that you are creating your
file in /usr/local means that you are well off the map as far as
your regular user is concerned. You can’t even see that directory
in Finder without some dedicated magic. The explanation you got was
close to true, but while the svn server daemon might run as a
special dedicated user in the wheel group, svnadmin is a regular
Unix command, which means it runs as whichever user invokes it.
Try this in terminal:
cd ~/Documents
mkdir repoman
svnadmin create ./repoman/test
cd /path/to/your/files
svn import ./yourproject file:///Users/todd/Documents/repoman/
test -m “Initial Import”
Obviously, adjust the last two lines to match your own file layout,
but if any of that requires you to use sudo, I’ll be very surprised.
Then check out your repository somewhere else, and finally, open it
with Coda and indicate to Coda that the files are in source control
using the site setup panel.
Skip the leading dot nonsense I was using for brevity, and go for whole-hog root-relative paths.
Remember, you only need to have created the repoman folder, anything that appears to be a folder beneath that level is part of the svn database and isn’t real.
Just so I understand, the command (below) is referencing 2 different
paths, correct? The first part, svn import /path/to/local/file,
refers to the physical working copy we want to import into svn and
the second part, file:///path/to/repoman/file -m “Initial Import”
refers to where the imported files should go.
So if the local file is at, ~/Sites/Demo
and the repo is at
~/Documents/repoman
then svn import ~/Sites/Demo file:///~/Documents/repoman -m
“Initial Import” should work, shouldn’t it?
Skip the leading dot nonsense I was using for brevity, and go for
whole-hog root-relative paths.
Remember, you only need to have created the repoman folder,
anything that appears to be a folder beneath that level is part of
the svn database and isn’t real.
Almost correct. The second path should include whatever you want to call the repository copy. So if you had a project called myproject, and you wanted to have a repository called repoman, then the second path would be
file:///path/to/repoman/myproject
If you want to do branches, like
/trunk
/branches
/tags
… then your first import would be into trunk, so you would make that path
Home$ svn import ~/Sites/Test file:///~/Documents/repoman/test -m
“Initial Import”
svn: Unable to open an ra_local session to URL
svn: Unable to open repository ‘file:///~/Documents/repoman/test’
On Aug 28, 2008, at 7:57 PM, waltd wrote:
Almost correct. The second path should include whatever you want to
call the repository copy. So if you had a project called myproject,
and you wanted to have a repository called repoman, then the second
path would be
file:///path/to/repoman/myproject
If you want to do branches, like
/trunk
/branches
/tags
… then your first import would be into trunk, so you would make
that path
? It sounds like maybe not. I have run through this a couple of times, trying different variations, and have gotten pretty good results in Coda. It’s a nice HUD-style UI, very instant update, too.
cd ~/Documents
mkdir repoman
svnadmin create ./repoman/test
cd /path/to/your/files
svn import /path/to/local/file file:///path/to/repoman/file -
m “Initial Import”
Did I miss something?
Todd
On Aug 28, 2008, at 11:53 PM, waltd wrote:
Did you ever run
svnadmin create ~/Documents/repoman
? It sounds like maybe not. I have run through this a couple of
times, trying different variations, and have gotten pretty good
results in Coda. It’s a nice HUD-style UI, very instant update, too.
It looks like I messed up with my instructions. If you followed the first part – svadmin create ./repoman/test – then you will need to add /test/ into all of the paths after that. Alternatively, you could delete the test subdirectory and run the svadmin command again.
cd /path/to/repoman
rm -Rf test
svadmin create .
And from that point on, any path beneath repoman would be a virtual directory, managed by the svn system. Where I messed up was I had a directory called test on my machine, but then I started writing repoman for test in my examples and left the test in there by mistake.