[darcs-users] Tracking other people's work - when things get more complicated.

[David Roundy]

On Fri, Nov 30, 2007 at 11:10:15PM +0100, Kalman Noel wrote:
> I use revision control systems only to get developer's branches of interesting
> programs and libraries, so I'm not actually an “active” (da)rcs user.  However,
> issue 447 on the bug tracker (a wishlist item about a patch-shelf feature) [1]
> made me think again.  All this is, of course, rather speculative thinking.
> 
> As for updating my favorite libraries, `darcs pull --all` does the trick well.
> I wonder still how my workflow would look like if I were actually envolved in a
> larger project.  Looking at large projects managed by a distributed rcs other
> than darcs, say the linux kernel, I'd probably prefer if I had a mirror of all
> important repositories on my machine.  That is, I'd want to catch up with other
> people's working repositories as well as those repositories labelled “stable”,
> “unstable”, or labelled after a specific feature that is hard to implement.

I don't really see why you'd want a mirror of many different repositories
on your machine, unless you'll actually be compiling and testing the code
in those different repositories--in which case you really will want a
working directory for each one.

> In order to achieve such a mirroring with darcs, I would have to keep one
> directory for every branch that interests me.  I'd just had to be careful not to
> record anything in the mirror repositories, so they won't eventually differ from
> the remote branch.  There's nothing bad about this approach per se, but I
> suspect two problems with it:
> 
>     * Different branches of a project tend to be populated not only with
>       different patches, but often with the same patches, if those are sensible
>       to apply to e. g. both the stable or the unstable branch, or if a feature
>       is merged from a feature branch.  `darcs pull --all` will then download
>       any such patch for every repository I pull into, which potentially means
>       wasted network traffic as well as wasted disk space (no hard linking in
>       this scenario!).

This issue is (largely) fixed with the (new, essentially unused)
hashed-inventory format and its cache option.  Identical patches won't be
downloaded more than once, and will be hard-linked, so you need only store
one copy.

>     * I'm not convinced by the strategy described in [1] for never pulling a
>       specific patch, namely, creating a utility respository with all the
>       unwanted patches and then using `darcs pull --complement` against it.
>       While it's rather obvious that we have to keep the unwanted patches around
>       somewhere (we have to remember them, after all), but why in a seperate
>       repository?  The wish author describes the same “worries” about the
>       untidiness of this approach that are experienced by me:  

The idea of a list of "ignore" list is a long-standing wishlist item.  It's
pretty easy to implement, but noone has bothered.  You don't need to store
the actual patches for this functionality, just their ids.
-- 
David Roundy
Department of Physics
Oregon State University