[rfc] Windows symlink support

[Jari Aalto]

Jamie Wilkinson <jaq at spacepants.org> writes:

> Both these use cases are more easily solved using management agents like
> puppet or cfengine; pushing symlinks out from your RCS is a terrible way to
> handle this.  Usually one requires a tool run after the RCS push to modify
> the final layout.  In such a case I've found it best to let this tool do the
> linking itself, and leave the symlinks out of revision control.
>
>>Some people version $HOME, which I have started playing around with.
>>Mostly because I have 10 different machines I work on, at various sites
>>(home, work, laptop, school, etc), where doing an NFS mounted home
>>directory is not possible (kind of hard to do on an airplane), but it
>>also sucks to try and keep my ~/.vimrc .vim/* in sync.

CNERALIZED MANAGEMENT

    People, CVS has been there for ages to keep separate hosts and 10
    different user identities (root, cvsadm, wwwadm, $USER) well on synch
    :-) It has been ideal for star-like system, where all hosts share the
    same configuration (even if they are on different OS, you can still
    separate "common" from site-specific).

               Host 3   Host 4
                     \ /
             Host 2 - o - Host 5
                     / \
               Host 1   Host ...

    Make change, check in, move to another site and just do

         cvs up

    With appropriate ssh setup, this can be automated:

         ssh login at example.com "cd that-dir; cvs up"

HOME DIRECTORY MANAGEMENT

    Personally I have found this to be best working for HOME directories
    with different identities (root, cvsadm, $USER ...), hosts and
    Operating Systems (HP-UX, SunOs, Linux, Cygwin):

         $HOME/vc           Keep all version control files under this
                            * Can be excluded from backup. 
                            * Files that you want to preserve. 

     You can selectively check out the pieces that you need
     under this directory from master repository.

 Example: dot-files

    Every directory contains a "Makefile" or makefile.sh that will
    populate the needed directory(ies). For examples for VI/Emacs,
    symlinks must be drawn to DOT-files from site specific VC
    directory to $HOME

    1) common settings for all hosts

         cd $HOME/vc/my/shell/rc/common
         makefile.sh
         
    2) Overwrite with site specific needs (and possibly more files)

         cd $HOME/vc/my/shell/rc/$(hostname)
         makefile.sh

    Now there will appear ~/.vimrc, ~/.emacsrc, ~/.muttrc ...

  Example: shell startup

    1) common settings for all hosts

         cd $HOME/vc/my/shell/bash/rc/common
         makefile.sh

    2) Overwrite with site specific needs (and possibly more files)

         cd $HOME/vc/my/shell/bash/rc/$(hostname)
         makefile.sh

    Now there appears ~/.bashrc, ~/.bashrc_logout ... and some
    libraries that are put under $HOME/var/link/bash and "sourced" by
    the host-specific bash settings. They provide aliases, functions,
    etc.

  Example: programs

     I use toplevel $HOME/var for "permanent" files so that it
     is easy enought to make a backup for everything.

         $HOME/var/bin

     Same as previously drill, but the files are symlinked to one
     common directory

         cd $HOME/vc/my/shell/bin/common
         makefile.sh
         cd $HOME/vc/my/shell/bin/admin
         makefile.sh         
         cd $HOME/vc/my/shell/bin/$(hostname)
         makefile.sh

     Sympliks are in place, so PATH setting only contains in
     ~/.bashrc:

         export PATH=$HOME/var/bin:$PATH

Now, when bzr gets central repository concept, this will all be even
more fun.

Jari