various suggestions for mr

[Joey Hess]

Adam Spiers wrote:
> So far mr is clearly winning :-)  However, cfgctl does have one or two
> tricks up its sleeve:
> 
>   - Config modules / packages / repositories / whatever you want to
>     call them are indexed by name within a unique namespace, rather
>     than by directory path, and packages are grouped together into
>     sections.  This allows you to easily run any of the actions on:
> 
>       - all the packages (just like running mr from $HOME)
> 
>       - a single package, just by specifying its name without needing
>         to know where it lives, e.g. "cfgctl --update zsh" would
>         update just the zsh repository
> 
>       - a section (i.e. group of packages) just by specifying its name
>         (e.g. "CLI" or "mail" or "Xorg") without needing to know where
>         anything lives, e.g. "cfgctl --pull Xorg" would update all
>         repos containing config relating to my Xorg (previously X11)
>         environment
> 
>       - any packages matching a regular expression e.g.
>         "cfgctl --update /emacs/"

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 at gnu:~>mkdir namespace
joey at gnu:~>cd namespace 
joey at gnu:~/namespace>ln -s ~/lib/sound
joey at gnu:~/namespace>ln -s ~/src/git-annex
joey at gnu:~/namespace>cd git-annex 
joey at gnu:~/namespace/git-annex>mr update
mr update: /home/joey/src/git-annex

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.

> All in all, I feel that mr has a better design than cfgctl, and has
> greater longevity.  So last night I spent an hour or two doing a quick
> proof of concept, to see whether I could extend mr to implement the
> functionality I require, in particular the integration with GNU stow.
> I'm pleased to say that so far it's looking very promising :-)
> This is pretty much all that's needed:

This seems close to something I could put in mr as an includable
library. Could use some documentation though.

-- 
see shy jo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 828 bytes
Desc: Digital signature
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20111028/38897f16/attachment.pgp>