Eric Kow writes: > On Thu, Nov 20, 2008 at 12:59:26 +0900, Stephen J. Turnbull wrote: > > > > What do hg and git do differently that makes their local branching > > > cheaper? Simply because it's done within a single repo, and therefore > > > you only ever have one copy of the working tree? > > > > "Ever" is too strong, but "few workspaces" is important to me, yes, > > though YMMV. Darcs branches are also conceptually expensive because I > > have to decide where to put them, and I have to remember where they > > are when I want to refer to them. > > Thanks for clarifying that! > > So as I understand it, this being purely a UI issue.
Well, it's not. (a) Speed: creating the branches will still be slow in Darcs---I wouldn't be able to bear my git workstyle. I'd do what another contributor did recently, sneak in the typo fixes with all else I have to push at the moment. (b) Underlying design: Darcs is not DAG-based. Conceptually it's a something like a preordered set of patches. Instead of layering (totally ordered) branches over Darcs, why not explore the possibility of naming subsets of the repo (while respecting the preorder)? Maybe you could (eg) "block" a patch from being pulled (cf http://www.orcaware.com/svn/wiki/Svnmerge.py). You could do things like create "features" as a subset of patches. "Add up" the features to configure your app! This is already implicit in patch theory as I understand. What Darcs doesn't provide yet is a powerful, simple way to name and manipulate these subsets, except in a clumsy way be creating a new repo. _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
