2GB limit

[Maritza Mendez]

I think I finally got hit by the 2GB VM limit.  Fortunately this is a test
setup, not production.  I've just started testing bzr against our newest
project.  It uses several SQL databases each of which can be about 100MB.
The databases are pretty dynamic so versioning them is highly desirable for
keeping code, data and testcases synchronized.  (And we claim bzr with its
global rev numbers is a better solution than scattered folders.)  Also,
there are lots of CAD models which can easily be a few hundred MB each.
Most test cases include at least one CAD model and sometimes several.  As
test cases are updated, the CAD models are also updated.  So there are lots
of typically small changes to large files (SQL and CAD).   The "big files"
usually have relatively simple straight-line history that could avoid merges
if we just worked with them only on "trunk".  They're almost like versioned
binaries in that way.

I am testing with bzr 2.2.1 and I know it is doing much better than bzr <=
2.0.  Older versions of bzr choked VM on projects much smaller than my
current test case.

Three questions:

1. How soon is bug 109114 [https://bugs.launchpad.net/bzr/+bug/109114]
likely to get attention from Canonical?

and

2. Does anyone know if any other dvcs system has solved the VM problem?  If
so we might put our "big file" projects in git or Mercurial until bzr can
handle them.

and

3. How hard would it be to add a bzr ignore rule that is based on filesize
instead of or combined with filename patterns?  My biggest fear is that
someone (like me) will accidentally try to commit a file which we know bzr
cannot handle and then having to un-do the damage to the repo, hopefully
before any more commits are made.  Being able to block-by-default commits of
files exceeding a configurable size would help protect the integrity of the
repo and help me keep my developers productive.  I realize this is dangerous
(missing content) but not as dangerous as downtime.  As Philip Peitsch
mentioned yesterday (what a coincidence!) explaining downtime to management
is not pleasing.

Thanks
~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20101002/6042618f/attachment.htm