[darcs-users] Fwd: Darcs Problems

[John Lato]

>
> From: "Stephen J. Turnbull" <stephen at xemacs.org>
> To: Ganesh Sittampalam <ganesh at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/darcs-users/attachments/20130228/3dbd54c7/attachment-0001.html>