svn stumbling blocks

Question

I face a few problems when I use svn. Here is a list

• at some point in time, all my commands like svn commit, svn add, etc worked, but I did something so that none of them would work without running them as root user (sudo). what specific actions would cause this, and how to fix it?
• my other website created an images folder itself, and its user:group became www-data:www-data as a result. when i tried to add this folder to versioning, i think svn failed to create a subdirectory .svn inside images, so it outputted that all sub-paths to the image s folder were locked, and i needed to run cleanup. The cleanup also failed. Also it started showing the images directory with a '~' (tilde) implying that it was versioned at some point but something happened to it. I fixed the 'cant commit till break locks'-and-'cant break locks' cyclic problem as follows:
  • removed .svn/lock files from each of the directories leading to the images folder
  • moved the images directory to home folder, and committed "Deleted images"
  • copied back the images folder and did 'svn add'

But I want to know what i should have done in each of the above two cases. i suspect that in case 1, the problem had something to do with messed-up folder permissions, but I dont know exactly what, and how to fix it. I suspect I could take one of the following steps for folders that dont have the appropriate owners/groups set:

• try to do 'sudo add folder_with_different_user_and_group'
• change user:group to default values, add files and commit. But somehow i would want to revert these changes in a way that it will make it work in future. probably change permissions back but dont change owner:group of the .svn folder?

what is the best way to use svn in each of the above cases, and how to successfully break locks etc when something like this happens?

Answer 1

Your first problem is a filesystem permissions thing, not a svn problem. If you run svn commands as root, it's very likely that a number of your files and directories will end up owned by root. Running

chown -R desiredusername .

as root in the working copy root directory should fix things (note that you'll have to substitute the real username for 'desiredusername'). Try to avoid working as root, and you will avoid a lot of these problems. :)

As for the second problem, if it's a directory that contains runtime data, like things stored by your web application, I'd call into question whether or not you actually want to version that. My bet is you don't, so you would be better served by asking svn to ignore that directory altogether. You can do that by running

svn propset svn:ignore imagedirectoryname .

in the parent directory. Again, substitute the actual name for 'imagedirectoryname'. Also note that if you already have other ignored resources in the parent directory, using svn propset will overwrite them, so you want to run

svn propedit svn:ignore .

instead.

Answer 2

What you describe are permission problems, not SVN problems. I suggest to learn about Unix file permissions and what they mean, for example here.

If your files are created by a web server, you probably have the issue that Apache is configured to run as "www-data" or something. In this case, it might be more simple to add the user (which runs the SVN commands) to the group which Apache uses to write the files.

Answer 3

It seems like you have at least 2 different users updating the same working copy:

• www-data:www-data (web user)
• your own user

That's a problem. You could use root (i.e. sudo) for all svn operations - it isn't clean, but will work.