Getting started with Version Control System

I need to implement version control, even for just the developing I do at home. I have read about how great subversion is for the past couple of years and was about to dedicate myself to learning this on the side until I heard about Git being the up and coming version control system.

Given the situation, should I hold off and see which one comes out on top? What are their relative advantages?

One issue I noticed with Git is, there are not many full featured GUIs, which is important to many users on my team.

Also, wouldn't mind suggestions on how to get started with one or the other. (tutorials, etc.)

The most important thing about version control is:

JUST START USING IT

Not using version control is a horrible idea. If you are not using version control, stop reading right now and start using it.

It is very easy to convert from

cvs<->svn<->git<->hg

It doesn't matter which one you choose. Just pick the easiest one for you to use and start recording the history of your code. You can always migrate to another (D)VCS later.

If you are looking for a easy to use GUI look at TortoiseSVN (Windows) and Versions (Mac) (Suggested by codingwithoutcomments)

---

Edit:

>pix0r said: > >Git has some nice features, but you won't be able to appreciate them unless you've already used something more standard like CVS or Subversion.

This. Using git is pointless if you don't know what version control can do for you.

Edit 2:

Just saw this link on reddit: Subversion Cheat Sheet. Good quick reference for the svn command line.

Use subversion, it's easy to setup, easy to use, and has plenty of tools. Any future revision system will have an import from SVN feature, so it isn't like you can't change down the road if your needs grow.

The Subversion Book is your best bet for learning the tool. There may be other quick-start tutorials out there, but the Book is the best single reference you'll find.

Git has some nice features, but you won't be able to appreciate them unless you've already used something more standard like CVS or Subversion. I'd definitely agree with the previous posters and start with Subversion.

If you are new to versioncontrol read this:
Source Control HOWTO

Go for SVN. If you have never used source control before, it won't matter to you one way or the other.

Also, there is not a large amount of learning involved in using a Source Control system. If you learn one, you can easily switch over to another at a later date.

SVN is a great tool, and it should take care of most of your needs. And since it's been around, it has a fair sharer of GUI tools (TortoiseSVN, for example).

Go for SVN.

For a friendly explanation of most of the basic concepts, see [A Visual Guide to Version Control][1]. The article is very SVN-friendly.

[1]: http://betterexplained.com/articles/a-visual-guide-to-version-control/ "Better Explained: A Visual Guide to Version Control"

I've used RCS, CVS, SCCS, SourceSafe, Vault, perforce, subversion, and git.

I've evaluated BitKeeper, Dimensions, arch, bazaar, svk, ClearCase, PVCS, and Synergy.

If I had to start a new repository today, I'd choose git. Hands down.

It's free, fast, and under active development.

And you can use it as a client of any subversion repository using git-svn.

It rocks.

> @superjoe30 > > What about using source control on your own computer, if you're the sole programmer? Is this good practice? Are there related tips or tricks?

I find git is actually easier for this as you don't need a server or worry about entering URL's and so on. Your version-control stuff just lives in the .git directory inside your project and you just go ahead and use it.

5 second intro (assuming you have installed it)

cd myproject
git init
git add * # add all the files
git commit

Next time you do some changes

git add newfile1 newfile2 # if you've made any new files since last time
git commit -a

As long as you're doing that, git has your back. If you mess up, your code is safe in the nice git repository. It's awesome

• Note: You may find getting things OUT of git a bit harder than getting them in, but it's far more preferable to have that problem than to not have the files at all!

From my own experience with it, I wouldn't recommend git as an introduction to version control. I've been using it for a couple of months now, and my impression is that it's very powerful and - now that I've partially got my head around it - reasonably intuitive. However, the learning curve is very steep, even though I've been using version control for years. It also suffers from being too expressive - it supports many different workflows and development models, but the only guidance on "the best" way to use it is a few pages deep in a Google search, which also makes it tricky for a newcomer to pick up.

That said, it's possible that starting from a blank slate with git might actually be easier - my VCS experience is all with centralised version control (CVS, SVN, Perforce...) and part of my (ongoing!) difficulty with git has been understanding the implications of the distributed model. I did glance briefly at other DVCSes like Bazaar and Mercurial and they seemed to be somewhat more newbie-friendly.

Anyway, as others have said, Subversion is probably the easiest way to get used to the version control mindset and get practical experience of the benefits of VCS (rollback, branches, collaborative development, easier code review, etc).

Oh, and don't start with CVS. It's still in practical use, and has advantages, but IMHO it has too many historical quirks and implementation problems (non-atomic commits!) to be a good way to learn.

My vote goes to Subversion. It's very powerful, yet easy to use, and has some great tools like TortoiseSVN.

But as others have said before me, JUST START USING IT. Source control is such an important part of the software development process. No "serious" software project should be without it.

At my current job, my predecessor did not use any kind of version control. There are just mountains of folders in at least 3 different places where he kept all of his projects. Any random project folder can be expected to find at least one folder name "project (OLD)" and one named "project"

With version control, you never have to make copies of "safe" builds. You don't really have to worry about your IDE corrupting the file you're working on (I'm looking at you, REALBasic 5.5) because is so easy to commit (Read: Save) your work every day.

Needless to say, I installed version control the day after I found out it existed.

Also, TortoiseSVN makes committing to the database as easy as right clicking a folder.

Also try out visual svn for your server if you want to avoid any command line work.

If you are on Mac OSX, I found http://www.versionsapp.com/">Versions</a> to be an incredible (free) GUI front-end to SVN.

Git is superior to subversion, but it's a little bit out on the bleeding edge.

I'd say, if you're just getting started, jump on the edge; setup a free account @ http://github.com

They have educational material on site for setting up & using git.

Don't wait. Pick one, and go with it. All systems will have their pluses and minuses. Your power could go out, you computer gets stolen, or you forget to undo a major change and all your code gets fried while you're waiting to see who emerges victorious.

It's not that difficult to switch between version control systems. As others have mentioned the important thing is to start using anything as soon as possible. The benefits of using source control over not using source control vastly outweigh the differential benefits between different types of source control.

Remember that no matter what version of source control you are using you will always be able to do a brute force conversion to another system by laying down the files from your old system onto disk and then importing those raw files into the new system.

Moreover, being familiar with source control fundamentals is a very, very important skill to have as a software developer.

Yup, SVN for preference unless you really need git's particular features. SVN is hard enough; It sounds like git is more complicated to live with. You can get hosted svn from people like Beanstalk - unless you have in-house Linux people, I'd really recommend it. Things can go wrong horribly easily and it's nice to have someone else whose job it is to fix it.

There's an excellent tutorial on revision control from Eric Sink which is worth reading no matter which system you use.

Use TortoiseSVN (version.app if on mac). Just install and go. If you need a place to host your code look at http://beanstalkapp.com/

Coding Horror has a great post about how to set up Subversion on Windows.

Following the tutorial, I was able to get Subervsion and TortoiseSVN running locally, and I got the education I needed out of it.

As far as Git goes, it's probably a good idea to do a hands on experiment with both of them, to understand which fits your specific development practice.

SubVersion is the best Choice for you , As Karl Seguin pointed out Moving to Another Versioning System would not be a problem. also SVN has very goof Easy to use GUIs in the Client Side (TortoiseSVN).

http://www.snee.com/bobdc.blog/2007/08/getting_started_with_subversio.html http://dojo.jot.com/WikiHome/Getting%20Started%20With%20Subversion

If you choose to go with subversion and you want to host your own svn server, then there is a very nice and easy windows based server called VisualSVN server. It hides the complexity of setting up an apache server, you basically just go next next next. User configuration is handled with a webUI, instead of a config

<http://www.visualsvn.com/server/>

using a public serve rlike beanstalk is probably easier, but some people like to have their own repositories, either for speed or security

When I decided I must use a code versioning system, I looked around for any good tutorials on how to get started but didn't find any that could help me.

So I simplely installed the SVN Server and Tortoise SVN for the client and dived into the deepend and i learn't how to use it along the way.

Start using SVN for your actual work, but try to make time for fiddling around with Git and/or Mercurial. SVN is reasonably stable for production, but eventually you'll face a scenario where you'll need a distributed SCM, by which time you'll be properly armed and the new systems will be mature enough.

>superjoe30 writes: >>Related question (perhaps answers can be edited to answer this question as well): >> >>What about using source control on your own computer, if you're the sole programmer? Is >>this good practice? Are there related tips or tricks?

I use SVN for all of my personal projects. I started off with running svn on my home machine but eventually migrated over to Dreamhost. Their hosting packages that include Subversion are pretty reasonable.

If on a windows box a quick and dirty slution is CVSNT. Easy to use just set it up and works very well.

I myself prefer SVN but this is a good one for quick use.

I would definitely choose SVN over CVS, if only because people who learned source control using CVS, tend to use "svn delete" then "svn add" instead of "svn move". Which makes it harder to find all of the previous revisions of a specific file. And you can always upgrade to using git-svn. I personally think it is easier to learn than hg, but really the main reason to use SVN is it has largely become the de-facto version control system of Open Source Software.

If you ever plan on learning / using D it is almost mandatory to access the third party repositories, like DSource.

@superjoe30 Yes, absoluteley. Once you start using version control you never go back. I use it for everything, even my "home" folder.

@Orion Edwards Subversion does not require a server. You can access a local repository directly (via a client, of course), and there is no server process involved.

Just use TortoiseSVN, and you can live even without knowing actual Subversion commands... But that's bad. Luckily there will always be a “great opportunity” to learn them by heart — when your priceless repository first gets corrupted.

Yes, it happens.

As mentioned many times elsewhere, Just Do It. I was able to get started from scratch with Subversion under Windows in no time by reading the quick-start guide in the Red Book. Once I pointed TortoiseSVN at the repository, I was in business. It took me a while to get the finer points down, but they were minor humps to get over.

I'd suggest installing the Subversion Service instead of using file:// URLs, but that's mostly personal preference. For a repository stored on your development machine, file:// works fine.

From personal experience, svn would be my recommendation. You can even use a service like Beanstalk that offers free accounts (with limits obviously, but sufficient for any smallish project) to test the waters. But as others have said, git is superior and is likely worth looking into.

One major tip to ease the setup of an SVN server right now is to use a Virtual Appliance. That is, a virtual machine that has subversion pre-installed and (mostly) pre-configured on it - pretty much a plug & play thing. You can try here, here and here, or just try searching Google on "subversion virtual appliance".

I started to use subversion after reading Wil Shipleys blog.

So I started checking in code, one machine and dreamhost account. Then after I accidentally deleted a function and saved my project I knew I was in deep "dudu", but with subversion I just checked out the latest version of that file and it was like nothing happened.

I use version control for everything now. I am planning on moving over to git because it is faster, works offline, takes less space and oh boy is it faster.

An important reason to use svn rather than cvs is svn supports binary diffs. That may not matter to many programmers but if you are making a series of minor changes in a 10Mb image, having a unique copy each time in your repository can chew up space remarkably quickly.

I use TortoiseSVN on Windows but on the Mac have gone for the commercial CornerStone client over the (now commercial) Versions client. I found the range of free Mac clients, including RapidSVN, had enough pain points to bug me into shelling out real dollars. The safety-net that CornerStone provides for catching files I forgot to add to repository is worth the dollars to me. I spend a lot of time collaborating with a US client who is in an opposite time zone so can't afford screwups forgetting to add files!

Short answer: Subversion if you're the only one coding it or you're on site with everyone you work with. GIT if you're working with people in different sites and your code base is huge.

Subversion is really, really easy to setup and get using. It is also nice because you can do relatively complicated things with it too, like hook it up to Apache and use SSL or plug it into Trac for project management. There's so many tools available for Subversion that it's really a good choice.

GIT is much more useful for people who are on large teams working in a distributed environment. Linus T. developed it for the Linux team because he was unsatisfied with the capabilities of traditional repositories. Well worth learning if you ever plan to be working with people on open source projects.