Re: various suggestions for mr

2011-11-06 Thread Adam Spiers
On Sun, Oct 30, 2011 at 1:26 PM, Adam Spiers vcs-h...@adamspiers.org wrote:
 On Sat, Oct 29, 2011 at 5:52 PM, Joey Hess j...@kitenet.net wrote:
 Adam Spiers wrote:
 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.

 So pick an operation that does? tr / _ would do, for example.

 The other implicit requirement of this namespace was that it is
 easy to remember and type.  The rest of my previous email
 gives the context for this requirement.

OK, I've made a patch which fulfills this requirement pretty well.
Hopefully you'll find it reasonably clean and unintrusive:


https://github.com/aspiers/kitenet-mr/commit/b9a4e45aefe87c11ade1e4c4022e511f0d96d53c

With this patch, if you have .mrconfig files defining repositories:

[path/to/foo]
...

[path/to/bar]
...

then you can limit mr to only act on those via:

mr -r foo,bar $action

If there is a clash of directory names, then it can be resolved via a
new special parameter 'name':

[path/to/foo]
checkout = git clone ...
name = foo.git

[path/to/a/different/foo]
checkout = cvs checkout ...
name = foo.cvs

and then you can do:

mr -r foo.cvs update

etc.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: various suggestions for mr

2011-10-30 Thread Adam Spiers
On Sat, Oct 29, 2011 at 5:52 PM, Joey Hess j...@kitenet.net wrote:
 Adam Spiers wrote:
 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.

 So pick an operation that does? tr / _ would do, for example.

The other implicit requirement of this namespace was that it is
easy to remember and type.  The rest of my previous email
gives the context for this requirement.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: various suggestions for mr

2011-10-29 Thread Adam Spiers
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:~/namespaceln -s ~/lib/sound
 joey@gnu:~/namespaceln -s ~/src/git-annex
 joey@gnu:~/namespacecd git-annex
 joey@gnu:~/namespace/git-annexmr 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


Re: various suggestions for mr

2011-10-29 Thread Joey Hess
Adam Spiers wrote:
 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.

So pick an operation that does? tr / _ would do, for example.

-- 
see shy jo


signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

various suggestions for mr

2011-10-28 Thread Adam Spiers
Hi all,

I've been tracking my dot files and related stuff since around 1999,
and was very excited to discover this mailing list two years ago.
Since then I've only been able to lurk, but finally have a bit of
spare time to participate.

Since 2005 I have been using my own (as yet unpublished) Perl suite
called cfgctl to manage my dot files, which serves a similar to
purpose to mr - applying operations such as checkout, update
etc. to multiple repositories using multiple VCS backends.  However
its shortcomings have increasingly irked me, and just when I was being
to resign myself to a complete rewrite, I noticed that mr had already
stolen most of my thunder :-)

The main differences between mr and cfgctl are:

  - cfgctl's repository meta-data is written in pure Perl (and then
require'd at run-time) rather than one or more .INI-style
.mrconfig files.  When I originally wrote it, needing
functionality akin to mr's skip parameter I naively thought that
this would give me maximum flexibility, and I mistakenly
underestimated the value of using a DSL.

  - cfgctl only has a fixup hook (i.e. post-checkout/update), and no
hooks for any other actions.

  - cfgctl is not nearly as extensible.  It doesn't support writing
arbitrary new actions either globally or per repo.

  - With hindsight cfgctl should have been made more shell-oriented in
general, because the kinds of tasks required for managing dot
files/repos, building/install packages etc. are much more easily
achieved in shell than in Perl.

  - Adding support for a new VCS backend is more work in cfgctl,
because it requires writing a new Perl subclass of Cfg::Pkg::Base.

  - cfgctl is harder to type than 'mr'.

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/

  - cfgctl integrates out of the box with GNU stow.  Based on this
list's frequency of discussion on fake bare / detached git
repos, it seems that most people here have an aversion to the
symlink approach to managing dot files in $HOME.  This surprises
me as I have been using them very successfully for 12 years,
although I will leave that debate for another thread.

  - cfgctl's internals have a reasonable amount of pod / comments.
mr's code, whilst mostly self-explanatory at the high-level, does
have a few very long subroutines which I feel would gain clarity
by being refactored into some appropriately-named smaller subs.

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:

- 8 - 8 - 8 - 8 - 8 -
[DEFAULT]
lib =
STOW_DIR=$HOME/.cfg
STOW_TARGET=$HOME
MR_NAME=`basename $MR_REPO`
#
set_stow_common_opts () {
STOW_PKG_PATH=$STOW_DIR/$MR_NAME
stow_common_opts=-t $STOW_TARGET -d $STOW_DIR
}
#
install () {
set_stow_common_opts
ensure_symlink_exists $STOW_PKG_PATH ${MR_REPO%/}
}
#
ensure_symlink_exists () {
[ $# = 2 ] || error CONFIG BUG: Usage: ensure_symlink_exists
SYMLINK TARGET
symlink=$1
required_target=$2
if [ -L $symlink ]; then
actual_target=`readlink $symlink`
if [ $actual_target = $required_target ]; then
return
else
error Symlink $symlink already points to
$actual_target, cannot point to $required_target; aborting.
fi
fi
[ -e $symlink ]  error Cannot create symlink $symlink -
already exists; aborting.
ln -s $required_target $symlink
}
#
stow () {
set_stow_common_opts
command stow $stow_common_opts $MR_NAME
}
restow () {
set_stow_common_opts
command stow -R -p $stow_common_opts $MR_NAME
 

Re: various suggestions for mr

2011-10-28 Thread Dieter Plaetinck
Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up 
and it seems very nice.
i haven't run it yet, but (for those who don't want to read the long 
description) from the description it seems like a simple and elegant tool,
which you give a directory (i want symlinks here) and a bunch of package 
directories (all files in here must be symlinked)
and it will do the right thing on package additions and removals.

Some people have actually already written symlink-managers, probably not 
knowing Stow existed.
So yeah, looks neat.
Carry on the discussion now :)

Dieter

___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: various suggestions for mr

2011-10-28 Thread Adam Spiers
On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck die...@plaetinck.be wrote:
 Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up 
 and it seems very nice.
 i haven't run it yet, but (for those who don't want to read the long 
 description) from the description it seems like a simple and elegant tool,
 which you give a directory (i want symlinks here) and a bunch of package 
 directories (all files in here must be symlinked)
 and it will do the right thing on package additions and removals.

Yes, it is pretty nice (although the code base is very old-fashioned).

One thing it does which I guess other symlink managers wouldn't, is
called tree folding - i.e. it makes intelligent decisions about when
to symlink to a subdirectory vs. to individual files within that
subtree:

  http://www.gnu.org/software/stow/manual.html#SEC4

For example, imagine I have a stow package called 'foo' which wants to
install a file to ~/local/lib/perl/Acme/Foo.pm (by install, I mean
set up a symlink so that that path points to the Foo.pm inside the
stow package).  If ~/local doesn't already exist, and 'foo' is the
only stow package which installs anywhere under ~/local, then stow's
tree folding feature will ensure that ~/local is a symlink back to
$STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.

However I might very well want to manually place other files inside
~/local which have nothing to do with stow, let alone the 'foo' stow
package.  It might make sense to have ~/local/lib/perl/Acme/ be a
symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
the tree would be undesirable.  This is easily overcome by creating a
special stow package (which I call 'ANTIFOLD') which contains (empty)
dummy files called .no-stow-folding in those trees.  So I run a simple
little custom shell script:

$ unfold ~/local/lib/perl5

which creates an empty file

$STOW_DIR/ANTIFOLD/local/lib/perl5/.no-stow-folding

and (re)installs the 'ANTIFOLD' stow package, which causes stow to
automatically split the ~/local/lib/perl5 tree open so that

~/local/
~/local/lib/
~/local/lib/perl5/

are all normal directories, and ~/local/lib/perl5/Acme becomes the
symlink.  Problem solved!
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: various suggestions for mr

2011-10-28 Thread Dieter Plaetinck
On Fri, 28 Oct 2011 14:34:16 +0100
Adam Spiers vcs-h...@adamspiers.org wrote:

 On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck
 die...@plaetinck.be wrote:
  Sorry that I go slightly off-topic but you mentioned Gnu Stow, I
  looked it up and it seems very nice. i haven't run it yet, but (for
  those who don't want to read the long description) from the
  description it seems like a simple and elegant tool, which you give
  a directory (i want symlinks here) and a bunch of package
  directories (all files in here must be symlinked) and it will do
  the right thing on package additions and removals.
 
 Yes, it is pretty nice (although the code base is very old-fashioned).
 
 One thing it does which I guess other symlink managers wouldn't, is
 called tree folding - i.e. it makes intelligent decisions about when
 to symlink to a subdirectory vs. to individual files within that
 subtree:
 
   http://www.gnu.org/software/stow/manual.html#SEC4

IMHO this feature is just common sense and it's among the first things
I think of when I'm thinking what would I want a symlink manager to do?,
so I would expect that people who implement symlink managers either
also do something like this, or at least list it as a todo.

 For example, imagine I have a stow package called 'foo' which wants to
 install a file to ~/local/lib/perl/Acme/Foo.pm (by install, I mean
 set up a symlink so that that path points to the Foo.pm inside the
 stow package).  If ~/local doesn't already exist, and 'foo' is the
 only stow package which installs anywhere under ~/local, then stow's
 tree folding feature will ensure that ~/local is a symlink back to
 $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.

Don't you mean to $STOW_DIR/foo/local ?

 
 However I might very well want to manually place other files inside
 ~/local which have nothing to do with stow, let alone the 'foo' stow
 package.  It might make sense to have ~/local/lib/perl/Acme/ be a
 symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
 the tree would be undesirable.  This is easily overcome by creating a
 special stow package (which I call 'ANTIFOLD')

this seems a bit messy though. Once you go the way of having a tool 
automagically
manage all your symlinks, why not just have the discipline to put all your files
in appropriate packages? so that you never _need_ to create antifold packages?
what you're doing seems a bit like running into the opposite direction.

Dieter
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: various suggestions for mr

2011-10-28 Thread Adam Spiers
On Fri, Oct 28, 2011 at 2:43 PM, Dieter Plaetinck die...@plaetinck.be wrote:
 On Fri, 28 Oct 2011 14:34:16 +0100
 Adam Spiers vcs-h...@adamspiers.org wrote:

 On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck
 die...@plaetinck.be wrote:
  Sorry that I go slightly off-topic but you mentioned Gnu Stow, I
  looked it up and it seems very nice. i haven't run it yet, but (for
  those who don't want to read the long description) from the
  description it seems like a simple and elegant tool, which you give
  a directory (i want symlinks here) and a bunch of package
  directories (all files in here must be symlinked) and it will do
  the right thing on package additions and removals.

 Yes, it is pretty nice (although the code base is very old-fashioned).

 One thing it does which I guess other symlink managers wouldn't, is
 called tree folding - i.e. it makes intelligent decisions about when
 to symlink to a subdirectory vs. to individual files within that
 subtree:

   http://www.gnu.org/software/stow/manual.html#SEC4

 IMHO this feature is just common sense and it's among the first things
 I think of when I'm thinking what would I want a symlink manager to do?,
 so I would expect that people who implement symlink managers either
 also do something like this, or at least list it as a todo.

 For example, imagine I have a stow package called 'foo' which wants to
 install a file to ~/local/lib/perl/Acme/Foo.pm (by install, I mean
 set up a symlink so that that path points to the Foo.pm inside the
 stow package).  If ~/local doesn't already exist, and 'foo' is the
 only stow package which installs anywhere under ~/local, then stow's
 tree folding feature will ensure that ~/local is a symlink back to
 $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.

 Don't you mean to $STOW_DIR/foo/local ?

Yes, sorry :)

 However I might very well want to manually place other files inside
 ~/local which have nothing to do with stow, let alone the 'foo' stow
 package.  It might make sense to have ~/local/lib/perl/Acme/ be a
 symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
 the tree would be undesirable.  This is easily overcome by creating a
 special stow package (which I call 'ANTIFOLD')

 this seems a bit messy though. Once you go the way of having a tool 
 automagically
 manage all your symlinks, why not just have the discipline to put all your 
 files
 in appropriate packages? so that you never _need_ to create antifold 
 packages?
 what you're doing seems a bit like running into the opposite direction.

I don't understand what you mean; please could you elaborate?
As far as I'm aware, all my files are nicely separated into appropriate
packages, but that doesn't solve the problem.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


to symlink or not to symlink (was: Re: various suggestions for mr)

2011-10-28 Thread Adam Spiers
So with the direction this subthread is going, it seems a good time
to ask everyone:

   (a) Are your ~/.* files symlinks or not?
   (b) Why?

I get the impression that some people on this list prefer to use git's
detached working trees feature, e.g.

  http://www.mail-archive.com/vcs-home@lists.madduck.net/msg00078.html

so I'm interested to understand the reasons behind this preference.
As I see it, the benefits of using a symlink manager like GNU stow
are:

  - You can immediately see which files under ~ are managed by it.

  - You can immediately see which stow package any symlinked file
under ~ belongs to, e.g.

   lrwxrwxrwx. 1 adam adam 21 Oct 20 10:20 /home/adam/.zshrc -
.cfg/shell-env/.zshrc

  - Zero issues with .gitignore

  - No extra effort required to prevent other tools such as
dvcs-autosync getting confused by having unrelated files in the
working directory.

  - No need to use something like vcsh to temporarily and manually
adjust git environment variables to point the correct bare repo
(and this approach doesn't work anyway if you like to commit from
within a long-running editor process).

  - Highlights file conflicts between packages which could otherwise
cause confusion.

  - Ties in nicely with the UNIX way of one tool per job: mr manages
the layer of interaction with upstream repositories, and
integrates via action hooks with the symlink manager which manages
the local package layer.

But I'm sure there are some disadvantages too.  Anyone care to
elaborate?

Cheers,
Adam

On Fri, Oct 28, 2011 at 2:34 PM, Adam Spiers vcs-h...@adamspiers.org wrote:
 On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck die...@plaetinck.be 
 wrote:
 Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it 
 up and it seems very nice.
 i haven't run it yet, but (for those who don't want to read the long 
 description) from the description it seems like a simple and elegant tool,
 which you give a directory (i want symlinks here) and a bunch of package 
 directories (all files in here must be symlinked)
 and it will do the right thing on package additions and removals.

 Yes, it is pretty nice (although the code base is very old-fashioned).

 One thing it does which I guess other symlink managers wouldn't, is
 called tree folding - i.e. it makes intelligent decisions about when
 to symlink to a subdirectory vs. to individual files within that
 subtree:

  http://www.gnu.org/software/stow/manual.html#SEC4

 For example, imagine I have a stow package called 'foo' which wants to
 install a file to ~/local/lib/perl/Acme/Foo.pm (by install, I mean
 set up a symlink so that that path points to the Foo.pm inside the
 stow package).  If ~/local doesn't already exist, and 'foo' is the
 only stow package which installs anywhere under ~/local, then stow's
 tree folding feature will ensure that ~/local is a symlink back to
 $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.

 However I might very well want to manually place other files inside
 ~/local which have nothing to do with stow, let alone the 'foo' stow
 package.  It might make sense to have ~/local/lib/perl/Acme/ be a
 symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
 the tree would be undesirable.  This is easily overcome by creating a
 special stow package (which I call 'ANTIFOLD') which contains (empty)
 dummy files called .no-stow-folding in those trees.  So I run a simple
 little custom shell script:

    $ unfold ~/local/lib/perl5

 which creates an empty file

    $STOW_DIR/ANTIFOLD/local/lib/perl5/.no-stow-folding

 and (re)installs the 'ANTIFOLD' stow package, which causes stow to
 automatically split the ~/local/lib/perl5 tree open so that

    ~/local/
    ~/local/lib/
    ~/local/lib/perl5/

 are all normal directories, and ~/local/lib/perl5/Acme becomes the
 symlink.  Problem solved!

___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: various suggestions for mr

2011-10-28 Thread Dieter Plaetinck
On Fri, 28 Oct 2011 15:00:52 +0100
Adam Spiers vcs-h...@adamspiers.org wrote:

 On Fri, Oct 28, 2011 at 2:43 PM, Dieter Plaetinck
 die...@plaetinck.be wrote:
  On Fri, 28 Oct 2011 14:34:16 +0100
  Adam Spiers vcs-h...@adamspiers.org wrote:
  However I might very well want to manually place other files inside
  ~/local which have nothing to do with stow, let alone the 'foo'
  stow package.  It might make sense to have ~/local/lib/perl/Acme/
  be a symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks
  higher up the tree would be undesirable.  This is easily overcome
  by creating a special stow package (which I call 'ANTIFOLD')
 
  this seems a bit messy though. Once you go the way of having a tool
  automagically manage all your symlinks, why not just have the
  discipline to put all your files in appropriate packages? so that
  you never _need_ to create antifold packages? what you're doing
  seems a bit like running into the opposite direction.
 
 I don't understand what you mean; please could you elaborate?
 As far as I'm aware, all my files are nicely separated into
 appropriate packages, but that doesn't solve the problem.


You wrote However I might very well want to manually place other files
inside ~/local which have nothing to do with stow.

Now you wrote As far as I'm aware, all my files are nicely separated
into appropriate packages.

That confuses me.  I was responding to your approach in which you describe how 
you
make stow unfold by creating a dummy 'antifold' package which would allow you 
store
files not managed by stow in your ~/local

Dieter
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: various suggestions for mr

2011-10-28 Thread Adam Spiers
On Fri, Oct 28, 2011 at 3:26 PM, Dieter Plaetinck die...@plaetinck.be wrote:
 You wrote However I might very well want to manually place other
 files inside ~/local which have nothing to do with stow.

 Now you wrote As far as I'm aware, all my files are nicely
 separated into appropriate packages.

 That confuses me.  I was responding to your approach in which you
 describe how you make stow unfold by creating a dummy 'antifold'
 package which would allow you store files not managed by stow in
 your ~/local

Ah, I see!  Well, in an ideal world, I would have time to ensure that
every single file in my home directory is perfectly managed as a stow
package :-) But in practice is there anyone who really achieves that?
There are many cases where it just isn't worth the effort.  Perhaps
~/local was a bad example, because that path is suggestive of a
typical GNU-like installation sequence:

./configure --prefix=~/local
make install

in which case I agree it's not much more effort to do:

./configure --prefix=~/.stow/$pkgname
make install
# now install via stow

but there are plenty of other examples where it is not pragmatic to
spend the time ensuring every single file is controlled by stow, e.g.

./configure --prefix=~
make install# this puts some files in ~/doc

# days/weeks/months later:
emacs ~/doc/shopping-list.txt

Without a ~/doc/.no-stow-folding file present, suddenly you have
accidentally put your shopping list inside a third party piece of
software :-) And it's not worth having a stow package for a shopping
list which will probably be deleted tomorrow anyway.

Another approach would be to add an option to stow that disables tree
folding entirely; it shouldn't be hard to do that.  But personally I
find tree folding useful as long as it's managed well.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: to symlink or not to symlink (was: Re: various suggestions for mr)

2011-10-28 Thread Richard Hartmann
mumble..

[1] https://github.com/RichiH/vcsh
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home


Re: to symlink or not to symlink (was: Re: various suggestions for mr)

2011-10-28 Thread Adam Spiers
On Fri, Oct 28, 2011 at 4:09 PM, Richard Hartmann
richih.mailingl...@gmail.com wrote:
 On Fri, Oct 28, 2011 at 16:14, Adam Spiers vcs-h...@adamspiers.org wrote:

 FYI: My version of vcsh [1] is different from madduck's. He graciously
 agreed to let me have the name and may switch over to my
 re-implementation soon from what I heard from him.

Ah thanks, I did wonder about that.

   (a) Are your ~/.* files symlinks or not?

 Not any more.

   (b) Why?

 It seems unclean, at best. I generally try to avoid symlinks where
 possible. There are very valid use cases for links (soft: git-annex,
 hard: some backup schemes, sharing funny pics etc on shared disks,
 cloning a directory to work with it iin git-annex while keeping the
 old directory full intact...) but this is not one, imo.

 It comes down to preference.

Sure, there's no right and wrong.  It sounds like your preference is
based on a sense of aesthetics rather than more concrete technical
arguments?  Not that there's anything wrong with that - aesthetics are
important too.  But if you are aware of some specific technical
advantages of avoiding symlinks, I'd be very interested to hear them
so that I can weigh them up against the alternative.

  - You can immediately see which files under ~ are managed by it.

 for repo in vcsh list; do vcsh run repo git ls-files; done

 Alias that away in case that's a valid use case, for you.

Sure, although that's assuming you have a shell to hand.  Almost
always the case, but sometimes it's handy to be able to see with
nothing more than a file manager (e.g. sftp).

More significantly, it doesn't tell you which files are *not* managed
by it.  Without symlinks, you have to iterate over all your
repositories, and then filter out those files from the set of files
you are interested in looking at.

  - You can immediately see which stow package any symlinked file
    under ~ belongs to, e.g.

 See above. But I sincerely doubt that my .vimrc will ever end up in my
 zsh repo.

Well, I'm obviously more prone to mistakes than you ;-) But that
aside, I want this setup to support checkout of a large number of
third party software packages which I'm either trying out, using, or
even collaborating with development.  In that case, there are a large
number of unfamiliar looking files installed in my home directory, so
it's not always immediately obvious where files have come from.

  - No extra effort required to prevent other tools such as
    dvcs-autosync getting confused by having unrelated files in the
    working directory.

 Never heard of that, I use mr. And vcsh was written with mr in mind.
 Thus, it integrates nicely.

To clarify, I'm thinking of using dvcs-autosync in parallel with mr,
not instead of it.

  - No need to use something like vcsh to temporarily and manually
    adjust git environment variables to point the correct bare repo
    (and this approach doesn't work anyway if you like to commit from
    within a long-running editor process).

 How is that a disadvantage when a tool hides it from you?

I don't know vcsh well enough to know which tool you are referring to
or what it would hide.  But I can't see how an approach which (in my
very limited understanding) is based on altering environment variables
would work without requiring a restart of my editor.  If you're a vim
user who starts up your editor every time you edit a new file, that
will work fine for you.  But it doesn't gel with my personal workflow.

  - Highlights file conflicts between packages which could otherwise
    cause confusion.

 Again, shooting your own foot will always end up in a shot foot.

Not if there's a bullet-proof barrier in between your gun and your
foot :-)  Which is exactly my point - I'm saying that if you had the
same (relative) file path in two different stow packages, stow will
refuse to install one over the top of the other; instead it will tell
you that you're trying to do something stupid.

  - Ties in nicely with the UNIX way of one tool per job: mr manages
    the layer of interaction with upstream repositories, and
    integrates via action hooks with the symlink manager which manages
    the local package layer.

 So does vcsh.

Yeah, I admit that one wasn't a very strong argument against not
having symlinks :)

 But I'm sure there are some disadvantages too.  Anyone care to
 elaborate?

 I did not look at stow, so no idea.

I meant disadvantages to using symlinks in general.  It doesn't really
matter what method you use for managing symlinks, the end result is
pretty much the same (modulo tree folding).

 One point, though: If i delete my repos, my system continues to work
 as expected. If you do the same, all your configs are gone.

If I did something that stupid, I'd prefer to know about it sooner
rather than later :-)  Besides:

  - An accidental rm ~/.zshrc seems much more likely than an
accidental

  rm -rf ~/path/to/all/my/git/repos/I/rarely/access/directly

because my pwd is $HOME far more often 

Re: various suggestions for mr

2011-10-28 Thread 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@gnu:~mkdir namespace
joey@gnu:~cd namespace 
joey@gnu:~/namespaceln -s ~/lib/sound
joey@gnu:~/namespaceln -s ~/src/git-annex
joey@gnu:~/namespacecd git-annex 
joey@gnu:~/namespace/git-annexmr 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


signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home

Re: to symlink or not to symlink (was: Re: various suggestions for mr)

2011-10-28 Thread Richard Hartmann
On Fri, Oct 28, 2011 at 18:23, Adam Spiers vcs-h...@adamspiers.org wrote:

 Ah thanks, I did wonder about that.

Yah, I hope the old version will drop off of google at some point to
avoid confusion.


 Sure, there's no right and wrong.  It sounds like your preference is
 based on a sense of aesthetics rather than more concrete technical
 arguments?  Not that there's anything wrong with that - aesthetics are
 important too.  But if you are aware of some specific technical
 advantages of avoiding symlinks, I'd be very interested to hear them
 so that I can weigh them up against the alternative.

Well, symlinks (on files!) work pretty much exactly as files in the
relevant use cases so there's no real downside.


 Sure, although that's assuming you have a shell to hand.  Almost
 always the case, but sometimes it's handy to be able to see with
 nothing more than a file manager (e.g. sftp).

Definitely not a use case for me. If you really do access $HOME via
ftp, that might be useful, though. Though, arguably, if you are not in
an interactive shell, what do you care about where what info lives?


 More significantly, it doesn't tell you which files are *not* managed
 by it.  Without symlinks, you have to iterate over all your
 repositories, and then filter out those files from the set of files
 you are interested in looking at.

Valid point, that. Though my fix to the ~/.gitignore issue will address that.


 Well, I'm obviously more prone to mistakes than you ;-) But that
 aside, I want this setup to support checkout of a large number of
 third party software packages which I'm either trying out, using, or
 even collaborating with development.  In that case, there are a large
 number of unfamiliar looking files installed in my home directory, so
 it's not always immediately obvious where files have come from.

Those will not be symlinks, though. So all you get is is this in any
repo, not what program does that belong to.
Personally, I like to run temp stuff under a temp user, simply linking
the .Xauthority between the two. That avoids hacks like kdesu.


 To clarify, I'm thinking of using dvcs-autosync in parallel with mr,
 not instead of it.

Then I can't comment as I don't know what it does.


 I don't know vcsh well enough to know which tool you are referring to
 or what it would hide.  But I can't see how an approach which (in my
 very limited understanding) is based on altering environment variables
 would work without requiring a restart of my editor.  If you're a vim
 user who starts up your editor every time you edit a new file, that
 will work fine for you.  But it doesn't gel with my personal workflow.

:!vcsh run vim git commit -a


 Not if there's a bullet-proof barrier in between your gun and your
 foot :-)  Which is exactly my point - I'm saying that if you had the
 same (relative) file path in two different stow packages, stow will
 refuse to install one over the top of the other; instead it will tell
 you that you're trying to do something stupid.

It might deflect into your groin ;)
vcsh will fetch the files from the remote repo, run ls-files to see if
there are any conflicts and only if there are not will it merge.
If there is a conflict it will error out and tell you to fix it by hand.


 I meant disadvantages to using symlinks in general.  It doesn't really
 matter what method you use for managing symlinks, the end result is
 pretty much the same (modulo tree folding).

Well, if you symlink a directory and enter that directory, you will
get strange effects. Sane shells like zsh will try to prevent
surprises, but session restoration after logging in again (think
konsole, etc) will make you end up in the real directory, not the
symlink. Icky.


  - An accidental rm ~/.zshrc seems much more likely than an
    accidental

Agreed, but in that case, both models can restore in the blink of an
eye. I was disregarding that as it's easy to fix. Losing your repo is
not (for you). And no, it's not likely, but you asked for possible
downsides :)


    And in
    the former case, if you are using symlinks, all you lose is a
    symlink, whereas with detached git working directories, you lose
    the whole file which may contain changes not yet in the git index
    or repo.

Agreed.



Richard
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home