Hacker News Reader

Comment by raganwald | Hacker News Reader

  One fateful day, VMWare and OS/X conspired to trash my
  shared filesystem, losing several days of uncommitted
  code in the process.

Several days of uncommitted code? We need to have a heart to heart talk about your process.

View on HN

This is really true. Back then we were still using CVS, and I was writing a feature that I thought wasn't quite big enough to branch and remerge for, but turned out to be a bit more involved to get right than I'd thought.

Now we're on Mercurial and life is better.

Edit: A nice win with the Linode is that they back it up for me for $5 a month. Sure, there are solutions for the desktop too, but somehow I never got around to using one of those.

There are two kinds of programmers: Those who’ve earned their experience the hard way, and insufferable know-it-alls who parrot whatever was in the last witty blog post they read.

There’s zero shame in being the first kind :-)

And one shame in being the other : P

What's the URL to the blog post where you read this? :)

http://twitter.com/#!/raganwald/status/131738600931995648

:-P

i think i'm in a wormhole!

Recursion abuse!

I would observe that with DVCS, if your hard drive crashes you can still lose several days of unpushed code, too. I recommend and use cron jobs to push and/or rysnc things around on a more frequent basis for my really important stuff.

You could buy a second hard drive and put it behind your other drive and occasionally copy important files from your front drive up to your back drive.

Or use TimeMachine if you are on a Mac.

No, if TimeMachine screws up a file it stays screwed up for ever after every backup, there's no integrity checking. It also completly barfs on large files that change little by little. The best example of that is the entourage mail store, but any single file db will do. I've seen clients bit bad by these problems. Don't get me started on the time capsule...

What should we use instead?

Linus's solution is to write software that people run and use daily.

Point your Time Machine backups at a NAS that's using ZFS with block-level deduplication.

Option-click on the Time Machine menu to verify backups. Sleep well.

Works great until your computer/home/office catches fire.

Personally I have a mirrored drive set that I use as my primary storage, and a third disk that I rsync to nightly and use for backups of other stuff, because I don't trust that I won't have filesystem errors or controller problems that might render both disks in the mirror unusable. Then on top of that I use Crashplan to ensure I have an offsite copy.

For most of my code I also push to github or private external repositories regularly and/or pull to my laptop.

Maybe a bit paranoid, but I've had to recover from enough scary hardware and software failures over the years to not want to take risks.

Dropbox fixes this.

Raid and rsync are your friends. Use them.

What's wrong with a remote branch you push to and then merge back into master afterwards?

Was my second sentence really that incomprehensible?

This is why I keep my working copies in Dropbox

second that... my working folders are dropbox... and commit to cloud git repository as needed.

Same here. I had some sort of electrical problem with my last computer and lost my hard drive due to it. Unfortunately, my back-up drive was also plugged in at the time and it got fried, as well (really bad luck/timing there).

One of the first thing I did when I got the new computer was to put a symlink to my projects directory in my Dropbox folder, so that all of my projects now get backed up to Dropbox automatically.

We keep our main repository in under dev/$PROJECT and backup repositories under user/$USERNAME/$PROJECT. Then we set a post-commit hook to push to the backup server on commit. Setting up the backup and creating the hook is done by a shell script you run after cloning.

I'm always doing

  git push origin develop

for this reason, but some environments probably don't allow you to do this easily? I work alone. (EDIT: be nice to people)

We typically work in personal feature branches before merging into develop; if you use a similar workflow there shouldn't be much issue at all from pushing constantly.

Can you protect from other folks pulling it? Sometimes people just don't want to reveal their code while is ugly...

Gitolite[1] will let you mark branches as private on the remote either by specific branch name or a regex (ex: any branch that starts with "swah-" is private to you) if you want privacy before revealing your code.

[1] http://sitaramc.github.com/gitolite/

It's more difficult to setup, but it's wonderful to have a dedicated development cluster. Put everyone's home directory on a dedicated file server, which uses NSF to be global to the cluster. Then you can do automated backups on the file server - hourly, nightly, monthly, whatever. There are file server appliances which are configured for this sort of thing.

When you do this, much less important data is stored locally, on developer's actual machines.

Thanks for sharing. Did you consider switching to a smaller laptop like a Macbook Air / Netbook?

No, I wanted to try something radical and crazy and new. Frankly, I expected to be back on my MacBook by now. This has been as much a surprise to me as anyone!

I tried out an iPad app called Koder, it was nice but still lacked some things.

Your post has got me wondering about Vim again.. :) Making the switch to Sublime Text has got me appreciating a more shell-like interface for some things.

Have you ever found yourself wanting to code and not have an internet connection? I think that's a pretty rare scenario, I'm rarely offline.

I haven't wanted to code offline for months. Maybe if I flew for more than two hours I'd miss it. Even the trains have wifi in Germany.

The few times I have wanted to code offline, I've also wanted to look something up >.<

Haha, that's really true. I rarely code offline, maybe it's just another umbilical cord that we should be examining.

Between having tethering and generally ubiquitous tethering, we should be good.

I think I want to try getting into VIM again. Is there a good resource site you like, where I can find a decent guide and some pointers on where to find some language dictionaries? Totally off topic but I'd appreciate it.

I recommend just running "vimtutor" in terminal once you've installed Vim. It's the best introduction. Far better than the online tutorials that sometimes pop up on HN.

Once I got the basics down (15 minutes in vimtutor), I noticed enough productivity gains to use it immediately for note taking and scripting. Then I just decided to jump in and use it for a real project. I learn new hotkeys, plugins, and config tricks every week and I just feel my productivity inch its way up and up.

Vim on my 11" Air is excellent. SSD is nice and fast, and I wonder if the total weight is less than the ipad+bluetooth keyboard.

Nope, Ipad: 601 g (613 g for 3G), 11" Macbook Air: 1080 g, I was unable to find the keyboard's weight but it can't be 400 g.

According to Amazon the keyboard weight is 522g.

http://www.amazon.co.uk/Apple-MB167B-A-Wireless-Keyboard/dp/...

Making the Macbook Air 11" the lighter option.

That is the boxed weight for shipping.

I have the wireless keyboard (the older three-AA revision) and it's comparatively lighter than my 7" Tab, which is 380 g.

edit: Charlie Stross says 325 g for a four-AA revision in http://www.antipope.org/charlie/blog-static/2010/05/ipad-wri.... Macworld says 323 g in http://www.macworld.com/article/150600/2010/04/ipadwhichkeyb...

My Apple wireless keyboard (model A1314) has 2 AAs, have there really been that many revisions?

I don't personally recall the four-AA revision. Wikipedia links to Apple's press release http://www.apple.com/pr/library/2003/09/16Apple-Introduces-W... which confirms four AAs.

My keyboard, bought in November 2008, part number MB167LL/A, definitely takes three.

Current revision available on Apple's website is MC184LL/B and that one is well known to only require two.

Insightful, and so close to a haiku as well...

Here's an attempt:

  Mac lost my data
  Many days of work gone
  Cloud to the rescue

Mac lost my data

Many day of work gone

Learn to commit more

Can I get this on a t-shirt?

  It's the poor craftsman
  Who points the blame at his tools
  Y U NO COMMIT?

winner

So this is why Even if you are u63r 733t Time Machine still rocks

  There once was some data I lost:
  Days worth of work just got tossed!
  So I decided to write code
  On an iPad plus Linode
  Getting backups for minimal cost.

yours is not quite a haiku either.

    you say its haiku
    but you missed a syllable
    in your second line

Meta-haiku?

  crafting great software
  takes many small commitments
  like playing Jenga

The cloud went down

Cannot get to my work

Twiddling thumbs feeling dumb

Variation:

The cloud went down

Cannot get to my work

Throwing birds at pigs

If I may offer David Dixon's classic?

       Three things are certain:
       Death, taxes, and lost data.
       Guess which has occurred.

Welcome to the hacker news sub-reddit.

This.

It was a joke. I can't delete it now.

So, this is something i worry about.

I'm using time machine for backups, so i don't think i'll lose much ... but i'm sorta hazy about how i should be using svn for all these little incremental steps. I'm uncomfortable with committing code that's going to break the whole system.

Should i be creating a branch for projects longer than an afternoon, and just committing that fairly often? I feel like eclipse's history is working okay but i have a vague paranoia i'm doing something dumb when i see comments like this.

With SVN, probably, but the branching just feels heavyweight so sometimes it's hard to motivate. Git with the "git flow" addon seems like it'd be a better fit for you. Being able to checkin in "to your feature", as opposed to waiting till it's done and ready, feels great.

It's also not just about avoiding data loss. If your feature starts going off-course or has a bug, you can look at previous revisions to get fixed up.

The major workflow shift that involves the skies parting and mana floating down from heaven when you switch to a DVCS (git, hg) is the ease and lightweight nature of branching.

Having used git for four years, I now feel absolutely filthy if I'm not coding on a branch. If I start coding anything, I make a branch first, because the overhead is nearly zero, if I screw something up I can easily revert, and the downside of being scared to push code is too great.

Example: Yesterday I started a new feature. Step 1 was to branch from our develop branch. A bit into the coding I realized that this feature was going to take longer than expected. I committed what I had on my branch and pushed it to the remote repository (github in this case). This affects no one else, because the code is on a branch.

What really makes this possible is that merging is so easy. Branching and merging in svn was scary. I was never sure if something horrible was about to happen. With git (and hg) branching and merging is the expected behavior, and it's easy.

Always being on a branch also makes it easier to deal with interruptions. "Hey, there's an emergency, can you fix Foo?" No problem, commit what you have on your branch (or use `git stash` which is amazing) and jump back to the branch that has the code you need to fix. Need that fix in your branch as well? You can merge or simply `git cherry-pick` a single commit across branches. You no longer have to worry about the dreaded "Did I already merge this? What if I merge it again, what will happen?"

This. A thousand times this.

I use perforce for my daily work, and all too often I'll get to a stopping point and think to myself that my approach isn't working - usually I'll wrap my stuff up in a changelist and save the diff off to a file. Then I need to revert to latest and start my work from there.

It's not hard, but it's slightly painful, because if I wanted to try different approaches I end up having dpks lying around on my disk which have no easy relation to what they contain.

I've been tempted to install Hg and use it's branching mechanisms on top of perforce, but I'm not so sure my workplace would condone that (plus, Hg + perforce may not play well - I'm not sure).

Um ... you might want to try `p4 help shelve` first. Shelved changelists are basically the same as a "git stash" - but they're stored on the server, so other developers on your team can review a changelist before you actually submit it. One of my favorite Perforce features, actually.

Changelists are a feature I really miss in other source control. It's nice to be able to keep orthogonal changes separate

As others have pointed out: you're using a tool that makes you not want to commit very often. Change to a tool that doesn't have this problem, there are nice ones out there now.

"I'm using time machine for backups, so i don't think i'll lose much"

Time Machine is great, but as others have mentioned that may not help if the building catches on fire. It's good to also have your stuff backed up at a different location, preferably in a different time zone. :-)

Edit: Like others, I use DropBox for stuff that doesn't really warrant a full-blown source control system. It's very easy to just right-click, compress, then copy the zip to the DropBox folder.

There once was a man with a Mac

One day his VMWare went wack

So he picked up his code, went to Linode

Which now handles all of his stack

As I read the article I knew something like this would be the top comment on HN ... :-/

Apparently lots of people make this mistake.

Is it stupid? Maybe. Probably.

Do we need to have a lengthy discussion about it every time it is a minor part of a story or article? I'd rather not.

How about if he is using Git? It is normal to work out of your local repository and only sync with the master occassionally, no? At least on projects that can tolerate such methods.

I push to a personal remote at least twice a day. Not doing so is asking for trouble.

And I agree- I am a veritable slave to keeping my data syncronized- but I recall many people lifted up the local repo idea, and being able to sync twice a week, as the herald of the future.

Well, you can pull from upstream twice a week. And you can keep a master on a computer in the next room.

(I'm also not terribly worried about my Air or my Hackintosh giving up the ghost, so...)

I highly recommend upping this closer to twice an hour.

I said "at least". ;) It's really more like "oh hey, I just committed and it works, might as well push while I'm here." Usually every 3-4 file changes or so.

Probably using SVN or CVS. Everyone I know used those systems that way but moving to a modern RCS usually gets people checking in a lot.

Even back on svn I tended to use svk (not in offline mode, just for workable merging) and branch for everything - keeping to a rule of "it compiles? commit it" and then only caring about everything working when you merge saves data loss and has the advantage of keeping your thought process, even when that process turned out to be wrong.

CVS? I think I've forgotten how I used that, thankfully.

Reply on news.ycombinator.com