svn client/server versions

Question

If I understand correctly version of subversion defines:

• A structure repository on server
• A structure of working copy on client side
• API between client and server

Once we've install svn server, we don't touch/upgrade it.

Things are more complex on client side.

On client side (Windows) we currently use tortoisesvn. It's version (correct me if I'm wrong) is corresponding to subversion version.

Now, we're going port our application to Linux and therefore we consider using additional svn clients (svn command line utility, Eclipse plugin and some GUI frontend).

Now the questions:

1. Is it possible several different clients will work on the same checkout code? If yes thus it means that I need carrefully pick up version of clients to be used, since each client expects a particular format/data be found in .svn directory?

2. What is the relationship between version of server and client side? If for example server side is 1.4 and client is 1.6, thus it means that some 1.6 features won't work?

3. Is it true that version of subversion client is not nessessary corresponding to the version of subverions, such as of rapidsvn as opposed to tortoisesvn?

Answer 1

1. Working copy formats are major-version specific for the client (ie, don't try to use a 1.4 client on a WC created by a 1.6 client).

2. Theoretically, old client/new server and vice-versa are OK, but the most testing gets done on same version (1.6.x - 1.6.x) scenarios. Generally you're OK to mix client/server versions, just new features won't be available with the older part (ie, mergeinfo is not available in 1.4 client talking to a 1.5 server, and commits from a 1.4 client would be missing that info). Again, best to stick with same major version, but you can get away with differences if necessary.

3. Usually you can find the svn library version that a particular client was built against in the release notes.

Answer 2

1. Most clients will respect the format they find in the .svn directories. That means they won't change it. If they don't support the format, you'll get an error but they shouldn't corrupt the data. If you use several different clients to update/work with the checkouts, they should create locks (so the second client will say that someone else is currently working on the checkout and stop). But to be safe, you shouldn't try this.

2. Yes, a 1.4 client can talk to an 1.6 server but the new features won't be available.

3. Usually, the client will say somewhere which server versions it supports but the clients are different projects and have their own version numbering scheme.

Answer 3

You are very close to the mark. Working copies and repositories are always readable by new cleints using the suprt major version, so a 1.6 client will always be able to handle an older server or working copy.

However, you do still need to be aware of the version supported by each one. Most will automatically upgrade a working copy automatically to their own version; so if you checkout using an older 1.4 client, and update it with a newer client ( eg. the latest svn 1.6); the workign copy will no longer be usable will the former.

Answer 4

I would strongly not recommend that you try to use different Subversion clients against the same checkout directory, especially if those are running on different platforms (ie. across a network). Subversion does platform-specific things with line endings on text files, and if you check out on Windows and then check in the same working copy with Linux (for example), you may accidentally touch every line of every file by adding spurious CRLF line endings.

If you are doing cross-platform development, set up a different checkout directory on each platform where you're doing development. If you must share changes before checking in, consider using Git and the git-svn gateway.