On Fri, Oct 28, 2011 at 6:08 PM, Joey Hess <j...@kitenet.net> wrote: > Having two namespaces for the same thing does not strike me as > necessarily a good idea. > > But if you wanted to do that with mr, you could > maybe take advantage of a little-known thing it does with determining the > absolute path: > > joey@gnu:~>mkdir namespace > joey@gnu:~>cd namespace > joey@gnu:~/namespace>ln -s ~/lib/sound > joey@gnu:~/namespace>ln -s ~/src/git-annex > joey@gnu:~/namespace>cd git-annex > joey@gnu:~/namespace/git-annex>mr update > mr update: /home/joey/src/git-annex
I already did this; in fact I *had* to, in order to support GNU stow, which requires the stow package namespace to be the list of directories under a single "stow directory". If you look for $STOW_PKG_PATH in the code I originally posted, you'll see: STOW_DIR=$HOME/.cfg ... MR_NAME="`basename $MR_REPO`" ... STOW_PKG_PATH="$STOW_DIR/$MR_NAME" and then post_{checkout,update} call the install() function which does: ensure_symlink_exists "$STOW_PKG_PATH" "${MR_REPO%/}" However, the basename operation does not preserve the uniqueness property which $MR_REPO had, and that's why I say that we need an additional namespace. I can easily hack one, e.g.: [$HOME/.my-repos/foo] lib = MR_NAME=my-foo [$HOME/.upstream-repos/foo] lib = MR_NAME=your-foo but that's ugly, and requires execution of shell code which would make it difficult to implement a reverse lookup from package name to repo path. > The only problem with this approach is that it only work when inside the > symlinked directory, so mr update in ~/namespace won't update the > directories symlinked to there. Right. I feel like there's probably some elegant tweak we could make to mr which would solve all this cleanly without much effort, but I'm still trying to figure out what it is :-) Let's examine the status quo. Currently mr has: - a namespace for repositories (let's call it "R") which is a subset of the filesystem namespace, and values are specified in mr config section headers, - a namespace for mr config files (let's call it "C") which is a different subset of the filesystem namespace from R, and - a 1:many mapping between C and R, i.e. each config file can contain one or more repos. I don't think there's anything wrong with this design - in fact that 1:many mapping is a nice configuration-time grouping mechanism, but it's not quite enough to cater for some use cases. For instance, sometimes it's just not acceptable to update all repos at once, e.g. if you know that something is broken in repo X but you really need the updates from repos Y and Z. However mr cannot currently perform actions on repos at a finer granularity than how they are grouped in config files. So if you wanted to update your 'zsh' and 'emacs' repos, you could only do that if they were in a config file containing no other repos. In general, unless you restrict yourself to one config file per repo, there is no way to get mr to operate on an arbitrary subset of R. Similarly, if the 1:many mapping between C and R is used to logically group repositories together (e.g. "CLI", "X11" and so on), there is no way to get mr to operate on an arbitrary collection of groups. Another issue is that whilst "mr -c $config ls" extracts mappings from C to R, there's no way to extract the reverse mapping from R to C, i.e. "what config file do I need to use in order to perform actions on repo X?" In summary, maybe the tweak I'm looking for is simply to decouple configuration-time grouping of repos from run-time selection of which repos to act on: [$HOME/.my-repos/emacs] name = emacs [$HOME/.my-repos/zsh] name = my-zsh [$HOME/.upstream-repos/zsh] name = upstream-zsh which would allow: $ mr -r my-zsh,emacs And then the reverse mapping from R to C could be extracted via: [DEFAULT] showconfig = echo "$MR_CONFIG" (except at the moment, MR_CONFIG isn't changed via includes which could cause a problem.) _______________________________________________ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home