OSDev.org

I was just curious on everyone's opinion of using a versioning system even when you are the only developer there ever will be on the project? I understand the whole tracking aspect of it, but does it really pay off in the end?


Thanks,

I use git in nearly every project I start, simply because it's very simple to use. Just a "git init" first and then some "git add"'s and "git commit -a" when I changed or added something.
If I discover an error in my project it's easy to go back to a state where everything worked (via "git reset"). So I use git just because it's very simple to use.

The same goes for almost all versioning software (I use SVN - but that's just personal preference).

Using one can really save you if you accidentally delete a file, or do some modifications and you need to revert your changes. Either way, it does help, and with almost no cost at all (except a some extra space on your hard drive, but a hobby OS usually doesn't exceed 10 MB).

Hi,

I'd use a versioning system (I use SVN) for several reasons:

• Good backup and recovery system.
• You normally get diff which can be very useful when deciding whether to roll back. Some versioning systems let you use diff offline.
• Even if you're the only developer, you may want to use several PC's - I prefer SVN to storing everything on a portable drive.
• You can show that you have written your project progressively, rather than copying and renaming someone else's work.
• A tidy directory structure for branching and snapshots (if you follow the recommended repository structure!)

Cheers,
Adam

Note that if you've got a single computer with both the repository and the checked out copy on it, you're still going to need to do traditional backups anyway, as a dead hard drive is still a dead hard drive.

There are any number of online repository hosts that will give you a free repository on a server that you can access from your home machine. One of the better ones for OSDev, IMHO, is QuokForge (Disclaimer: I'm biased though, I am an admin). It's still in beta, but it's coming along fast.

Not using any version control for a software project larger than Hello World should be considered a crime. The point I'd like to add to what was already said (rollback, experimental branches etc. - you'll need it!) is that the version history also provides some kind of documentation that can be really valuable later on.

Which software to use is up to your personal taste. I for one prefer git.

I quite agree with the reasons cited above, but would like to cite another tool than cvs/svn/... : a versioning filesystem. It's wonderful, and you get a complete history of each and every modification you do. Sadly, there aren't any good (and stable) versioning filesystem for linux (and I guess the same for other mainstream OSes). Although deriving one from an existing fuse module is a matter of a few days.

I currently use copyfs ( http://n0x.org/copyfs/ ) which uses FUSE (Filesystem in User SpacE), and although it works well enough, it has a few quirks (mainly the lack of tools like diff etc., and a directory listing (ls) time proportionnal to the number of versions of every file, due to a bad storage structure / algorithm).

If you use this kind of software, though, you should put your compiled files outside the versionned directory, cause you'll run out of space otherwise. Versionned source files compress quite well, so space is not a concern for them.

See wikipedia for a list of alternatives : http://en.wikipedia.org/wiki/Versioning_file_system . You can also use a SVN mounted over the network, but it requires intalling apache and a few modules.

The whole idea of having a repository stored elsewhere, is because of the backup. You lose your backup, you still have a checked out version from which to continue. You lose your storage, you still have everything minus your last day's work.

Having a repository online allows you to check and work on your code from any place. I lost count how many questions I've answered here with the help of a quick svn browse. And it's not that hard to set up or get for free.

Same here: First thing I do when starting a new project is setting up a new SVN repository on my server.

(I'm a customer of LCube, who offer the least expensive web hosting including SVN services I've found. I can easily afford the 5,- Euro / Month, and being a paying customer has certain advantages over SourceForge and the like, especially in the support arena.)

My top 5 reasons to never work without VCS control:

• Off-site backup. If my computer fails violently, my sources won't be lost.
• URL-linkable files, diffs etc. - when I have a problem, I can link directly to the issue when asking for help on the 'net, and others have the ability to surf around in the supporting code.
• Commented commit history - even years after the fact, I can check when I did a change to a specific line of code, and more importantly, why I did it (because I believe in "one reason per commit").
• Branches - sometimes I want to try something, but don't want to muck up the main development line, so I create a branch. Maintaining a mainline and a branch without version control can get ugly very fast.
• Scaleability - you never know when your single-developer project might turn into a multi-developer project, or whether you might want to pass it on to a different developer altogteher. Providing the history of the code alongside with the latest version might help the poor guy who takes over, mightily.

There are more, but these are the most important to me.

@ Combuster:

You lose your backup, you still have a checked out version from which to continue.

You should have a backup of your VCS locally, not only the working directory. Losing the whole history, currently-not-checked-out branches etc. would be a real pain.

PS: There's another reason I haven't thought about initially - working under VCS control should be second nature to any developer. I would actually feel uncomfortable if I had to break long-ingrained habits like checking in stuff once the latest change works.

Yes, you should be using versioning for any project you will actually "use" (which would exclude framework tests and hello worlds)

I find it's a lot easier to begin a project by adding a new repo(local or remote) and adding in initial structure and start the project from there than to try to convert later on to using versioning(though only barely more difficult)..

I personally like SVN. For one person I would say Git seems a bit like overkill, but I've never used it so I can't judge.

earlz wrote:For one person I would say Git seems a bit like overkill

What does make it overkill in your opinion? Except in the same way as a lighter is overkill for making fire compared to a wooden drill, of course.

but I've never used it so I can't judge.

Probably yes.

For one, I dislike git because of the aggressive advertising done by those who use it. Example: See post above.

Second, I used RCS, CVS, and SVN privately. I used VSS, ClearCase, CVS and SVN at the office. I don't do distributed or mobile development on any of my projects. I don't do merges (more often than about once a year). I've got a remote-hosted SVN server of my own, and the provider doesn't even offer git as an alternative, so I would have to switch providers. (If you look at my list of reasons above, you'll see that having the repository off-site is important for me.)

All in all, git doesn't offer any advantage for me.

Solar wrote:For one, I dislike git because of the aggressive advertising done by those who use it. Example: See post above.

Now this is an objective fact that I won't contradict, even though my conclusion is a different one.

I'm not suggesting that git meets your workflow better than Subversion does (it certainly does for my workflow, though), I was just wondering why git qualifies as "overkill".

At least what I find confusing of git (and also, mercurial) is that revisions are represented by some hash code, and not an monotone incrementing integer. You don't have any idea of age and temporal ordering with those systems, while you do with SVN.

For example, if someone complains about a version, you can almost outright tell him if he should have updated first. I also find it useful in monitoring other people's projects as I can see how hard they have been working over time.

Kevin wrote:

earlz wrote:For one person I would say Git seems a bit like overkill

What does make it overkill in your opinion? Except in the same way as a lighter is overkill for making fire compared to a wooden drill, of course.

but I've never used it so I can't judge.

Probably yes.

http://github.com/aptana/

I'm not sure if that project is just laid out poorly, but if you can show me where the source is(without actually using `git`) in that project then I'd be thankful.

I find git to be massively confusing in my limited exposures of it... I especially get confused at the multiple "repos" per project bit..

and I don't like that you have to download the entire git repository/project in order to get the latest revision.