I am currently using Tortoise SVN and a SVN plugin from my IDE. Sometime problems appear, and it seems that my .svn aren't always in a consistent state. So is a bad practice to use two SVN clients ? (looking from a practical approach). Do you have links related to SVN best practices ? Thank you.
+2
A:
I use AnhkSvn and Tortoise all the time, they sometimes get out of sync but I never had any issues with consistency. I don't think it is a bad practice to use any number of svn clients provided they are well behaved.
Otávio Décio
2010-03-05 14:26:42
Agreed, the only thing to keep in mind, is that if you have files not included in your IDE that may need to get updated or committed, then you would need to go use Tortoise for that. That's the only time I've run into problems with this type of setup.
dhulk
2010-03-05 14:28:26
@dhulk - agreed and it happens to me all the time as well, but it is not a fault of either client.
Otávio Décio
2010-03-05 14:30:44
I agree with dhulk
Jason W
2010-03-05 14:30:46
+1
A:
Not at all. Many people use a graphical client (TortoiseSVN, IDE plugin) along with a command-line client (useful for those commands that would just take longer to click through than to type).
Michael Hackner
2010-03-05 14:36:38
+6
A:
You can use however many makes it easy to do your job.
We're using Tortoise on all machines, and AnkhSvn for those who use Visual Studio as well. Most of the time I'll use the plugin, but it often has issues doing things like complicated moves or renames, so in those instances I'll use Tortoise. Whatever gets the job done. I also really like the shell integration that Tortoise gives you.
If you're using multiple clients, it's a bit of trial and error to find which client works best for which operations, but that shouldn't take too long.
One thing you need to watch is to make sure the SVN clients remain compatible with the version of SVN on your server, and that all the clients are capable of reading/writing between each other. I recommend reading the release notes before installing any updates to the clients (which often have automatic update type mechanisms).
Jon Seigel
2010-03-05 14:36:48
The server version doesn't matter; svn clients are backwards and forwards compatible with server versions. What matters is that all clients are on the same svn version.
Ken Liu
2010-03-05 14:49:52
@Ken: That has not been our experience. We had downloaded the latest client and it did not interact well with an older version of the server software. Yes, the clients *should* be backwards and forwards compatible, but this doesn't seem to be the case all the time, or it's up to the developers of the client to make it happen reliably.
Jon Seigel
2010-03-05 15:03:48
@Jon interesting. I guess it's good to know the difference between the way things _should work_ and how they really work. :)
Ken Liu
2010-03-05 15:17:21
@Ken, @Jon: Subversion 1.5 added merge support which mostly works on the client side but also needs server side support to truely support all features. Some clients (e.g. Subclipse and AnkhSVN) will show a warning if the server doesn't support these features.
Bert Huijben
2010-03-06 12:17:43
Yes, what I meant by "compatible" is that the client won't break just because the server version changed. We certainly can't expect old clients to support features that didn't exist when they were released. :)
Ken Liu
2010-03-06 16:56:08
+1
A:
It is a bad idea to use multiple SVN clients on the same checkout. Even using different versions of the commandline client may make the repository unusable for the other (I've had plenty of trouble with that, using remote filesystems from different machines).
Tronic
2010-03-05 14:36:48
+3
A:
Yes, it is a very bad idea. SVN is notorious for silently upgrading the on-disk data structures to the newest format it understands, so whenever only one of your clients is updated to a newer program version (e.g. because you used "refresh plugins" in your IDE, or when you refresh your Cywgin installation...), the other one may be locked out. If it isn't easily upgradeable, e.g. because your IDE plugin hasn't actually been rewritten yet, you're screwed. At the very least, use only clients that cannot possibly self-update without your knowledge.
Kilian Foth
2010-03-05 14:46:28
Subversion 1.7 will require an explicit upgrade, unlike all previous 1.X releases. (The upgrade will also be much slower than previous updates... To make everything faster afterwards)
Bert Huijben
2010-03-06 12:18:47
+1 for the answer. I will say in SVN's favor that when I ran into this, the older program complained that the structure wasn't what it expected, rather than crapping all over my files.
Hugh Brackett
2010-03-08 20:38:14
+1
A:
This generally works fine. I frequently switch between TortoiseSVN, Eclipse, and the CLI client.
What you have to watch out for is caching in your IDE. For example, Eclipse doesn't know when you use Tortoise to do an update, so you have to manually refresh the project so that it finds the updated files.
The other thing you have to watch out for is the client version. Be careful when updating one of your SVN clients, because if one of them moves to a newer svn client version, it may make your working copy inaccessible by the other clients. It doesn't matter what the server version is, as long as all your clients work against the same svn client version.
Ken Liu
2010-03-05 14:49:09