Archive for the ‘svn’ Category

TortoiseSVN uses root account to check-in

Friday, November 28th, 2008

Normally I prefer the command line tools over the tools with GUI. CLI usually means that interface is clear, simple and it could be wrapped up in the script and run automatically.

I worked with all mainstream source control systems, but Subversion is the one which still puzzles me after a year of use.  That’s why I prefer to use TortoiseSVN, which seems to me really great thing (not the Subversion itself though). It’s a pity that it exists only in Windows version.

Anyhow, I was trying to understand why when I’ve got source tree checked out under my username, TortoiseSVN checks in modifications using root account, instead of my username. Subclipse does not have this problem at all.

Then I found the answer in the TortoiseSVN FAQ:

Why is there no ‘author’ shown in the logs when I commit changes via svn+ssh?
Since SSH completely takes care of the authentication process, Subversion won’t even see the author who does the commit. So to tell Subversion an author you have to specify the author in the URL itself. E.g. svn+ssh://username@server.com. You should do that when you check out your working copy.

When I tried it, TortoiseSVN used my username. Perfect! But Subclipse went nuts. It started to think that the repostory URL is username@ssh+svn://host/repository or similar. I tried both PureJava & SVNKit implementations with no luck. Nuts!

svn: This client is too old to work with working copy; please get a newer Subversion client

Friday, July 11th, 2008

I’ve bumped into this problem again – Subclipse was refusing to do anything (Share the project, update, commit, etc) with the source files.

It is appeared that the culprit was a Tortoise SVN – it is already built on subversion 1.5, while Subclipse is using 1.4.x.

The problem appears everytime when you do anything using newer client, like Tortoise SVN.  Newer client  leaves a different footprint, so Subclipse is getting upset with that fact.

To overcome the problem I’ve added subversione client into the Cygwin port – it is still some relatively old version (1.4.6-3). Then I checked out the project via cygwin version of svn.

It also helps when only a part of the source tree is damaged by a newer client, so you can simply overwrite these bits from an tree checked out using older version.  Just be sure to copy modified files to some safe location first.

UPD  The final solution is to upgdade to Subclipse >=1.4.2 as it is using Subversion 1.5.x. The problem will be completely fixed.

To do this you have to simply add new remote site in Eclipse:
Name: Subclipse 1.4.x (Eclipse 3.2+)
URL: http://subclipse.tigris.org/update_1.4.x

and remove the old one which refers to Subclipse 1.2.x.

The full installation instructions could be found here:
http://subclipse.tigris.org/install.html