TortoiseSVN compatibility mode

1
votes

Our code is being developed on Windows (corporate requirement), but it runs on Linux servers. Therefore, we are using Samba shares with an SVN checkout on them. Unfortunately, we need to use some SVN-using scripts on the server side, but our SVN on the server is a 1.4, while our TortoiseSVN on the Windows clients is 1.5 or 1.6. So essentially, any action on the checkout using TortoiseSVN upgrades the internal structure of the checkout and thus it can't be used on server side anymore, since "The client version is too old".

Do you know any way to work around this problem? The only way I know of is not using SVN on client side at all, but that's kind of contra-productive. Upgrading SVN on the server is also out of question. Any other possibilities?

3
svntortoisesvn

3 Answers

5
votes

Why don't you use the old 1.4 TortoiseSVN then?

The other option would be to have a separate working copy for Samba shares and for running those SVN scripts you mention. This way your shared working copy could use v1.6.

5
votes

Don't share working copies!

Especially not between different OS. You will get into troubles with this, sooner or later. One (the most obvious one) problem is the line ending of text files. If you specify the svn:eol-style property to "native", that's different for an svn client running on Linux than an svn client running on Windows.

There are many more differences which will get you into troubles with this approach, but those require knowledge of the svn internals to understand.

So again: do not share working copies!

0
votes

So long as the server can see the svn repository I'd go for a small batch file that uses something like plink from putty and runs a script on the server which updates it's checked out folder.

And also keep a separate working copy on each dev machine (which I assume you aleady have anyway)

This way it doesn't matter which client version we are using as all client checked out repositories are independent. To simplify things a bit also check in the plink and a batchfile to run the update script on the server, then have a restricted account created on the box which users know the id/password of and then you can run it from the client machine easilly. we have a command line as follows

tools\PLINK.EXE -pw password user@server /fullPathToSNVUpdateScript