9

Pretty self-explanatory; I'm thinking of @AndrewStacey's answer, in particular the part about working with collaborators who do not use VCS. I'm hoping for a more detailed explanation / step-by-step workflow for how, e.g., to use GIT (or SVN) to make it "seem" to me that a potential collaborator who is not tech-savvy (or TeX-savvy!) is using VCS without the collaborator having to be aware of it.

The collaborator and I will share files over Dropbox, but I'm planning on treating a local non-shared, version-controlled folder as the "real" project and just using the Dropbox for fast exchange with the collaborator. Any words of advice / approaches to doing this would be much appreciated.

Community
  • 1
Philip
  • 743
  • 5
  • 13
  • 9
    Step 1: encourage collaborator to use git. 2: ??? 3: profit. – Seamus Feb 09 '12 at 13:32
  • @Seamus Lol. It was a big step for hypothetical collaborator to pick up Dropbox...frankly, his time is worth more than mine and the learning curve for VCS doesn't seem to fit into his value proposition. – Philip Feb 09 '12 at 13:46
  • 5
    Mount the dropbox directory (or somehow link to it - have to check how git reacts to symlinks) inside the git branch and then commit it whenever you notice that something's been updated. By keeping the dropbox well inside the repository, git doesn't place any extra files in it to confuse your collaborator. – Andrew Stacey Feb 09 '12 at 13:52

1 Answers1

7

Create a small script which watches changes in the dropbox directory, copies the file back to your git repository and makes a commit. (do provide a way to handle merge conflicts)

And use a git hook to copy the file back to dropbox when you push to the git remote repository?

Symlinking won't work btw, since git then only stores the symlink and not the actual contents of the file.

Davy Landman
  • 1,345
  • Thanks for this advice; is there an advantage to this solution over @AndrewStacey's of just putting the whole folder inside the repo? I don't have any problem with doing that but I'm curious why one would do one or the other, in particular since writing the script is extra work. I also don't mind manually dragging my own updated files into the Dropbox; in fact I'd rather do that than have it happen automatically b/c I don't need my collaborator burdened with my every minor change. – Philip Feb 11 '12 at 01:57
  • 1
    Well, @Andrew's way won't work since git doesn't version track the contents of a symlink, but just the fact that it is a symlink. And yes, you could just write a script you invoke to sync dropbox and your git repo. Just thought to mention that you could automate some stuff in git using the hooks :) – Davy Landman Feb 11 '12 at 09:23
  • 1
    What about hard links, or mount points? With Ubuntu One (not sure about Dropbox) you can simply add a folder to its list of folders to be synced so you could just add a folder inside the repository. The way I would handle conflicts is to have a separate branch for the collaborator and ensure (via script or via linking) that this branch is always an exact copy of the Dropbox folder. That way, there's no conflicts when importing from the collaborator, only when merging the collaborator's branch with your own. – Andrew Stacey Feb 13 '12 at 09:39
  • 1
    This seems to require more programming than it might be worth. If you're using Dropbox, why not just clone a copy of the main repository for the collaborator, tell them to work there, and then just do the VCS stuff for them on your computer? – Louis Feb 13 '12 at 10:52
  • 1
    @AndrewStacey I've no idea about hardlinks or mount points. But (also for @Louis) there is also the posibility of hosting your repo in dropbox: https://github.com/karalabe/gitbox although I'm not sure how fragile this becomes when also using it as non git repo. – Davy Landman Feb 13 '12 at 13:20
  • 1
    The danger of putting the repository inside the Dropbox would be that the collaborator might accidentally delete some essential files. However, if they can be relied upon to "leave well alone", then that might not be a consideration. – Andrew Stacey Feb 13 '12 at 13:22
  • All very interesting, and hopefully of use to anyone else who stumbles upon this question, but I think my needs are simpler. I'm considering this workflow: when I finish working on a section I want to share, I can commit, overwrite my work with my collaborator's, update to head, handle the conflicts, and re-commit. Then, I can overwrite the files in dropbox with my own. There's a risk of conflict if he's editing the files in db when I overwrite them, but it seems pretty minor. This seems to strike a good balance between keeping things in VCS and giving me control over what to share, thoughts? – Philip Feb 16 '12 at 04:27