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 _______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
