One for the nerds....

[tyggerjai]

So I now have 2 or 3 machines I use for tinkering with the little projects I have, and I'd like to keep the code synched. There are many tools for this, of course, and I'm not wanting to start a religious war about which tool I should use, but rather seeking advice on how to use them best :)

Assume, for the sake of argument, that I have access to git and/or subversion. Assume, for the sake of argument, that I have a ~/Code directory, which has, of course, a Python directory and a Perl directory, which then contain project directories and library directories.

Assuming for the moment that I don't care so much about synching "broken" code - in that I want to be able to half-finish something on the desktop, commit it to the repo, and check it out on the laptop to keep tinkering - as much as I care about the latest version, is my best strategy to commit ~/Code en masse and then just update en masse?

Or should I commit each project individually to the repo, so I can branch later if need be?

Comments

[thorfinn]

Separate projects should be kept in separate repositories. Putting multiple projects in the one repository is just asking for confusion. If things are related sufficiently then they're probably the same project.

That said, to solve the synchronisation of *working* space problem, you *could* put the whole thing inside your Dropbox folder. That isn't so good for large projects involving binary builds, but for scripting language projects, it's great. And then you don't have to worry about forgetting to commit code (and you should *also* be using a code repository, but it then fulfils its correct function - keeping a history of your code, as opposed to being misused for a function it's not designed for - keeping directories in sync).

[tyggerjai]

That's true - I have two separate aims, I guess. I want version control on every project so I can have a stable release and a dev branch. I also want the dev branch (at least) to be available across all my machines so I can keep working on it.

[thorfinn]

Yep. :-) Different goals, different solutions.

You want to keep directories in sync across different machines, put them inside Dropbox. There are other solutions, but I guarantee you Dropbox is the simplest, quickest, and least prone to error, by a very very long way. Just the dev directories, if you like, since presumably the stable branches shouldn't contain anything except correct stable versions.

[tyggerjai]

And then I can also configure the netbook to just get the code stuff from dropbox, since it can't handle the full 2 gig. Yeah, that works. Need to explore the advanced dropbox fu a bit more. Do you know if I can go back and tweak it easily after choosing "basic" install option?

[tyggerjai]

Oh look, that would be "select which directories sync to this computer"...

[thorfinn]

I'm not aware of multiple versions of Dropbox installs, but I'm only using it on iOS, Mac OS and Windoze. With the latter two you just pop open the Dropbox Preferences from the Menu/Tray Icon then clicky Advanced to find the Selective Sync option... iOS you have to explicitly favourite individual things if you want them to be downloaded for offline.

[ideological_cuddle]

The other thing to know is that if you symlink something into the Dropbox tree, Dropbox will happily sync it properly. I'm using this feature to keep my music where iTunes wants it, but with a symlink from ~/Music/iTunes/iTunes Media/Music (or whatever) to ~/Dropbox/Music.

Dropbox treats that symlink as though it were a real directory so far as the other client machines go, so anywhere I don't explicitly exclude ~/Dropbox/Music from sync, it'll just pull all the music across as a directory rather than as a symlink.

This may be useful if for some reason you really want stuff in random directories in different places but still want Dropbox to sync it all.

[thorfinn]

Oh, and I have to say, if you really do want to misuse a code repository for keeping directories in sync, I believe git is actually designed around being a distributed code repository rather than centralised, which makes it slightly better.

Still not as good as Dropbox because you have to remember to push/pull/run-script-to-sync, but not everything fits in Dropbox. :-)

[ideological_cuddle]

but not everything fits in Dropbox.

It does if you give them (enough) money. ;)

I mainly use Dropbox for an offsite backup of my music collection, so I've paid for a 100GB account. It works pretty well in that role and I don't have to think about it all once it was set up, it just automatically syncs properly.

[thorfinn]

Well, that is true. :-)

I'm more thinking that if you're compiling a project that involves regularly creating and destroying hundreds of MB of libraries, or working with editing multi-GB media files, Dropbox is not going to help you much... if only because sending all that crap up to .us even once (assuming the other machines are local so they do LAN sync) is going to take forever. De-duplication may or may not help, but I wouldn't like to bet on it helping. :-)

Personally I'm very happy with http://crashplan.com/ as my emergency cloud backup provider and I really hope I never have to do a catastrophic restore (of all machines), but it's there just in case. I did do a full crashplan restore of my linux VM when that died horribly, but that was a mere 13GB. :-)

Dropbox I'm keeping just for "a small amount of stuff I like to sync", so the free GB is fine for me so far. I'd be happy to pony up for a bit more if I needed it though.

[ideological_cuddle]

Yeah, in that instance you'd either do your builds in a different directory (which is something the gcc people like to do, if memory serves) or use selective sync. I think the former is probably a cleaner solution, you're already going to have to make sure that your binary files go into a subdirectory rather than sitting alongside the source anyway...

I like that Dropbox will also sync across the LAN if it can, so it takes care of both the remote backup and the rsync-like cases. At this point anything I care about winds up in TM, on Dropbox, and synced to a second machine via Dropbox-over-LAN. I feel *reasonably* safe.

[tyggerjai]

Ahh, that explains the (LAN) message I sometimes get. That's pretty awesome, given that my usual use case is indeed a desktop downstairs and a laptop upstairs.

[afuna]

In that case, I'd probably do separate repositories, and then toss them all into Dropbox to solve the always syncing issues >_>

I've tried both models, and have found that the one-big-blob approach quickly gets frustrating because you have leftover commits all over the place (even though I started out intending to be okay with broken commits, in practice it didn't work out!). It also makes it difficult to share just one project with a friend at a future date.

With the multiple repos approach, things are nicely separated, and even when there's a broken commit it's easy to pick back up on it the next time you're working on that section of code because you can just look at the log for head/tip/whatever, but there is a chance that you'll forget to sync one at the end of a coding session before you move on to another one. Perhaps you could write a script that goes over and syncs everything just before you logout?