Hi,

After ****ing up my Scratchbox for the umptieth time I dediced to use a snapshotting solution hence currently I'm using snapshotting together with Scratchbox & Maemo SDK. Whenever I start to work I first make a snapshot. This is included in a script before it calls /scratchbox/login and if I screwed up I can rollback to a previous snapshot.

The advantage is that when you ****ed up your SDK you can switch back to a previous image in a wink without requiring to reinstall Scratchbox and SDK. It also does not use much more diskspace because only when files are different the different version is saved; ie. there are no dupes.

The disadvantage is that there is overhead involved. In my case I'm using ZFS-FUSE, which is not fun for I/O, although it does work. I cannot compare performance because I'm using different target storage than I was when using Ext4.

If there is interest I can provide a howto for using ZFS-FUSE together with Scratchbox & Maemo SDK.

Has anyone tried a similar setup (without VM images)? What did or do you use for providing snapshot/rollback support? Perhaps on a different layer than filesystem layer? What is the best solution to get this working well?

I'm curious about in what way your scratchbox setup is getting ***ed up? Is it the scratchbox installation itself? If so, what kind of actions causes this? I haven't had any such issues myself (note I'm on pre-fremantle scratchbox). As for applications or software I'm working on, I'm using GIT to keep track of versions, problems and roll-backs. I access the scratchbox user area from my host login (using the host GIT), I only use the scratchbox login to do the actual builds (and any apt-get commands). This way I can also clone the code I'm working on to somewhere else.

Well, it is not Scratchbox-only problem. On other production systems its usually /etc and /var/log although logrotate with compression mitigates the latter, and manual backing up the former. The other bugger is /home/$USER/.*

The last time I screwed up Scratchbox was when suddenly half my binaries were gone in my targets. They were in ls but when I tried to execute them I got command not found. This was not related to $PATH. OK, I did something macabre (replaced qemu-arm binary), but that shouldn't have this effect and I reverted the change.

It could also be the case my SSD is dying, or because I had kernel panic. Heck, it could even been due to OOM killer. But there is nothing in /lost+found.

Another time I did not use /usr/local and installed dependencies, or the packages from Debian overlapped. Or I changed a Makefile and forgot to back it up first.

No matter what I want some kind of data consistency, and I also like to go back to a general vanilla starting point to evade race conditions where stuff is non-default. VMs do provide snapshots, but also overhead, and I can't run one at the moment on my target machine.

Without using a versioning filesystem do you think GIT can be used, with OK performance, to have good versioning including a whole target? Would gitfs work?

Ideally, one could just execute less filename.txt;2 which reads the last version of the filename before it was modified to its current incarnation.

The only suitable, stable alternative I found thus far seems to be kernel-space filesystem called NILFS. I'll try it and report.

I have no experience with gitfs, so I can't say. Your usage (and hardware) seems to be different enough from mine that I don't think I can come up with any useful advice, unfortunately. NILFS looks interesting though.

Out of curiosity, why not?

-jkq

I think there is interest in such a HOWTO, I'd read it!