Upgrade process may be causing issues due to using mv & globbing

[dedward]

The initial install process, the [b]ackup options work fine - mv (renaming) the files to files.backup in the home folder.

On an upgrade, per the Readme........ the rake install tries this again and simply moves the symlinks that it previously installed, then linking the file again. The git merge should take care of this in theory - but it's confusing as a backup procedure, and prone to misunderstanding if you don't realize it's happening.

Doing the backup, via cp instead of mv, to a location outside the .yadr folder, prior to the git pull (and merge resolution, etc) would at least leave some backups in place. Perhaps a rake upgrade task?

[skwp]

I generally upgrade by just doing git pull; git submodule init; git submodule update - yes we can get smarter than that, but is it really necessary? Your thoughts are welcome, and a pull request with a patch is even more welcome! :)

[dedward]

I'll try to throw some patches together (this is a good exercise in getting the ins and outs of git/github/vim/etc all refreshed as well...... thanks, btw.....

I'd say at a minimum, the readme could be updated to reflect what you just said is your normal update process, rather than what it says right now, which leaves room for confusion, especially if people don't understand git branching/merging, etc..

I hesitate to patch the readme because I'm not sure which direction you're heading in - which way do you want it to go - the Rakefile fixed up to do something safer, or something involving branching, or just an update to the readme?

[skwp]

Technically it's better to use the rakefile for upgrades, because there may be tricky things that a git pull won't handle. For example, new files that need to be symlinked somewhere. I welcome any input on this...recently most of the work on this project has been for vim customizations so no new files have really come into play. And the installer was actually written as a contribution from @kylewest so I didn't participate really actively in it, maybe I should review the code. I welcome your thoughts on what exactly is broken with updates, and how you think we should fix it. I'll try to make some time to review this with you. Thanks!

[kylewest]

Hi @dedward help me understand exactly what's happening...

From what I understand, you've installed YADR and are trying to upgrade. You have your old files backed up and chose backup again when upgrading. Doing that overwrites your backed up files with the symlinks that the install created.

Sounds like we could fix this by checking if a symlink has already been created before attempting to recreate it? E.g. (pseudo code):

~/.zshrc is symlinked to ~/.yadr/zsh/.zshrc
if (test for the above)
  skip zsh setup, it's already done
fi

I think that's a good idea and we should get it in there. If you're going to work on it let me know, otherwise I'll try to get this implemented.

Kyle

[dedward]

Hi Kyle - while I'd love to commit to fixing it, I'm afraid I can't commit to it due to time constraints, though I might have something to push at some time - assume I won't be able to (but if I can squeeze in some time, I will)

Your suggestion works - but it might mean you must be installed in ~/.yadr/ (somewhat related to the other issue we're discussing). That's probably okay, given this is opinionated, right? Just say "it must be in .yadr and that's it"

I'd say ideally the setup/upgrade procedure should avoid the symlink, and instead have two things (this goes for all upgraded files linked inside .yadr - but using .zshrc

1. A way to detect whether or not the real ~/.zshrc needs to be upgraded, a comment that can be parsed out or something like that including a release tag or whatever. Or maybe easier, a simple diff between that and what's in .yadr/zsh/zshrc or similar to determine if it's needed (if they're the same, not needed). Symlink check needed too I guess.

2. If it's going to be upgraded per snipmate tab completion may be broken #1 - a clean and obvious backup by copy, with a datestamp. That will remove any symlink that might be present to somewhere else as well. Output included to user during the process to show what/where/why.

The simplest solution at the moment is just to upgrade the readme so newbies don't blindly follow the instructions and blow themselves up :)

[dedward]

Kyle just re-read - the problem isn't creating the symlink, it's the backup option that simply renames (via mv) the .file to .file.backup, still pointing to the same location inside ~/.yadr/

That means your file isn't backed up if it's been changed.

[kylewest]

let's see what @skwp has to say about #58 and go from there.

[skwp]

I think this is no longer an issue. If it is, please reopen with detailed comments.