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

[Richard Hartmann]

On Fri, Oct 28, 2011 at 18:23, Adam Spiers <vcs-home at 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