What do LWN-ers use ?

What do LWN-ers use ?

I have settled on mercurial. darcs was a close contender. I love darcs' ability to pull a single patch. But, mercurial is fast, Fast, FAST, has lots of developers, plugin support, is written in python, fully cross-platform (I have to deal with some windows folks at work), and has some really great extensions already like view (inspired by gitk), forest (for handling multiple modules in a really nice way), the mercurial queue (handling patches on top of history like quilt but much more convenient), and transplant (for cherry-picking any patch you need to).

on top of that, mercurial has the best documentation I've seen for any DVCS, take a look at the book written about it.

If darcs were faster and had a view/gitk program, and was cross-platform for real (i.e., handled the line ending issue) I might revisit it again. hmm, that list got longer than I intended it to. :)

I also was intensely interested in git, but I just couldn't do it. I tried when it first came out, and used it for a simple project with lots of files where I knew there wouldn't be any branching. so I got a feel for the performance of pulling lots of patches (fast). I tried again about 3 months ago, saw improvement, but still couldn't do it. I felt it was easy to do easy stuff, but anything past that, you really had to jump off a cliff of a learning curve, and there were sharpened stakes at the bottom of the cliff!

the poster I'm replying to said there is great documentation for git now... please look at the mercurial book and then post a link to documentation that compares to that, for git. I haven't been able to find any good source of documentation at all, past man pages for some of the commands, and a couple of tutorials that get you into the absolute basics. nothing for how to deal with the aforementioned cliff with spikes at the bottom. :) I really would like to learn git though. but mercurial is just as fast as git, and MUCH easier to master.

For me, the big problem with mercurial is that it stores all state for each repository and has
no way of packing and/or combining things. Hence, every checkout takes the full history, where
with git you only need the additional objects and make it refer to another tree for most
objects, so another working tree is cheap, where with mercurial you copy all history again.

git has the option to use hard links when doing a clone. I've also seen some very spectacular
compression achieved with git packs. are you possibly comparing to a git repository that
hasn't been packed?

you're probably correct; I was probably comparing an unpacked git repo to 
a mercurial repo when I said mercurial took less space. 

more precisely, mercurial hard links all the history files (not the working copy files).

I could be wrong, but my understanding is that bzr is one of the few (or maybe the only?)
d-vcs that can share the history between multiple branches/checkouts, even under MS Windows
(without hard links or symlinks). If you are serious about cross-platform support, that's a
big feature, because you want branching to be cheap for everyone on all platforms.

If anyone can confirm/refute whether bzr and/or other systems can in fact do this, please do
so.

I use bzr on a number of projects, but I've found that git's in-place branching is much more
useful than bzr's shared-repository code. My brain and fingers don't do so well with multiple
directories for a project; it's much easier for me to have one directory and switch branches
at will.

Aside from that, having the set of branches stored in the repo itself is good from a
discoverability POV.

Anyway, my point was that shared repositories are less interesting when you have in-place
branching. (I like both bzr and git, so no flames please.)

I still don't use a dVCS, but I find in-place branches difficult for me. Not conceptually, but
I like to keep different branches around, like my Debian packages: I sometimes maintain both a
backport to Debian stable and a version of the same package in unstable (i.e. the current
development part). I would find it quite inconvenient to commit anything I currently try in
the development branch only to be able to safely switch to the backport's branch. However, I
know that some people like to commit any (reasonably sized) changes they do, while I usually
like to try my changes at least on a very basic level before committing and doing more
extensive tests. This sometimes means that I have changes uncommitted for days at a time.
Certainly something many developers don't like to have.
Anyway, based on this, I like mercurial better than git.

On the local storage of all the history vs. referencing the remote repository, I also prefer
the mercurial way. Once I cloned/branched a remote repository, I have all history at my
fingertips (not just the commit messages), even if the remote repository becomes unreachable
for some reason.

A git user would use a "topic branch" for each such string of unacknowledged changes. Then
when you have evalutated the changes just merge the branch or delete it at will.

Arguably a system that doesn't let you commit for days reminds me of svn, patch+diff or
similar old-fashioned systems.