Re:Darcs - Another open source version control system
by __david__ on Wednesday May 09, 2012 @05:32AM
(#3947740)
> You can imagine that I write a new filesystem for Linux, but I wait two years and the FS interface has changed drastically, the old patch is meaningless.
Perhaps, but the same could be said for git: the original commit is also meaningless because so much has changed since. I don't see that as a compelling argument.
Also, darcs lets you explicitly set dependencies on patches for the cases when it can't automatically detect them. The key philosophical difference is that darcs doesn't use time as an implicit dependency.
We use darcs on greenfelt.net. We push patches to our development repo which is where the other developers pull from. When we are happy with the state of the feature we push the patches (manually, usually from 2 to 10 patches) to our test site for a quick sanity check and then push that live.
In practice this means that we have half finished features/ideas on our development repo that never get pushed (the oldest patch is from 2009 and is still perfectly relevant, I might add). It also means that bug fixes can be fast-tracked through (directly from development repo to the production server), when appropriate. This is all handled by darcs in a very straightforward manner (of all the DVCSes I've used, darcs has the absolute simplest/best UI--git has been copying it a lot lately, see "git add -p").
The other thing that I found that we do constantly with darcs that isn't really doable in git is "darcs unpull". If someone pushes a patch to the development repo that is flawed you can just unpull it and tell them to go fix it. We use darcs-notify so that the team is emailed when someone unpulls a patch from the main repo because it requires everyone on the team to unpull the patch. Of course, most of the time a patch gets unpulled it happens before anyone else has pulled it. We've done this even on fast-moving projects and it's less scary than it sounds, and allows you to keep the coding standards high.
Along those lines, I've noticed that the darcs push and pull UI encourages code review by asking you explicitly which patches you want to push/pull. At the prompt you press 'v' and it prints the patch up so you can see what it actually does. It's a seemingly small thing but I've watched other developers change their coding/patch styles dramatically after using darcs and watching the patches go by. I tend to use "darcs push" as a last minute quick code review to make sure there's nothing overtly stupid in my patched. I can't tell you the number of times I've control-C-ed a darcs push and amended to make the patches correct.
One thing I've noticed in using both darcs and git extensively is that once you've really embraced each one they encourage different kinds of commits. Darcs really likes light, independent patches (since conflicts are not darcs's strong suit) and git likes more atomic feature patches (since a commit that touches 15 files doesn't have any drawbacks).
Perhaps, but the same could be said for git: the original commit is also meaningless because so much has changed since. I don't see that as a compelling argument.
Also, darcs lets you explicitly set dependencies on patches for the cases when it can't automatically detect them. The key philosophical difference is that darcs doesn't use time as an implicit dependency.
We use darcs on greenfelt.net. We push patches to our development repo which is where the other developers pull from. When we are happy with the state of the feature we push the patches (manually, usually from 2 to 10 patches) to our test site for a quick sanity check and then push that live.
In practice this means that we have half finished features/ideas on our development repo that never get pushed (the oldest patch is from 2009 and is still perfectly relevant, I might add). It also means that bug fixes can be fast-tracked through (directly from development repo to the production server), when appropriate. This is all handled by darcs in a very straightforward manner (of all the DVCSes I've used, darcs has the absolute simplest/best UI--git has been copying it a lot lately, see "git add -p").
The other thing that I found that we do constantly with darcs that isn't really doable in git is "darcs unpull". If someone pushes a patch to the development repo that is flawed you can just unpull it and tell them to go fix it. We use darcs-notify so that the team is emailed when someone unpulls a patch from the main repo because it requires everyone on the team to unpull the patch. Of course, most of the time a patch gets unpulled it happens before anyone else has pulled it. We've done this even on fast-moving projects and it's less scary than it sounds, and allows you to keep the coding standards high.
Along those lines, I've noticed that the darcs push and pull UI encourages code review by asking you explicitly which patches you want to push/pull. At the prompt you press 'v' and it prints the patch up so you can see what it actually does. It's a seemingly small thing but I've watched other developers change their coding/patch styles dramatically after using darcs and watching the patches go by. I tend to use "darcs push" as a last minute quick code review to make sure there's nothing overtly stupid in my patched. I can't tell you the number of times I've control-C-ed a darcs push and amended to make the patches correct.
One thing I've noticed in using both darcs and git extensively is that once you've really embraced each one they encourage different kinds of commits. Darcs really likes light, independent patches (since conflicts are not darcs's strong suit) and git likes more atomic feature patches (since a commit that touches 15 files doesn't have any drawbacks).