On Thu, Feb 28, 2013 at 11:14 PM, Stephen J. Turnbull <step...@xemacs.org>wrote:
> John Lato writes: > > > Put simply, git manages branches for you. With darcs, you have to > manage > > them yourself. > > That is it, in a nutshell. > > However, I think there are some aspects of daggy branches that don't > fit will with Darcs: > > > Next, suppose Bob asks Alice to review branch "bar". [...] > > and now, Alice can see not only the commits in "bar", but exactly where > > they are in the graph in relation to other branches. So she might see > > > > * hash (HEAD, bar) add bar-features > > * hash whitespace only > > * hash (stable-v.1.0) some stable commit > > * hash Merge branch old-cool-feature into stable-v.1.0 > > > > So she knows not only what Bob added to bar, but also that his code was > > based on the stable-v.1.0 branch, and exactly where Bob's work starts. > Now > > Alice has much better knowledge of the context of the bar code. > > > > With darcs, that sort of information isn't as readily available. > > True, but I don't think this DAG-based analysis makes sense in Darcs. > git branches are based on history, where history is a partially > ordered set of versions. A branch, of course, is totally ordered. > > It seems to me that, unlike the explicit history in a DAG-oriented > VCS, in a patch-oriented VCS with good support for cherrypicking, > history is implicit in the subset (of patches) relationship. Because > of cherrypicking, history is going to be more or less fuzzy. The > granularity of versions will also be much coarser than in git. > Because of commutation, I don't think it makes sense to think of every > subset of patches as a version, any more than every set of blobs is a > tree in git. > Agreed. This is a big part of my point, although in much clearer verbiage. A clear history is very useful for determining the context of current work. Git users value this history quite highly, as evidenced by the vast amount of time git users spend rebasing to clean up history, developing best practices for maintaining a clean history, etc. Patch-oriented VCS's don't really have anything comparable. I was thinking about a possible implementation a few days ago, and came up with this idea. Darcs could add another special patch, which I'm calling a base patch. A base patch would have the following properties: 1. Every patch applied after a base patch depends on the base patch. 2. A base patch doesn't depend on anything, but it conflicts anywhere its dependents would conflict. This would make a base patch act as essentially a starting point for a group of patches that logically work together (they're all based on the base patch). I think you'd also need either a tag or another special patch to act as the other end of a base patch. I think an equivalent statement is that a base patch doesn't commute with any of its dependents, but it does commute with any antecedent patches its dependents commute with. What the base patch gives you is the ability to pick commits without their dependencies. Suppose you have two branches, stable and dev, and you want to pick a patch 'hotfix' from dev to stable. hotfix will most likely have several other dependencies in dev, but you don't want those. You want to just take hotfix and fix any conflicts. So you would do the following: make a new repo 'tmp-dev', which has everything in 'dev' except 'hotfix' apply a base patch pull hotfix from the stable repo, cherrypick tmp-dev's hotfix (which will also bring the base patch) When trying to apply the base patch to the stable repo, the base patch will conflict everywhere hotfix's dependencies are unmet. To resolve the conflicts, we first undo hotfix, then apply hotfix' (the new patch). We don't actually touch the base patch when resolving conflicts, but after the resolution, the base patch's dependents have changed, so now it will only conflict where hotfix' would (since the original hotfix is undone). At this point, the developer would apply a tag (or end-base) patch and it's done. A lot of this work need not be done explicitly. For cherrypicking, darcs could ask the user for each patch whether to pull it or not, and automatically create an appropriate base patch. I haven't given too much thought to this, but there's probably substantial overlap with the darcs-rebase work that's been going on. I'd appreciate it if someone who's familiar with that (Ganesh?) could comment on this. If it's a good idea, maybe I could try to hack it up, or somebody else might be inspired to work on it. John L.
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
