code versioning systems

If you want ask questions like:

- when did this bug start happening?
- when did I write this part of code?
- when was the last time I touched this file/directory?

then all of those things are much more difficult to find out when using zip files.

Storing a bunch of zip files is also not very space-efficient, which is a problem that gets worse once you want to start having assets.

And using a real version control system has another benefit: it becomes trivially easy to store your work onto a remote server.

It might take you time to learn how to use a VCS, but it's a one-time cost. Once you learn how to do it, it's super easy to set up a new project. I track every project with Git no matter how small it is.

Is this the official site? http://git.or.cz/ the page does not load for me.

I also forgot to mention that I ideally want one that works in win32 and linux. ( Or at least windows )

Git was developed to manage the Linux kernel, so obviously it runs there and on most Unices. Windows support is improving, but there's also Mercurial which works on the same principles.

Subversion gets my vote.

Perforce is also pretty commonly used, and is free if you only want one or two people accessing the repository.

You could look at darcs, which is fully distributed (ie, each working copy acts as a repository, unlike the above two where there is a shared central repository and working copies don't store history themselves).

And yes, in my experience it's definitely worth using version control, even for small projects.

John B

Quote:

Original post by ninmonkeys [1] What advantages does using a code version system give you? I'm wondering if it's worth using one for the small prototypes that I'm writing. Right now what I do is create a zip: project_vX.Y.Z.zip every once in a while.

You can maintain a 'history' of all files. It's nice to be able to make a change to the code without worrying about losing a working version. Assuming, you check in your files, after you make changes. Another advantage of SVN is easy backup. All you have to backup is the SVN directory.

Using a local SVN repository is very easy. It gets a little more complicated if you want to share it across a network. And tools like Tortoise SVN and TamTam SVN (http://www.daveswebsite.com/software/tamtamsvn/index.shtml) make it easy to manage the files.

I would recommend setting quite a few filters in SVN, so that built files (ie. exe, converted resource files, etc) are not checked in. Basically any file that is created by the compiler, or a conversion tool, doesn't need to be checked in.

Here's a tutorial on setting up a local SVN under Windows:
http://www.shokhirev.com/nikolai/programs/SVN/svn.html
There's a better tutorial somewhere, but I can't find it.

I've been using SVN for 3 or 4 months now, and couldn't imagine doing without it now, even though I am the only programmer on all of my projects. It adds very little time to the development process, but offers a bunch of advantages.

[Edited by - cdoty on June 14, 2008 11:32:05 PM]

Another vote for Subversion but as long as you are using version control I'm happy regardless of which one it is.

To me coding with version control is coding without fear. You'll never fear breaking, changing, forgetting or trying something with your code when using a version control system properly.

Yet another vote for Subversion.

I would vote for Perforce (the cross-platform P4V, specifically), since it's awesome and always super-fast and efficient, and has great tools, but the "free version" limitations inevitably hold you back eventually.

Quote:

Original post by bombinator-dev To me coding with version control is coding without fear.

Seconded, as well. You pretty much are guaranteed to have at least two copies of your code, as long as you stay sync'd with your repository. If the client hard disk dies, you still have the server code. If the server hard drive dies, you still have client code that you can submit to a newly-setup server.

Add that to all the other advantages that pinacolada first mentioned, and it's a no-brainer. Even for small projects. :)

And I'll add one more advantage: if and when you end up working for a team at a software company, you will have a foot in the door. Source control will already be second nature to you, and you won't have to hit the ground running (as fast).

Quote:

Original post by ninmonkeys Is this the official site? http://git.or.cz/ the page does not load for me. I also forgot to mention that I ideally want one that works in win32 and linux. ( Or at least windows )

Yeah that should be the site, it's strange that it isn't working.

If you were using just Linux or Mac then it would be easy for me to recommend Git, because it runs absurdly well on those platforms. It really is absurd. There are certain operations where you will say, "how the F can it do that so fast?"

But the Windows ports of Git are pretty bad so I can't recommend them. Instead, Mercurial and Subversion are both fine tools with good Windows support.

I've been playing around with Bazaar recently. Like darcs and Git, it's distributed, which also makes it easier to set up for a single developer.

With SVN I need to set up the SVN server software, and connect to that every time I want to update or commit code.

With Bazaar, everything works locally. Your local copy *is* your repository.

In any case, you should use version control for *everything* you make, no matter how small and insignificant.

I at first was going to host on my localhost -- but I forgot I have a SAMBA server running on the LAN that's my backup drive. So I can use that as my version server.

What's this mean? Subversion doesn't store a history? Does that mean I get no history at all, or I do but just on SAMBA?

Quote:

Original post by JohnBSmall Subversion gets my vote. Perforce is also pretty commonly used, and is free if you only want one or two people accessing the repository. You could look at darcs, which is fully distributed (ie, each working copy acts as a repository, unlike the above two where there is a shared central repository and working copies don't store history themselves). And yes, in my experience it's definitely worth using version control, even for small projects. John B

Quote:

Subversion doesn't store a history?

In Subversion only the server stores the full history. As a client, you need to be able to contact the server to access the history. The client stores a copy of whatever version it was last updated to, so locally you can tell which files you've modified.

This means that if you lost the server data, you lose your history. So you should backup your server data periodically.

In distributed systems, each peer has a full version history.

It means exactly what he said. In centralized systems, such as SVN, the revision history resides only on *one* common server. If you want to know what revision 762 looked like, you ask the server. When you commit a new revisino, the server takes a look at the previous revision and merges everything together.

In decentralized systems, like Git, Darcs or Bazaar, there is no central server. Instead, your client stores the revision history and all other "server" information locally

Quote:

Original post by niteice Windows support is improving, but there's also Mercurial which works on the same principles.

Seconded. It blows SVN out the water for my needs and has changed the way I work with code for the better. Indeed, I fail to see how it wouldn't be a better option for pretty much anyone else.

But the take-away is that you should definitely be using *a* version control system. It would be worth doing your own reading on the systems mentioned in this thread.