Monday, May 5, 2008

DVCS experience

Together with Ivan Veselov we are going to write an article. Living in XXI century, we certainly are going to use distributed version control system. But it appeared not so simple...

The best workflow I could think of is just sending patches by email. In the case of two peers it's more comfortable than holding some "central" repository, as commonly done for larger communities.

However, none of popular DVCS'es seems to be able to satisfy my requirements. There are just three of them: respect locales (we use cyrillic in UTF-8 locale), no published repository, all patches are sent in one email.

So, here is our experience:

darcs
I really enjoyed darcs send experience while working on xmonad, but in our case darcs got confused by the absence of the remote repository:
% darcs send

darcs failed:  Missing argument:  [REPOSITORY]
We had some discussion on #darcs, and several workarounds were proposed, but I didn't like them (and was really upset).
mercurial
Mercurial (with patchbomb extension from Bryan O'Sullivan) feels ok even if there's no remote repository, but it sends one email per commit. There's an option --bundle, but it uses some binary format, and also with this option for some reason hg starts to complain about the absence of remote repository. Another problem with hg is that it does something terrible with cyrillic when patches are sent by mail, so it isn't actually usable in our case
git
Git appeared the best today. The only its shortcoming is one-email-per-commit. At least it deals well with cyrillic and does not expect some remote repo. And I know that given enough time I can write alternative to git-send-email which will behave as I want. Unfortunately, we don't have much time at the moment.

2 comments:

kowey said...

Hello! This is just a follow-up comment to the Darcs Q&A session we hosted in during the Utrecht Hackathon in 2009-04.

So the problem here is that darcs needs to know what context it's apply patches to, because it does not guess where patches get applied (line numbers, etc). This makes merging more predictable, but it has a cost, which is that darcs needs to kno what context to apply patches to.

There's two ways to do what you want. One is to just create a "remote" repo on your local hard disk that has the patches that you and your buddy have in common. Then you can send patches to that repository.

Another way is to use the context file mechanism. For example, you could

cd common-repo
darcs changes --context > /tmp/our-context

These context files can then be used as an argument to darcs send or other commands:

darcs send --context/tmp/our-context

Alternatively, you could generate the context file from your own repository, and use a text editor to skim off the patches you know the other guy doesn't have yet.

A final useful thing to note is that you can use patch bundles as context files too, so that

darcs get remote-repo --context /tmp/my-bundle.dpatch

would get a version of the repository to which my-bundle can apply.

So in principle you could just keep re-using each other's patch bundles as context files. The price of this is that your patch bundles would grow bigger and bigger.

Phew! That's enough stuff for a blog post in its own :-) Hope this helps, and please don't hesitate to ask if you have any questions.

Roman Cheplyaka said...

Thanks for your comment! I didn't realize that I can use patch bundles as context files. That makes things simpler and probably can be automated.