Hi all,
about a month ago I discovered DARCS http://darcs.net and I've been using it solidly ever since. It blows every VCS I've used out of the water except for BitKeeper, and BitKeeper is EXPENSIVE.
DARCS is changeset based, has atomic commits, has good merging capabilities, can work over SSH, works on unix and win32, etc, etc, etc. It is also very simple- despite the being command-line driven.
Every time you check out a working copy you actually get your own copy of the repository, meaning you can commit broken things to your local copy and they won't affect anyone else. You can then merge this local repository with a central repos to give others access to your changes. Every checkout creates a branch.
If you are using CVS, Subversion, SourceSafe or Perforce I suggest give it a go, I think you won't want to go back :)
The only issue I have with it is it isn't so great for binaries: it doesn't store binary diffs, but the whole binary every time :( So not so great for art asset management.
I have nothing to do with DARCS development, I've just been using it.
Binaries for lots of platforms are available from here http://www.scannedinavian.org/DarcsWiki/CategoryBinaries
It is nothing like subversion (or CVS). It's much more like BitKeeper or GNU Arch.
How you avoid that sort of mess is by updateting you local copy regularly from a central repository, but I haven't looked into that side of it (yet), I've only been using it on my own.
However BitKeeper manages to handle all the crazy amount of work the thousand-odd Linux kernel developers throw at it, and it uses the same "everyone gets a local repository" model. It just takes really smart merging.
The branches are very different to normal too, every checkout creates one. A commit is a patch against the whole repository, and they are identified by what I think is a 128-bit random number.
You can also pull in changes from other people's local repositories, and because the repository is made up of uniquely identified patch files it won't cause too many problems.
The ataomic commits in darcs come about because of this "commit == single patch file" system.
All I can suggest is try it out. I keep a repository on my home machine, on a master server at home, on my USB key drive, on my work/study machine at uni, and on a master server at uni, and I've had no problems at all keeping them all in sync.
I don't think I'm about to loose any work with that many backups [:D]
BitKeeper is free for open-source projects btw, though it seems a little too much like spyware for my taste.
Hey lorien - big thanks. I have been using darcs for serving / controlling our current game project to my lappy (my main repository now works on darcs and cvs - cvs is required because thats what the US people require). So I have been able to do a darcs get from my home server and do a push we needed to update, and it works flawlessly. The only problems I had with it, was when initially setting up the repository. Some of the binaries I had lying around in some folders caused it to bawk badly - once I found them and commited only what I needed, it has worked flawlessly since.I also realise too, that the binary thing was my fault, since the docs state you should specify binary types in the binary file in the repository.
The plusses over subversion are great - the local patching idea works so well. I also like the autopatch generation and emailing (very handy for team projects). Even the checking and repairing worked quite well (I intentionally damaged some of the repository to see whether it was intelligent enough to fix it :-) ).
Im also working on a specific front end for window for darcs - why? Well, I figure this is an _ideal_ system for art, design and code versioning. The only problem is getting a designer or artist to use another command line tool :-) .. so a pretty interface will hopefully help it get some decent usage with people who dont have time to learn new command line tools. I will post it when it gets completed, might be useful - it is intended to be pretty transparent to use (think alienbrain usage).
I have now switched the majority of my gear over to darcs, and wish to thank you lorien - this is a gem.
Yes, my own cross platform gear (since a simple lightweight UI with the components I wanted just isnt available :-) ). Will be using LuaGL that I have posted on Adelindie. Its just Lua+OpenGL + a little UI system I am building - being script its all nice rapid dev, and easy to modify (personalise?). I was even thinking of using a html/xml style display system - thus people can use their fave web builder to make a UI component - will see, the base set of gadgets are nearly complete, then its a matter of data... All operations for darcs will be through script, thus completely adjustable to suit the deployment.
Oh, and it all runs in OpenGL because I wanted something that had a completely consistant interface across platforms, without the hassle of various libraries (like the various toolkits available) and maintaining them and their compatibility. Also, there is an advantage in game development too :-), I plan to build an RPG type D&D game starting sometime in June...
Sounds interesting, might give it a looksee - reading the manual of features, it looks alot like subversion though (subversion has true atomic commits.. and such.)
The local commit sounds promising though, both possibly a benefit and a bane - Not having consistant versions across multiple clients and server could get a bit nasty when commits start to occur - how does the merging get handled with multiple clients committing their largely changed local copies (yes each is atomic, but resolving merges on large local changes would be a little nightmarish)? Would this mean youd have a list of client based branches that would now be in the repository?
That would be my only problem, Im a big fan of subversion with its more strict client/server design. But, I like the idea of a local repository - local versioning control would be handy. Would also be nice to have binary diffs too, currently we have all our projects data and source together in the one repository.