> > From: "Stephen J. Turnbull" <step...@xemacs.org> > To: Ganesh Sittampalam <gan...@earth.li> > Ganesh Sittampalam writes: > > > How do explicit branches help with coordinating work? Is it about > > addressing, i.e. people know that the repository is at location X and > > they just need to find out what branches are inside it? > > (1) Only one location to push to is needed. (also an addressing issue) > > (2) The VCS itself can tell you what branches are there. > > (3) Multiple new branches can be received with one VCS operation.
Yes, it's mostly about addressing and administration. Various git hooks make a lot of this even more useful. If you have a repository set up to send emails on pushes, then not only do you find out about other people's commits, you also find out about new branches. Put simply, git manages branches for you. With darcs, you have to manage them yourself. Sure, you could set policies about where to keep repositories, etc., but that's up-front work you need to do. You may need to write scripts to manage it. Consider this: Alice is working on a feature in branch "foo". She asks Bob to review it. Assume Bob's never checked out "foo" before. There are a few different things he could do, but one simple one is: git fetch git diff master origin/foo in darcs, assuming you had policies about standard locations, you might do something like this: cd $TOPREPO darcs get repo.net:/$TOPREPO/foo diff -r master foo Not only is this a bit more typing, you have to change directories to get a copy of the branch. So maybe you have a few aliases darcsget=cd $TOPREPO;darcs get repo.net:/$TOPREPO/foo;cd - darcsdiff=diff -r $TOPREPO/$1 $TOPREPO/$2 and now you've recreated some of the functionality that git provides (although a darcsdiff that's equivalent to gitdiff would be quite a bit longer). Next, suppose Bob asks Alice to review branch "bar". And maybe Alice has a different approach to code review, and wants to start with a large-scale overview. In git, she can use git fetch git checkout bar git log and see a list of commits. In particular, she may want to do got log --graph --decorate 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. You could put branch information into patch commit messages, but that doesn't really work very well since patches both commute and end up in multiple branches. Probably the closest is "darcs changes --from-tag=.*", but if bar is based on a feature branch that's under active development it may not have recent tags. In that case, it's not clear that bar is based on that feature-branch at all; AFAIK the only way to tell would be to manually inspect the patches. Or maybe you have a policy that every time you fork a branch, you create an initial tag for it. Not only is that more overhead for developers, then you end up with a lot of tags cluttering up the changelog. I like darcs a lot, and in particular the patch model matches my mental model very well. But since using git at work, I've come to realize that a lot of the effort of coordinating multiple branches, and how they inter-relate, falls out naturally from git's model, in a way for which darcs has no equivalent to the best of my knowledge. John L.
_______________________________________________ darcs-users mailing list darcs-users@darcs.net http://lists.osuosl.org/mailman/listinfo/darcs-users
