Talk:Subversion

From DreamHost

Jump to: navigation, search

If you want to edit this or any other talk page and add a reply, try to use proper talk page formatting, including a colon at the start of your comment to indent the paragraph (if replying to an existing comment) and four hyphens to make new lines across the page to break apart new discussions like this one. Use four tildes to add your name and the date you added the comment, like so: -- Louis 14:06, 2 Feb 2006 (PST)

Don't ask questions in the article use this page instead. Santosj 09:08, 27 Feb 2006 (PST)

Contents

Installing SVN yourself?

I tried to install SVN myself, because I need a later version than Dreamhost's. Clearly someone has done this before, or it wouldn't say in the article "If you install your own version of Subversion, then you will have to support Subversion and its problems yourself and read the documentation". However, when I run "make install", I get the error:

mkdir: cannot create directory `/usr/local/apr': Permission denied

How can I resolve this? Presumably there is some way to force SVN to install to a directory other than /usr/local? Kidburla 05:07, 7 Dec 2006 (PST)

It's okay, I resolved this with:
./configure --prefix=/home/[myusername]/svn/usr/local
make
make prefix=/home/[myusername]/svn/usr/local install
make clean
which seemed to work, though its a bit ugly. Kidburla 05:42, 7 Dec 2006 (PST)
Ugly how? Of course you don't have write permissions on /usr/local -- this protects everyone else on the server from your bins -- and protects you from some malicious user replacing the DH-installed ones with copies that would do nasty things to your data. I recommend we go ahead and cut this section from the Talk page because it is a) resolved, b) a year old, and c) of little to no utility for future visitors. -Fjornir 10:40, 10 February 2008 (PST)

Rewrites and Future Sections

Many Sections of the guide still need to be rewritten (or scrapped if not relevent anymore).

To Do:

  • Create a new FSFS repository
  • Simple Checkin/Checkout
  • Other SVN clients
  • Links to other resources (ex: SVN Book for various elements)
  • How to set up your repository from the Dreamhost Panel & check that its working.
  • How to check out your repository annonymously.
  • How to get access with a username/password.
  • Troubleshooting for Subversion Goodies and other authenticate along with other areas.
  • SVN Hooks

I'm up for a rewrite. I think the old directions should go somewhere else like "SVN+SSH". That would cut down on the page size, its very large. It would be good to give a walkthrough with Tortoise SVN or some other simple tool.


I think that this page should concentrate on using the DH Subversion. Some things that should change (suggestions) :
I'm willing to cleanup this page. Any other suggestion ? -- tiennou 04:22, 2 Apr 2007 (PST)

SVN+HTTP

I have been some research on how to allow more than one user access to the repository. Since I may have more than one user working on the repository, I don't want to just hand out my shell access username and password to everyone that wants to make a change. I have been trying to hack into how Dreamhost does the SVN+HTTP. I was wondering if the mod_auth_svn and mod_dav_svn are on every server, but I'm not sure. I did try the .htaccess hack, but it didn't exactly work. I think it could be that it is using the /usr/bin/svn subversion instead of my installed version (1.3.0), which could cause some issues with features and Subversion being able to read it.

It could also be that it is by Location, which from my research is unallowed in .htaccess. That doesn't mean that the mod_dav_svn directives can't be used in .htaccess. My research hasn't come up whether or not they can or can't be used in .htaccess. I have tried to look to see if Dreamhost used it, but either the folder repository is in another location (most likely) or they haven't created it yet (also most likely but it has been 12 hours since I have created it in the panel).

Santosj 09:08, 27 Feb 2006 (PST)

Quick Start added

I agree that the Subversion page needs a rewrite. But what it needs most of all (and right now) is a few simple instructions on how to take advantage of DreamHost's built-in support for Subversion. (Most of the content here discusses how to install Subversion from scratch, which is not what most users care about.) To that end, I've created a Quick Start section that assumes you want to quickly install Subversion using the DreamHost control panel, rather than installing it from source. I put it at the top and called it "Quick Start for the Impatient".

Vocaro 01:36, 14 Feb 2006 (PST)

Good work! Perhaps we can move the old instructions off to a seperate page. This was done for Ruby on Rails when DreamHost started supporting it. The 'do it yourself' instructions for rails moved to Ruby on Rails Installation. Perhaps we could have Subversion Installation and move all the old stuff there.

Garethky 11:09, 16 Feb 2006 (PST)

FYI: For anyone that is confused about the URL for your repository. The SVN access on DreamHost is via http only. So the url of your repository is the same one dreamhost gives you in the control panel. Not 'svn://something' as you might have expected. No matter what tool your using.

Also note that netstat fails on the box that hosts my site, so thats not always reliable: 

 [khan]$ netstat -nl
 Active Internet connections (only servers)
 Proto Recv-Q Send-Q Local Address           Foreign Address         State
 /proc/net/tcp: Permission denied

-- Garethky 16:52, 8 Feb 2006 (PST)

Authentication and Access Control

There are two seperate security issues with Subversion: authentication and access control (granting specific permissions to specific users). The Subversion book v 1.1 calls these issues authentication and authorization, while the Subversion book v1.3 calls them authentication and access control. I think the latter terminology is clearer.

Most of this comes from the subversion book, with some confirmation from DreamHost support. You must be sure to read the v1.1 book. Subversion 1.3 changed some aspects of authentication and access control.

SVN+HTTP

svn+http is very convenient, but very insecure. Everything (including the initial login) is passed essentially unencrypted. Your only option to tighten this is up is to use svn+https. In order to do this, you'll need an SSL certificate and a static IP. The DreamHost panel will install a self-signed certificate for free, and you can add a static IP to your account for another $3.99/month. With a self-signed certificate, most browsers will pop up a message warning that the site's validity can't be ensured. I'm not sure yet whether Subversion tools such as TortoiseSVN do anything like this, although I suspect not. If you need to avoid this warning, you'll have to buy a commercial certificate.

Access control with svn+hhtp and svn+https is done using two files: subversion_repository/repositoryname.access and subversion_repository/repositoryname.passwd. Both of these files are created by the DreamHost panel if you choose the "private project" option. The usernames and password that you enter in the panel are used to build these two files. The format of the file is described here (scroll down past the Apache Location stuff). The Apache Location stuff is out of your control, but there is some flexibility provided by the access file format.

The DreamHost panel creates repositoryname.access files that grant readwrite permissions to every user that you specified. If you want to restrict some users to readonly, you have to edit the file yourself. Using the DreamHost panel to edit your Subversion repository will regenerate this file, blowing away your modifications. The access options are:

  • blank - no access at all
  • r - readonly
  • rw - readwrite

One other issue you will run into into is login caching. This is the mechanism that allows you to repeatedly talk to svn from the same IP and username without having to log in again, once you login successfully the first time. This is one of the things that makes svn+http(s) more pleasant to use than svn+ssh. But it can cause problems if you are trying to test the access control on your repository, as you never know which user account you're operating under. These cached logins are stored in the appropriate subdirectory under ~/.subversion/auth/, and you can just delete the files as you need. See the section on Client Credentials Caching. You can temporarily disable caching by appending "--no-auth-cache" to almost any svn command, or you can disable it for good in the ~/.subversion/config file.

I ran into some weirdness in which my login credentials seemed to be cached (I wasn't being asked to log in again), but I had no cache files anywhere under ~/.subversion/auth/. I'm still trying to figure out what's up with that, but DH support says that's the folder they are using.

SVN+SSH

I gave up on this. For one thing, it's painful in most tools because you are constantly asked to login, often several times during a single command. Good tools like Idea handle this for you transparently, but many tools don't. The only way you can solve this is to set up an SSH Agent, which is pretty painful unless you've done it before.

But the bigger problem is that there is no way to do control access over svn+ssh with the built in Subversion. Access control over svn+ssh is done through UNIX permissions on the repository files. Since these files are owned by dhapache, you can't change the owner or the group. The only way around this is to install Subversion yourself.

Check SSH#Passwordless_Login and set up a ssh without password. It's secure and works. --Eduardocereto 20:13, 21 Nov 2006 (PST)

SVN Versions

Finally, I ran into a pretty serious bug with other svn installations I have used. We used svn 1.1.3 for the server, but users tended to access it with svn 1.2 or 1.3 over ssh. We could generally import large project fine, but the server would always wedge about halfway through the checkout. Updating the server to v 1.3 fixed the problem. Accessing the server with a v 1.1 client probably would have worked too, although we never tried it. Just something to keep in mind.

Willismorse 08:01, 19 Apr 2006 (PDT)

Really awesome research, but I think this should be added to the main article and not the talk page. If you can find a place it would fit then please do so. Santosj 10:26, 20 Apr 2006 (PDT)

Trouble installing SVN::Web

I started the SVN::Web page. The long and short of it is this: I had a really hard time getting SVN::Web installed via cpan, and it didn't really work well (err...at all) for me. Has anyone else had any success with it? Aggieben 14:02, 21 Jul 2006 (PDT)

Character sets?

Is there a way to tell svn to output in UTF-8? --Neurophyre 02:48, 11 Oct 2006 (PDT)

Subversion access troubles

There can be trouble accessing subversion on checkin. Similar to

> svn ci -m "commitme!"
svn: MKACTIVITY of '/svn/!svn/act/7dade699-e050-5046-9cc2-245b0e64fef2': Could not parse response status line. (http://rainforce.org)

That probably means that you are behind a proxy. It could be a proxy of your provider like Squid that caches traffic and works transparently. You can't even notice it until you start to use subversion or other advanced Internet tools. The problem could be avoided (at best) with HTTPS protocol support - it guarantees better security, but this requires unique IP for domain. So the easiest way is to persuade your provider to do as SVN FAQ says. http://subversion.tigris.org/faq.html#proxy
--Techtonik 10:51, 14 Nov 2006 (PST)

Post-commit auto-update script issues...

I took the idea from the forum and moved it into the wiki. The other options up here that people have been complaining about have one thing in common: they all rely on setuid binaries. setuid is disabled as per DH support on all of their NFS volumes (including /home/ where the old instructions wanted people to load from. Let's go ahead and kill this section now that we've got some working and (hopefully) futureproofed instructions in. -Fjornir 22:05, 6 February 2008 (PST)

I'm having problems trying to get post-commit scripts to work... I've followed all of the directions supplied but the post-commit script is not working at all...

post-commit.c 

#define REAL_SCRIPT "/home/USERNAME/svn/USERNAME/hooks/post-commit.bash"
#include <sys/types.h>
#include <unistd.h>
main( ac, av )
  char **av;
{
  execv( REAL_SCRIPT, av );
}

post-commit.bash 

#!/bin/sh
echo "Subversion Update"
cd /home/USERNAME/website
/usr/bin/svn update


ls -al output 

-rwsrwsrwx  1 USERNAME  pg1033716 11437 2007-01-17 11:39 post-commit
-rwsrwsrwx  1 USERNAME  pg1033716   175 2007-01-17 11:44 post-commit.bash
-rw-rw-r--  1 USERNAME  pg1033716   175 2007-01-17 11:39 post-commit.c

Of course I changed all of my personal information to USERNAME...

I chmod'd to 777 out of frustration... As you can see, the Setuid is in place, the permissions are there, the C program compiled fine... I can run the post-commit executable and it does what I want it to do, it just doesn't ever work as an actual post-commit hook.

What am I doing wrong here?

- Williamcotton 12:06, 17 Jan 2007 (PST)

UPDATE

I would love to be able to debug this, but I can't easily login as dhapache to check to see what the permission issues are... ala http://subversion.tigris.org/faq.html#hook-debugging

FIXED

The problem was that setgid wasn't in place... everything is working now.

ANOTHER SOLUTION

I made a script to do the post-commit, its to use for a newly created rep, but it works and it takes 5 sec now to create new reps :) Userbased Scripts

Still more post-commit auto-update script issues...

Here's the rub.

Calling svn update from within a post-commit script causes errors.

My setup: 1. A postcommit suid that executes a postcommit.sh bash shell. 2. That bash shell ends with an "svn update " to update my website. 3. If, and only if, that "svn update" is not commented, I start getting these annoying problems during my *next* commit operation. Here's the log 

laptop:~/facedemo$ svn commit  -m "now 24"
Sending        index.php
Transmitting file data .svn: Commit failed (details follow):
svn: MERGE request failed on '/facedemo'
svn: MERGE of '/facedemo': 200 OK (http://....com)
laptop:~/facedemo$ svn commit  -m "now 24"
Sending        index.php
svn: Commit failed (details follow):
svn: Your file or directory 'index.php' is probably out-of-date
svn: The version resource does not correspond to the resource within the transaction.  Either the requested version resource is out of date (needs to  be updated), or the requested version resource is newer than the transaction root (restart the commit).
laptop:~/facedemo$ svn commit  -m "now 24"
Sending        index.php
svn: Commit failed (details follow):
(repeats above error)
Can you post the contents of the script you're using? Also, since the setuid stuff doesn't work any more you might just try swapping over to the simple scripts I've posted to handle this then re-add the other functionality to you scripts. -Fjornir 19:37, 7 February 2008 (PST)

Small subversion tip

I've written up instructions about how to access a subversion repository via svn+ssh with a shortened URL. It's a bit complex for only a few characters savings, but it's useful for me. Feel free to move (not copy) it to the Subversion page if you think it's useful in general. —Datagrok 03:56, 18 March 2007 (PDT)

ZIP Files

I get the following message when attempting to commit ZIP files. Are ZIP files not allowed? If this is the case, then why are EXE files allowed? 

[00:31:13] - svn commit  1 item(s)
[00:31:18] - Adding  (bin)  {ZIP file name}
[00:31:18] - Refreshing files state...
[00:31:18] - Refresh done
[00:31:18] - Operation failed: svn: Commit failed (details follow):
svn: PROPFIND request failed on '{path to ZIP file}'
svn: PROPFIND of '{path to ZIP file}': 302 Found ({SVN Base URL})

Theraven 23:55, 16 January 2008 (PST)

post-commit

Recently DreamHost disabled the SVN's post-commit workaround specified in the article due to security reasons (They no longer allow setuid). Anyone has a solution? --Locutus 12:48, 6 February 2008 (PST)

I put new, working, instructions in the article. Try them out, then if they work let's delete this from the talk page --Fjornir 18:56, 7 February 2008 (PST)
Retrieved from "http://wiki.dreamhost.com/Talk:Subversion"
Personal tools