Easy-to-backup version control for windows single developer

Question

I really need to get started with source control because I'm going absolutely crazy keeping track of my code and modifications as it is.

I'm a single developer on Windows. I use Eclipse for most of my development. Some of my projects are saved in wamp/www folder. Other non-PHP projects are in one or more Eclipse workspaces.

I don't work in a team with other developers, so my needs are different this way:

• I need something that lets me create a local repository. Don't want to depend on an outside site. What I need is the version control, not the external backup.

• Easy backup is really really important to me. I need to easily backup and restore the repository if I format my computer. I found this question that suggests a version control called Fossil which sounds really attractive in my case, because the whole system is a sqlite file. This would be super easy to backup and restore, but I'd prefer to something a little more well-known if there's any other well-known version systems that let me do the same thing.

fossil-scm.org/index.html/doc/tip/www/index.wiki

• I need something that would preferably play nice with wamp.

• I'm leaning on the side of git because a lot of people talk about it, but I wonder if it's really the right thing for me. I have a feeling it's best for teams.

Answer 1

One of fossil's strong advantages is that it was designed for "low ceremony". You don't have to do much configuration of anything, the database file itself can be kept locally, and it mostly just stays out of the way.

I've been using it on a handful of projects that are mostly single-principle-developer and am becoming quite attached to it.

It has a small user community partially because it hasn't had much overt marketing or evangelism. But that community makes up for its lack of marketing by being very responsive on its mailing list.

But it is also the version control standing behind SQLite, so it is both a user of SQLite for its database file, as well as an important supporting tool for SQLite's implementation.

Even for a single user, taking advantage of the ease of replication of a repository is a good way to provide a backup. Hide your repositories on a second machine with a minimal amount of CGI configuration and you can autosynch your work and have a live backup. Put that machine in a friend's house or at an inexpensive webhost and you have an offsite backup.

Edit:

See the fossil homepage for a good starting point. Any repository can be viewed via the built-in web interface which allows access to the timeline, ticket system, wiki, and project settings. It also can be used to view documents that are checked into the repository. In fact, all links to pages at the fossil web site are being served by a copy of fossil.

There is a decent book in draft form that walks through the process of using fossil for common tasks in a reasonably sized project.

The source repository for SQLite is also maintained by fossil, and its web interface is served by a copy of fossil as well. All the SQLite repositories and the fossil repository are kept synchronized among several geographically separated servers by cron jobs that do periodic fossil sync commands.

One easy way to get a hold of a repository with a rich history to play around with is to clone the source to fossil itself. To do this, put a copy of the fossil executable in your PATH, then in an empty folder somewhere say

C:...>fossil  clone  http://www.fossil-scm.org/  fossil.fossil
C:...>mkdir src
C:...>cd src
C:...>fossil open ../fossil.fossil

You are now standing in an open fossil repository containing the complete source code and revision history of fossil. With GCC, awk, and zlib available, you should be able to build it from source. (On Windows, it is easiest to build with MinGW from an MSYS bash prompt in my experience.)

You can periodically do fossil update to keep your clone current, and I recommend you try fossil ui to see the full power of the web interface with administrative access to your clone.