Josef “Jeff” Sipek

This is a part 2 of my adventures of making version systems go boom.

As I described before, I need to version some reasonably large files. After trying Mercurial and Git, I decided to go with git as it presented me with less problems.

To make matters worse than before, I now need to version 3 files which are about 2.7GB in size each. I tried to git-add the directory, but I got this wonderful message:

$ git-add dir/

The following paths are ignored by one of your .gitignore files:

dir/ (directory)

Use -f if you really want to add them.

$ git-add -f dir/

fatal: dir/: can only add regular files or symbolic links

Wha?

1. I don't have any .gitignore files in this repository


2. Adding a directory like that worked (and still works!) on other directories

Really painful. Time to experiment, but first I run git-status to see what other files I have not committed yet, and I see everything listed except the directory!...So, I moved one of the files to the top directory of the repo, ran git-status - the file did not show up - but tried to add it anyway:

$ git-add file

fatal: pathspec 'file' did not match any files

Ok, this time around, I at least get an error message which I've seen before. It is still wrong, but oh well. Thankfully, the program that uses these files has be made in such a way that it can handle filesystems which don't support files larger than 2GB. I regenerate the file, now I have 2 files, the first one 2GB and the other 667MB. git-status displays both - great! git-add on the smaller file works flawlessly, but...you guessed it! Adding the larger file dies? Which error message?

fatal: Out of memory, malloc failed

Yep, great. My laptop's 1GB of RAM just isn't good enough, eh? I'm not quite sure what I'll do, I'll probably scp everything over to a box with 2+GB RAM, and commit things there. This really sucks :-/

Update: I asked around on IRC (#git) where I got a few pointers and the code confirms things...it would seem that git-hash-object tries to mmap the entire file. This explains the out of memory error. The other problem is the fact that the file size is stored in an unsigned long variable, which is 32-bits on my laptop. Oh well, so much for files over 4GB. I think, but I'm not sure - I'm too lazy to check - the stat structure may return a signed int which would limit things to 2GB - which is what I see.

So, time has come, once again, to talk of many things...of Git and Mercurial. :)

For a fun project which I'll describe here some other time, I want to version about 2GB of files. Here's the breakdown:

• 5x 312MB


• 3x 100MB


• 2x 16MB


• 80 other files all under 5MB each

My first instinct was to use Mercurial, and so I did. It made sense, because it stores compressed deltas for the files. I don't expect more than ~20MB to change between two consecutive versions, so it made sense on an architectural level as well.

The setup

There are a number of computers involved, unless I say otherwise, I'm talking about my laptop.

• laptop: 3.06GHz P4, 1GB RAM


• server: Athlon 2000, 1.25GB RAM


• kernel devel box: 2x 2.8GHz Xeon, 2GB RAM, 4GB swap


• big box: 4x 1.8GHz Opteron, 64GB RAM

Unfortunately, I can't use the "big box" much. :( Oh well.

Attempt #1: Mercurial

First, I set up the directory hierarchy with all the files. Virtually all of the data in the 100MB & 312MB files consists of binary zeros, so it came as no surprise that the initial commit created approximatelly 50MB worth of history. Not bad at all! I ran some commands that changed the files the way I wanted, and commited each time I felt it was a good place to checkpoint. Mercurial's compressed delta way of storing history really worked well, only 4MB increase in history between the initial and the 6th commit.

At this point, I decided that I should make a clone on another computer - yeah, I use distributed version control systems for backups of individual projects. :) Now, this is where things went crazy. I initiated clone on my server, and after about two minutes, the hg process on my laptop died with a memory allocation error. That sucks. It was probably because of the protocol, which tries to uncompress everything, and recompress it to save bandwidth. Since I was on a LAN, I tried to use the --uncompressed option, which doesn't try to be smart, and just wastes bandwidth, but I forgot that I need to enable it on the server side, and so unknown to me, it still tried to compress the data. It died with a memory error, just as before. Oh well. At this point, I decided to try Git for this project.

Attempt #2: Git

Git uses a different storage scheme, well it actually has two. Whenever you commit, git stores the full file versions - compressed. I did a quick conversion of the hg repo to git - by hand as there were only 6 commits. I had to use:

hg update -C <rev>

otherwise, hg was trying to be too smart - something that makes you run out of memory. :)

After the conversion, the resulting .git repo was also about 50MB in size. Everything worked just as well. It is possible that the commits took little bit less time, as commiting consists of just compressing the files, and storing them on disk. I am not sure which one was faster, and knowing how each works doesn't help with psychological effects :)

Anyway, it was time for me to clone the repository - again, going from my laptop to the server. I was afraid of this step, because when git transfers data between repositories, it tries to conserve bandwidth by making a packfile - a file containing a number of deltified objects (such as the compressed files stored during commit). It started to create the packfile, but it died with a nice message saying that it ran out of memory. Great! Now what? At that point, I decided to cheat. Since I need a packfile sooner or later, I just rsync'd the whole git repo to the kernel test box I have - a box that has twice the ram, and 4GB of swap, and I tried to clone from that. It got to about 66% done, when it was using most of the ram, and far too much swap. After about an hour and twenty minutes, I decided to rsync the repo to the box that has 64GB ram. On it, I ran the commands necessary to just create a pack file - without pulling/pushing/cloning. In about 10 minutes, it was done. Great! I then aborted the clone that was running for hour and a half, and cloned from the repo that had the packfile all set up. Everything worked rather nicely :) I moved things back onto my laptop.

Additional commits

Now it was time to resume what I was doing before - "the project"...I made some additional changes to the files, and made another commit. And it was time to push the changes. Git wasn't happy. I wasn't going to fight as I was getting tired, so I just rsync'd the ~6 newly created objects to the server.

Recently, there have been some patches on the git mailing list to make git little smarter about the way it uses multiple pack files. This doesn't apply to me - at least not yet.

Conclusions

So, here it is. Both of the version control systems I like to use (each one has it's area where I wouldn't want to switch to the other), die on me because my 3 year old laptop has only 1GB of RAM. Just great. :-/ And please, don't tell me about Subversion, and other non-distributed vcs tools. As far as I know, the other distributed systems consume even more resources.

Quite a bit has changed in Guilt over the past two months. There have been 5 releases, as well as one release candidate (v0.19-rc1). During these releases, 71 files were changed (2210 insertions, 293 deletions) in 98 commits. There has been a number of patches I got via email:

Brandon Philips: 4

Nur Hussein: 3

Theodore Ts'o: 2

Yasushi SHOJI: 7

Brandon Philips contributed a significant portion of the documentation - currently every command has a man page! Additionally, he is trying to get Guilt picked up by Debian. So if you happen to qualify as a sponsor, do the right thing ;)

Nur Hussein contributed an uninstall script as well as fixed the patchbomb script.

As far as I know, Ted Ts'o is using Guilt to maintain his ext4 tree.

Yasushi contributed created a few patches which add several bits of quilt functionality (e.g., guilt-files, and guilt-series -v).

I have also been contacted by Peter Williams, the maintainer of gquilt (a GUI wrapper for quilt and mq, with a very similar name to guilt), if I would like to have guilt added as a backend. I checked out gquilt, and it looks really nice. I also looked at what it would take to add the backend, and it doesn't look like that much effort, but I need to implement few bits of functionality first. If anyone wants to volunteer, let me or Peter know. :)

It is really interesting how sometimes a bit of luck makes things happen. For example, little over 6 months ago, I wrote a few shell scripts, which called gq, to make my life a little easier. I worked on the for about a week, and then I decided I should share with the community. So I tagged the sources as version 0.10, and announced it on the git mailing list. One of the comments I got was about the fact that there is another project (completely unrelated) that had the name gq for a long time. Oh well, it was time for me to rename it. After some procrastination and hacking, new year rolled around, and I decided to release 6th version (v0.15), but this time it wouldn't be gq anymore - instead I would call it Guilt. My post from January describes how it got the name. As with every version of gq, I announced Guilt v0.15. I could see that Guilt was getting way better, and so I felt even more motivated to hack on it. v0.16 came out. And then a very unexpected thing happened. I got two patches from a guy on the mailing list. Sweet! I applied them, and release v0.17. Shortly thereafter, during the Linux Storage and Filesystem (LSF) workshop in San Jose, I got a patch from Ted Ts'o (of the ext[234] fame). I couldn't believe it, but it was true. I decided to release v0.19 the next day. At LSF, I met Brandon Philips, and we talked about Guilt. Rather shortly after LSF, he send me an email saying that he'll try to get Guilt into Debian. :) Well, about a month ago, he succeeded.

As many of you may already know, I stick around a number of channels on OFTC's IRC network, and it is rather interesting to see people try Guilt, or people talk about Guilt; generally suggesting that someone use it - and people do!

Anyway, I hope I didn't bore everyone to death with my little tour of history behind Guilt.

Here's another update on my version control system escapades (a follow up to Do I have...).

As several people mentioned during the 0.10 release of gq, the name is already in use by a rather well established project. So, after some idleing and hacking, I decided that it was time to give the scripts a new name, and announce the new version on the git and linux-kernel mailing lists (the announcement). I can't take credit for the rather clever name, I asked a few people, and the best suggestion was by Dave - Git Quilt or Guilt for short.

One thing I did not expect was the fact that someone would contribute 2 patches very shortly after I announced it. Here's the list of changes that made between v0.16 and v0.17:

Horst H. von Brand (2):

      Fix up Makefiles

      Run regression on the current version


Josef 'Jeff' Sipek (24):

      A minimalistic makefile

      Contributing doc file

      Added guilt-add

      Added guilt-status

      Expanded the HOWTO

      Added usage strings to all commands

      All arguments to guilt-add are filenames

      More thorough argument checking & display usage string on failure

      Changed status file format to include the hash of the commit

      Fixed guilt-refresh doing an unnecessary and somewhat wrong pop&push

      Fixed up guilt-{delete,pop} not matching the patch name properly

      Fixed guilt-{delete,pop} regexps some more

      Force UTC as timezone for regression tests

      Fixed a bug in guilt-pop introduced by the status file format switch

      Error messages should go to stderr

      Merge branch 'usage'

      Merge branch 'status-file'

      Yet another TODO update

      Added guilt-rm

      Makefile update & cleanup

      pop: Display the name of the patch from the status file, not the series file

      new: Create dir structure for the patch if necessary

      Documentation/TODO: Mark guilt-rm as done

      Guilt v0.17

I haven't had much time to work on Guilt since then, but I got an rather encouriging email from someone, who tried to apply Andrew Morton's -mm patch series on top of the kernel tree, but failed. The problem is with the way git-apply works. If it applies a patch with an offset, it still returns non-zero status. This makes guilt think that at least one of the hunks in the patch did not apply at all. As far as I know, there is no way to get the necessary information out of git-apply without either modifying it (which I might as well), or parsing the output for signs of rejection and ignoring the return status completely. I don't like the latter, but changing git-apply would limit the number of compatible git versions. :-/

Needless to say, patches are welcomed :)

So, for whatever reason, I seem to be working on version control systems far too much. I have a decent amount of code in Mercurial, I wrote a bunch of wrappers for CVS, I call them CDS which stands for Completely Dumb System which is an apt description of CVS. And now I am working on gq (git repo: git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/gq.git) which is a porcelain (set of wrapper scripts for git) that gives a Mercurial Queues-like functionality to git users.

Yep, I think it is official, I have a thing for version control systems. Ever since I became very interested in them (~April 2005), I learned a lot about them, and I am kind of tempted to give it a go and try something of my own. :)

So yesterday, Matt Mackall released Mercurial version 0.9.2 which includes the churn extension..my own creation! Mwhahaha! :)