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

[Kalman Noel]

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.

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!).

    * 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:  

        “Also, if the shelf is a full repository and I store a lot of similar
        patches, or variations of the same patch, the files there will be full
        of conflict markers. Of course you suggest that I ignore the working
        area of the shelf repository, but it’d be easier if it were a separate
        concept from a repository.” 
      
      -- Yes, it's a question of comfort.  The idea of a “shelf”
      appeals to me for its potential simplicity:  Have no fear to ever lose a
      patch, all your (and other's) data is still on the shelf, ready to pull
      into your working directory whenever you wish!

I probably sound blasphemic if expressing the idea that in-repository branches,
i. e. a `darcs branch` command, would appeal to me, too, could they combine the
aspects of the previous paragraphs in an aesthetic (to me) way.


  [1]  http://bugs.darcs.net/issue447

----------------------------------------------------------------------
Get a free email account with anti spam protection.
http://www.bluebottle.com/tag/2