I’ve asked google, and I’m not sure I can do what I want to do, but maybe one of you knows how.

At work, we use subversion (ick) as our VCS.  I, of course, use git-svn.  However, this means that I have to have a multiple git-svn repos if I want to have multiple outstanding change-sets (uncommitted to local git) at a time.  I know, I’m supposed to commit early and often and rebase (and I do) but sometimes it’s horribly inconvenient to have to stop what I’m doing, commit, check out a new branch, make a small change, commit, and switch back.  In addition, I sometimes need stable checkouts for testing (some bugs can take days to reproduce, and rebuilding breaks debugging).   However, keeping track of all these git-svn repos is a pain, and getting new ones is very time-consuming, involving either a new ‘git svn clone’ or a copy of an existing repo.

What I’d like is a git to svn bridge.  That is, a bare git-svn repo with appropriate hooks that I can clone (using git), work from, pull from (the pull hook would git svn fetch), and push to (the push hook would git svn dcommit).  As nearly as I can tell, I can’t do this, because git-svn seems to need a checkout for some things (git svn rebase, for example; git svn fetch didn’t seem to pull the changes into the repo’s history), but cloning and pushing in git seems to need a bare repo.

So, oh lazy web, is it possible to do what I want?

A bug in your code that is in a superposition of triggering and not triggering.  Examining the state of said bug (via code inspection, accidental triggering, whatever) causes it to collapse into one of the two states permanently.  All future tests exercising the bug will hit either pass or fail, depending on the collapsed state.

Note: It may seem that all quantum bugs collapse to triggering, since they are only noticeable if they trigger.  In fact, the wave function for the code determines the probability of collapsing to triggering or not.

See also: heisenbug.

How long for a port to the Nokia Internet Tablet family (preferably the 770)?  Anyone? 

Computers are getting faster, and more capable.  In particular, the amount of RAM available to computers has increased in leaps and bounds.  My first computer (and IBM PCjr) had 64K of RAM, and that was part of an expensive upgrade from the default.  The laptop I’m typing this on has 2G of RAM, and the workstations sitting next to it have 4G and 6G respectively.  That’s a huge increase, over the past 25 years.

However, in my daily use of my laptop, 2G doesn’t seem to be enough.  After a few days of uptime, my free RAM (defined on Linux as the amount used by disk cache, rather than the amount actually free, since RAM is basically never actually free) drops below 100M.  This is not an acceptible amount of disk cache, and it causes my machine to slow way down, and even to go into swap storms sometimes.  If I then go and emerge something written in C++, I trigger the OOM killer.  On a 2G box.  How does this happen?

One posited (and believeable) reason is the Developer-User machine divide.  The reasoning goes thus:

Software development is a resource intensive operation.  Compilers, debuggers, emulators, and so on, take lots of CPU and RAM to run fast.  Developers are rather high paid individuals.  Thus, most companies maximize ROI by getting developers large, fast development machines, so they don’t spend all their time waiting for tools to execute.  Similarly, FOSS developers tend to spring for decent development boxes if they possibly can, because software development quickely becomes painful on low end boxes.  Naturally, if a developer has a large, fast development box, they’re going to use it whenever they can, for normal, day-to-day tasks.

Typical users, on the other hand, have (by definition) average machines.  They tend to be middle-to-low end, with much less CPU, RAM, and disk than a typical developer machine.   (Unless it’s a gaming rig, of course, which ends up way in the top end for similar reasons to developers having good boxes).  This means that the box a developer typically uses for day-to-day activities (mail, browsing, chatting, office, and so on) tends to be faster and have more RAM than the box a typical end user has.   This is the Developer-User machine divide.

I’ve read a number of posited solutions to this.  The most common is that developers should use “typical” boxes for day-to-day activities, rather than their development machines.  This is not going to happen.  First off, if you have a choice of 2 computers, one of which is much faster, you’re going to use the fast one, right?  Second, especially for FOSS, developers typically don’t have the funds  to have multiple machines like this.  Any extra machines I have, for example, are typically either old dev machines that are below even the average curve and run my network, or specialized machines (say my elisa box) which cannot be used day-to-day.   I’m going to use my laptop (which, granted, is not a beefy as my workstations at work, but is still, even 1.5 years later, beefier than anything any of my relatives have).

So, my reasoning went like this:  We need a little daemon that lurks in the background, sucking up RAM and keeping your CPU at it’s lowest frequency, until it detects software development in progress.  Then, it should free up RAM (temoprarily, of course) and jack up the CPU frequency, so that development happens fast.  When development is done, it lowers the CPU again, and sucks RAM back up.  This, of course, is problematic, difficult, and easily open to abuse (say a tight-loop script of gcc niced).

Then it hit me: a VM is the perfect solution.  It’s slower by it’s very nature, and it can have strictly limited RAM.  Developers should run their day-to-day programs in a VM!  Then, they can allocate, say 512M of RAM to the VM, and leave the rest outside for normal development activities.  Granted, this leaves it open for cheating, but at least developers would start to feel the pain of normal users, start to bridge the machine divide.

Will this happen?  Probably not, at least not on a large scale.  Many developers, of course, already develop in a virtual machine of some variety, for other reasons (need Windows on Linux or vice versa, for example).  But in general, the first reason why developers don’t already use slow machines applies, and many developers (myself included) don’t have the time to track down complex time/space trade offs in complex software (I’m looking at you, Evolution!) to make their VM’d selves happy.

Will I do it? Again, probably not.  This is because my primary development is Gentoo maintenance.  This means that I can’t isolate my development to outside my VM, since I’d need to keep the VM itself up-to-date with ~arch software.  I’ll think about solutions, but there may not be a good one (maybe distcc to the host box?).  Additionally, the majority of my development work for FOSS is packaging software for Gentoo, which means I don’t usually do much actual development on that software, and what I generally do is bug fixing, not in-depth development.  Then again, maybe I will do it, just to force myself to dig into these issues.  It certainly could be a useful experiment.

Now, the question is: how do I get my VM to gracefully recover when my video doesn’t resume? 

Question for the Lazy-Web:

Has this been done?  Are there tools for syncing, switching, backing up, and so on?  Does, for example, VMware do this internally?