OSDev.org

Until very recently I used no version control - just regularly backed up my source files. I was living in the dark ages!

I Love SVN now, and anyone not using version control on an OS project should seriously look at it

I totally agree with the above sentiment.. It's great!

I've hosted SVN for friends in the past... Always fun.

Same here, just read through most of the subversion book and I love it.

A hint from a long-time SVN user (since pre-1.0 times actually): svn diff and svn revert work even without a net connection - beautiful for on-the-road work.

I use CVS, but i hear more people raving about SVN. Is it much better?

senaus wrote:I use CVS, but i hear more people raving about SVN. Is it much better?

It all boils down to personal preference, I've used CVS in the past sure... but I started using SVN and it's amazingly easy to learn and use.

BTW I dig that "C++++" geek code:
I'll be first in line to get the new cybernetic interface installed into my skull.

So true.. So true.. But geek code needs an update.. It's getting rather old and annoying.

senaus wrote:I use CVS, but i hear more people raving about SVN. Is it much better?

I used both. SVN is not "much better", as it has not been designed to be so. It has been designed to fix the major problems with CVS, while being largely similar in concept and use.

If you need three major points where SVN exceeds CVS, I'd say:

1) diff and revert work offline;

2) the information you get via 'cvs update' ("what's the difference between my workdir and the repository?") you get via 'svn status', only better readable and without updating your workdir by accident;

3) instead of hiding version tags as hidden metadata, you make "tagged copies". It takes some getting used to, but you end up being able to browse, diff, and package versions without requiring any special commands or options. Look up the SVN documentation to find out how it's done.

All that without having to re-learn much, aside from using "svn status" instead of "cvs update" and the different "tagging" mechanism.

I don't think SVN vs. CVS is a matter of preference. It's more like matter of ignorance.

The single most important feature of Subversion over CVS is that where CVS versions files, Subversion versions directory trees. This means you that you can say (for a whole directory) gimme revision "2136" and you'll get revision 2136 of the source tree. With CVS you'd have to ask for a certain date, since version numbers are specific to files.

But that's not all about it, because if a commit fails (say a conflict) Subversion will rollback the whole transaction, not just the failing file, such that you don't end up in a situation where you just commited a large patch into the repository, and a single file failed, and fixing it takes a week, and now the repository is inconsistent.

So what that means for me doing OSDev, is that when I post a floppy image numbered with a Subversion revision number, and somebody reports a bug, I can immediately pull the exact same revision from my repository, look for the bug, and when I find it, see if it's in code that hasn't been replaced. No need for any special tagging, since the revision number is enough. Ofcourse if I need to start maintaining another branch, it's just a matter of copy in the repository (with version history linked back to the originals ofcourse).

Subversion was designed as an improved CVS. As such, one should more or less consider CVS to be deprecated. That said, many projects seem to be migrating to something distributed like Git, so maybe Subversion is becoming old-fashioned as well.

Thanks for the quick yet detailed replies everyone! Unfortunately i'm on my phone, so mine will have to be relatively brief.

SVN does sound impressive, particularly the ability to version subdirectories over files. Also, i never knew that CVS updates aren't atomic! That's shocking...

Now i'm going to upgrade, if sourceforge supports it (if only the Nokia web browser supported tabs).

Cheers,
The Senaus

senaus wrote:Now i'm going to upgrade, if sourceforge supports it

Indeed they do.

good thing about SVN over CVS (or at least at sourceforge) is that you don't have to worry abotu setting up 3 different things.. for CVS (which I never got working..) on sourceforge, I had to setup TurotoiseCVS, putty, and something else(think it was for openssh) had to make keys, and had to configure CVS... very confusing!

but with SVN, all I had to do was install TurtoiseSVN, setup my repo, import it, and just enter in my https url to my SVN repo...
plus doing the basics is very simple, still don't understand things like tags, but I haven't had a lot of use for them yet either..

hckr83 wrote:plus doing the basics is very simple, still don't understand things like tags, but I haven't had a lot of use for them yet either..

Tags and branches are considerably simple, When you tag a release you're simply making a copy and then placing it in another location.

It could be like "archiving" releases, If you tagged 1.0 and went back to work on 2.0(trunk..).. Someone could checkout the tagged (1.0) release

"branches" could be used to maintain version "1.0", You could make a 1.0.x branch and then if a bug effects 1.0 you can fix it there.. and later tag it as a new release like 1.0.1 for example.

You normally wouldn't make changes to the tags, It's more of a place where someone could locate older versions really. (And information like at what revision you tagged at etc..)

Hopefully this was clear, I myself only recently figured out how it all pulls together..

(Branches can be used for other things BTW, Like testing major features before it's ready for the mainstream trunk development..)

I basically new what tags and branches were, but TortuiseSVN would always give some mysterious error when I tried to make one..

hckr83 wrote:I basically new what tags and branches were, but TortuiseSVN would always give some mysterious error when I tried to make one..

I don't see why.. It's essentially just a glorified copy event..

A funny side note about trunk/branch development though...

When Firefox was at version 1.5x... Work had already began on Firefox 3 in trunk

Nice way to plan for the future

hckr83 wrote:still don't understand things like tags, but I haven't had a lot of use for them yet either..

actually SVN doesn't know branches or tags. These are nothing but cheap copies of a directory (ie. a cheap copy of a specific revision of /trunk to ie. /tags/version-1.0). The advantage is that it's a very cheap operation as the files aren't actually copied but rather referenced, so that the file history doesn't get lost. Of course if you make changes to copied files/directories those changes don't affect the original source (which is basically the concept of branches).