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 than anything else. 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. - This is git, so all my repos are mirrored remotely. So at worst I would only lose stuff I haven't committed yet. _______________________________________________ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home