Thank you Joe for a well written article. I've been looking into subversion for a few weeks now and i found your article with pics explained a lot. Much appreciated.

Looking at replacing VSS with Subversion, but want to ask if it is feasible to switch without any integration with VS.NET.

The various plugins to VS.NET (Ankh, Subway ) does not on the surface look up-to-date, though I haven't looked too extensively at them.

TortoiseSVN looks good and up to date, though not integrated with VS.NET, but I worry that the "user experience" (and thereby the "versioning dicipline" or whatever I should call it) will suffer...

Martin,

Subversion can be us completely free of any VS.Net intergration. Just use Tortise SVN, its a great Windows client for Subversion and feature rich.

The user experience is fine, TortiseSVN easily has the required functionality for your basic version control cycle which I'm assuming your developers are familiar with.

In VSS you check projects/files out and therefore lock others out, where as in Subversion anyone can check out anything and when you commit your changes and conflicts are found, you just need to merge the changes.

TortiseSVN has a great inbuilt merging tool.

If you could give me some more specific examples of things you are worried about, I can let you know if I have encountered them.

regards,
Ralph

OK.

Now I have read (parts of) svnbook.red-bean.com and think I basically got the major difference; VSS does lock-modify-unlock, and subversion/CVS does copy-modify-merge.

Then a few things come to mind:

1) Using VSS/VS.NET it is very very clear when you are initiating a change that needs a checkout (VS.NET complains that you must checkout the file(s)). Even most other tools (unaware of VSS) will warn you about modifying a read-only file, and you get a chance to think "Do I really want/need to edit this file?", whereas in Subversion you just work on writable files, and never get the "change initiation warning". Won't this cause more unintented or accidental changes to stuff?

2) Also, it seems that one "commits" a directory-ful of changes at a time, not a single file as in VSS. In VSS/VS.NET it is clear that you only check in a single file and nothing else, but in Subversion, I (might) have to watch out for these unintentional changes (such as VS.NET unexpectedly rewrites some paths in a .sln/.csproj-file or something) looking carefully at some list of changes to commit.

3) It is also (visually) obvious if files you work on are under version control or not, at least using VS.NET. If you just add/delete a few files in a Subversion controlled directory, will they be automatically be added/deleted, or do one need to tell Subversion about this explicitly? I fear otherwise some new files might be left out of version control, and at best create problems for others who will end up having an incomplete set of source files.

4) Labels in VSS are useful. Am I correct in thinking that the "directory version" is more or less the same thing conceptually? And a "tag" corresponds to a nicely named label (but is really just a "copy-on-write"-copy just like a branch)

5) In VSS, I want to avoid people having useful code only on their local machines, so weekly I run a script that warns users if they have had things checked out more than two weeks. In Subversion, I assume it is impossible to keep track of if people have made some changes locally that they havn't committed within a reasonable timeframe?

Obviously, some of these issues will solve themselves if we work out some procedure to follow. I guess I have to try it out for myself a little before requesting anyone else to use it.

Hi Martin,

You bring up some good points, in the next few days I should have some time to respond!

Martin,

How are you going with Subversion?

Ralph!

I have now got a fairly good understanding of Subversion, and I like it a lot, apart from unicode issues, but more on that later.

The initial reason I looked at Subversion was that it, for a project we're starting up, might be useful to be able to work remotely (accessing version control over the internet).

But since I the rest of the team is more familiar with VSS, and we heard that VSS 2005 had "remote access via http", we decided to try that first.

Word of advice: Don't!

We ended up wasting a few days on setting up VSS2005 web access via HTTPS only to realize that "remote access via http" actually meant "you can add, check out and check in" and that's it! No history, no labelling, no diffing with an older version, no nothing. Also it can only be used from Visual Studio, because the standard Visual SourceSafe 2005 client cannot speak http.

So we will definitely use Subversion - if and when remote access becomes "need to have" instead of "nice to have"...

However, apart from the other questions I posed (3 resolves itself using TortoiseSVN and 4 is "yes") I was a bit dissapointed with the (lack of) unicode support.

I immediately got garbled characters in log messages (using the swedish characters å ä and ö) but maybe I haven't set up Tortoise and/or SVN correctly in this regard.

Also we use tools that output files as UTF-16, which apparently gets treated as binary by SVN, which means no internal tool diffs. At least in Tortoise it seems you can set a specific differ per extension, but I havn't tried that, and I am afraid it will turn out to refuse to do "binary diffs" (just as useful as when SourceSafe 6 tells me that "Binary files differ" when they're UTF-16).

Having codepage issues is "soo 90's" when we now live in the interconnected information highway unicoded web 2.0 xml universe thingy...

Ok, I was being a tad unfair to SVN regarding unicode, because the garbled log messages turned out to be the cmd/CC.NET console that could not handle unicode UTF-8 output. When I redirected the output to a file the log message looked good. That said, I still want full unicode UTF-8/16 support in SVN...

Thanks for that Martin, try out accessing subversion using http with Apache. I found it works great and didn't notice any speed problems accessing repositories at work from home over ADSL.

My goal with this ebook was to take all the tools that do specific jobs really well and glue them together.

I've got plenty more to add and will do in the new year, I'm off on a snowboarding trip for a month around Canada and the US.

Eén van de laatste dingen die ik doe in mijn loopbaan bij MoreInfo, is kijken welke mogelijkheden er

thank you very good a post.