Subversion Versus CVS

I have recently changed from CVS to SVN and I'm not thinking about going back. Main reason to switch for me was Subversion being able to move files without losing the file history. (Although I have not used the feature much for now).

Subversion stores a working copy locally (so not only the file dates), which takes up more space on your HDD (disadvantage), but that really speeds up things sometimes (advantage IMO). And I like the revision numbering better: per repository, not per file. Now I use this number to identify my builds, no obscure build numbers anymore.
I use RapidSVN to manage the stuff. I don't like Visual Studio, so I have no need for integration and this tool works good for me on both Windows and Linux (and Mac too I suppose).

For me SVN is CVS and more. I haven't used SourceSafe myself, but from what I've heard it shouldn't be any problem to convice people to stop using it :-).

P.S. Why is a directory named .svn a problem?

Quote:

Original post by DaBonoP.S. Why is a directory named .svn a problem?

Try creating it or browsing it with windows explorer ;)

Quote:

Original post by mandrav Quote: Original post by DaBonoP.S. Why is a directory named .svn a problem? Try creating it or browsing it with windows explorer ;)

Indeed .svn is just an extension to windows, windows likes to have a filename before an extension.

Quote:

Original post by paulecoyote Indeed .svn is just an extension to windows, windows likes to have a filename before an extension.

But that only applies to creating this directory by hand (which you shouldn't need to do anyway).

Browsing the .svn directories is certainly possible using the explorer.

Quote:

Original post by Erluk Quote: Original post by paulecoyote Indeed .svn is just an extension to windows, windows likes to have a filename before an extension. But that only applies to creating this directory by hand (which you shouldn't need to do anyway). Browsing the .svn directories is certainly possible using the explorer.

That does not change the fact that it screws up webprojects because of the nameless .svn thing.

Anyway, rather then concentrating on filenames... CVS versus Subversion, why did you choose one over the other?

I haven't used subversion, but it has version numbers per-commit as opposed to per-file, which I think is way better.

tj963

Quote:

CVS versus Subversion, why did you choose one over the other?

Atomic operations, man. Gotta be atomic.

There is a version of tortoiseSVN (subversion client), that uses _svn instead of .svn, it is made specificly to work around that visual studio bug.

I've been using SVN at work for over a year now, and it is excellent. The single biggest improvement over CVS is that all commits are atomic - that is, they are single, transactional entities. If something goes wrong with your commit, the SVN repository is safe - as opposed to the hours I've spent fixing up a busy, multi-user CVS repository after such errors. Repository-wide version numbers are good for clarity. File moving and copying (with tagging) can be performed within SVN, and it's smart enough when you copy to a new trunk to only duplicate storage space for deltas on the changed file. Binary file handling is far and above better than CVS; CVS has to store the whole file, SVN can often store a binary delta. At work, we use it for VS.NET web projects all the time - with the _svn version of TortoiseSVN. (Incidentally, this is a VS problem, not IIS or Explorer - websites work fine with .svn folders on the webserver).

Finally, I like the command-line controls more - but that's a personal choice. I did find it really easy to write a script that automatically updates various websites from SVN, onto a staging server, and then calls Nant to build them - but I'm sure that CVS could be made to do the same.

We have been using subversion for almost a year now. Before we did not have any regular source control schemes in place. We had tried sourcesafe but it inserts metadata into the source files to keep them in source control which was unacceptable for us. Not to mention that we could not use it outside of our network without third party tools. We have not tried cvs but I cannot see any reason to switch because of how well subversion has worked for us. On a windows machine the TortoiseSVN client is indispensable.

As far as the .svn folder issues with Visual Studio .NET web projects. We got around this problem by creating our web projects as class library projects. This solved the .svn folder issue. In addition to that, the project is not tightly linked to the particular IIS installation on that box. It allows us to open the project with Visual Studio even without IIS on the box. A huge advantage in multi user environments IMHO.

Here are a couple of links with information on how to use class library projects to make web applications.
http://pluralsight.com/wiki/default.aspx/Fritz/AspNetWithoutWebProjects2.html
http://www.peterprovost.org/archive/2003/08/15/734.aspx

Quote:

Original post by Bracket (Incidentally, this is a VS problem, not IIS or Explorer - websites work fine with .svn folders on the webserver).

Interesting, just Visual Studio huh. Thanks for the long reply too!

Quote:

Original post by rewt As far as the .svn folder issues with Visual Studio .NET web projects. We got around this problem by creating our web projects as class library projects.

That is not going to win over any developers on the Windows side of things, having to change the way you work because of switching source controls is no good, I could not offer a decent business case for spending time switching over to do essentially the same thing our already well established source safe server does, plus loosing partial functionality of the design tools.

Again thanks for the long reply, I am concentrating on giving reasons why we might use Subversion over CVS though for development on Sun & Unix boxes - I cannot see the Windows dev team making the switch from Source Safe to Subversion unless the switch is painless. I hear the next version of Visual Studio does not have the .svn bug in it, so perhaps by then I can recommend to have new projects created on a subversion server and take it from there.

Yes, Ankhsvn is a bit of a pain in the arse with VS.NET and ASPNET applications. Copying / renaming versioned files inside the project manager applet, causes grief most of the time.

However, .svn directories are clearly not what causes the problem. What is a problem is:

- You can't rename a file using the VS.NET project explorer, you have to use the Ankh option.
- If you accidentally *try* to rename a file using the PE, Ankh renames it back, but doesn't take account of the fact that it might be an aspx or ascx file with a codebehind file which also needs renaming - resulting in grief
- You can't rename a file which hasn't yet been committed - therefore VS.NET's OBSCENELY SILLY behaviour of copying things to "Copy of X", breaks things completely. If it prompted for the new name, it would be fine.

As far as I can tell, most of these problems are specific to VS.NET silly rename / copy behaviour, and/or the fact that Ankhsvn doesn't take into account codebehind files.

They are work-aroundable but annoying

---

Having used VSS, however, I can say that that is at least 99.5% less annoying than VSS, which causes your source code to be corrupted, destroys its own repository, and causes half the repository to become corrupted or deleted, on a fantastically regular basis.

Add that to the fact that VSS becomes cripplingly slow on even a modest-sized repostiory.

Plus all the stupid things that VSS doesn't let you do (i.e. anythign). And VSS doesn't correctly remember the history of deleted files!

Basically, creating backup copies on floppy discs which are fed to a baby elephant on a regular basis, then its turd examined later, is less likely to corrupt your code than using VSS.

---

If you're using VSS, why not just delete your own source code to save yourselves loads of hassle - it'll have the same end result.

Mark

Microsoft's new vs.net(2005) is comming with a new source control system that supposedly works with cvs.

On that topic, we use cvs and as someone pointed out cvs's atomic commits are great!! I haven't used svn but we are a cross platform shop here and have had zero complaints with tortoisecvs on windows and SmartCVS on OS X and plain cvs on Linux.

Cheers
CHris

Quote:

Original post by markr ... anti source-safe rant ...

Yeah I know, like I said we've all lost source from source safe at one time, but I am not a manager, I'm a senior developer making recommendations and honestly migrating all our existing projects to a new source repositry would take up too much time. 99.9% of the time Source Safe has been adequate, and the whole "if it's not broken, don't fix it" thing applies here.

At no time has there been a complete source-safe breakdown the whole time I've been here. The worst case actually happened to me a little while ago where it lost me quite a bit of work, no one else here has suffered such a loss... so there isn't much love lost between me and SS. It's integration with the IDE is key to it's adoption though, and having an alternative not integrate properly will not help me recommending it,

The original question is to address CVS use over Subversion, the seemless use on a Windows+Visual Studio development platform would give me ammunition to try and get new projects using Subversion instead of Source Safe - but for now I'm trying to win the CVS versus Subversion thing.

Gotta' pick my battles... bide my time... [wink]

Quote:

Original post by chollida1 Microsoft's new vs.net(2005) is comming with a new source control system that supposedly works with cvs. On that topic, we use cvs and as someone pointed out cvs's atomic commits are great!! I haven't used svn but we are a cross platform shop here and have had zero complaints with tortoisecvs on windows and SmartCVS on OS X and plain cvs on Linux. Cheers CHris

svn looks great for its support of tracking renaming of files alone, what makes you use cvs over svn despite svns larger array of functions?

I chose SVN over CVS because it was much eaiser to get up and running. Combined with TortoiseSVN, can you say "it just works"? I had also heard good things about SVN (about it being newer, and generally "better").

Of course, now I use it, I have no idea how people can put up with many of the mis-features of CVS. *yuck*

On the subject of integration into Visual Studio: I found that AnkhSVN isn't an "it just works" matter. I actually ended up uninstalling it and managing my files in Explorer with TortoiseSVN. Of course, this seems eaiser anyway - particularly if you've got two monitors and you're adding and moving files about a lot.

I would suggest that you would be best off using SVN over VSS. The many, many benifits of SVN outweigh the minor pain of having to move back to Explorer to checkin or getting AnkhSVN to work.


Also TortoiseSVN has absolutly the best Diff and Merge tools I have ever seen. Well worth it.


On the subject of how I use SVN: I generally use TortoiseSVN to work. I can't think of an SVN feature that you can't access through the GUI, let alone one that you'd use regularly. I use the command line version of SVN for making scripts - one of my favorites is a script that automatically checks out an empty project+basecode for rapid prototyping. It's absolutly fantastic.


Other notable things about SVN:
- Best. Manual. Ever.
- Makes backups very easy (particularly incremental).
- Very clean systems (branching, merging, properties, log messages, etc)

Quote:

Original post by paulecoyote Yeah I know, like I said we've all lost source from source safe at one time, but I am not a manager, I'm a senior developer making recommendations and honestly migrating all our existing projects to a new source repositry would take up too much time....

Let me explain more clearly and less rant-ishly:

I have worked on several projects which used MS VSS. All of them have lost parts of the history of files at times. Many have broken down entirely and had to be thrown away.

VSS is a total non-starter as a useful source-code control system, in that it lacks the *only* useful feature of a source-code control system: the ability to actually get back old versions of your source-code!

Not only, has every VSS repository I've ever used, become corrupted to some extent, but I've spent countless hours that I would otherwise have spent developing, trying to recover broken ones (with limited degrees of success each time).

Moreover, I've spent even more countless hours, attempting to educate other developers (and sysadmin staff), how to use VSS in ways which perhaps encourage it to hold on to your sourcecode for slightly longer before breaking.

So from a manager's point of view, VSS is a very bad idea, as your senior developers end up spending time on non-development tasks, and it saps morale very badly.

I'd say, that the final negative point was, VSS's poor quality spread the message amongst the developers that source code control OF ANY TYPE, was an inherently bad idea.

It's a case of throwing the baby out with the bathwater, when developers become so pissed off with VSS, that they choose instead, to use NO SOURCE CODE CONTROL WHATSOEVER.

--

Granted, they did so because they could also see the wasted time trying to fix broken repos etc.

This is another reason why VSS should never be used for anything.

On a more positive note, perhaps we could sell copies of VSS to Iran's nuclear weapons programme scientists, in the hope that they'd lose all their data?

Mark

Quote:

Original post by paulecoyote Quote: Original post by chollida1 Microsoft's new vs.net(2005) is comming with a new source control system that supposedly works with cvs. On that topic, we use cvs and as someone pointed out cvs's atomic commits are great!! I haven't used svn but we are a cross platform shop here and have had zero complaints with tortoisecvs on windows and SmartCVS on OS X and plain cvs on Linux. Cheers CHris svn looks great for its support of tracking renaming of files alone, what makes you use cvs over svn despite svns larger array of functions?

Well to be honest, we use cvs because that's what some of us had experience with. We are happy with what cvs offers us so we've never tried to switch to subversion.

We only really use merging/checkin/checkouts and history.

Cheers
Chris

For what it's worth, TortoiseCVS is nearly as good as TortoiseSVN (I use both regularly, since we use SVN for internal projects, but maintain a couple of Open Soruce projects on SourceForge.net - and it is CVS only for now). So from the client point of view, you can get by with either.

I missed the other big reason we use SVN, so I figured I should post it: WebDAV support. Earlier releases of SVN only supported a small subset of WebDAV functionality, but of late it has been a pretty full-fledged WebDAV server. This means that your webmonkeys/graphic designers (many of whom are excellent at what they do, but aren't always on the same geek-scale as developers!) with Dreamweaver can view it as a remote WebDAV site, gain full version control transparently, and don't really have to understand what's going on. WebDAV is also supported by just about everything.

We actually used VSS for a while, fortunately only as a test case on some projects. It simply couldn't handle the large projects we manage (our SVN repositories add up to a few hundred gigs right now), and was really fragile. I did like its pinning feature a lot - pin a shared file in lots of projects, and updates are tracked between all copies; however, I've concluded that approach actually hurts you in the long run! We've found that we tend to get MUCH more maintainable code by building shared code into 'black box' style modules, built in a central location (with unit tests, etc.) and shared by projects as needed.

Finally, I should say that SVN isn't perfect. Earlier versions (with the BDB back-end) were known to corrupt data from time to time, although I've never had a problem that couldn't be fixed by taking the database offline and calling BDB's recovery tools. It can also be quite sluggish when you have a very large (many gigs) project checked out, particularly when updating. Oh, and Windows users need to be careful to not check Thumbs.db into the repository (TortoiseSVN makes it very easy to click "select all" in the "what to commit" box), since those get conflicted ALL the time.