This is why darcs currently doesn’t always works so well for keeping a “local branch” of some source. The local deviations are likely to cause exponential conflicts after time. Local deviations must either be isolated in some way (kept in separate files) so they never conflict, or changes from upstream needs to be merged in “by hand” and recorded as local patches that doesn’t conflict with the local changes.
Can anyone help me reconcile why I would give darcs a try over git if I can't do local branching?
First, you can do "local branching" by cloning your repository. On a local filesystem, `darcs get` is fast (uses hard links). And instead of `darcs branch`, you use `cd` (personally, I don't see how `cd` is worse, do you have some pointers about that?).
Second, the Darcs way of managing patches gets you "spontaneous branches". http://wiki.darcs.net/SpontaneousBranches The main advantage lies in that you can select the patches you push to other repositories. Say you work on some feature. Suddenly you need to fix a bug. The way to do it is, fix the bug right away then send the relevant patches (easy if you name your patches sensibly). Your unfinished feature simply won't get send (unless of course there's an actual conflict).
I see your point about local branching, but I do prefer git's approach for simplification on large branch sets. Some of the git repos I work with have upwards of 200 branches, having those in folders to be manually managed would be a little overwhelming.
I suspect there was less pressure for local branching because a lot of things you tend to want to do with branching, Darcs sort of trivially does with its easy cherry picking. But there are cases where cherry picking won't be enough and you want to have the separation, and it those cases, I can see where people would want to share working directories.
As one Darcs hacker among several (meaning I want it to be clear I'm not speaking for the rest of the team), the most important thing about Darcs is the friendly UI [and the friendly UI is made possible by the patch theory stuff]. And so my concern in trying to do Darcs branches is to do them in a way that keeps the UI very simple to learn and explore. We'll get there. Slowly.
Even without shared working directories, with the current branch as a dir workflow, you have no easy way to see what branches you have, how they relate, nor to express how they should relate (which one should follow which other one). For instance, this means that if I open a new branch on my public repository, there's no automated way for people pulling from my older branch to notice that fact. To me, it is a more compelling but rarely stated argument for in-vcs branching.
This is why darcs currently doesn’t always works so well for keeping a “local branch” of some source. The local deviations are likely to cause exponential conflicts after time. Local deviations must either be isolated in some way (kept in separate files) so they never conflict, or changes from upstream needs to be merged in “by hand” and recorded as local patches that doesn’t conflict with the local changes.
Can anyone help me reconcile why I would give darcs a try over git if I can't do local branching?