Getting started with a content filter

[Stephen J. Turnbull]

Chris Hecker writes:

 > 2.  Can't have entire history in all branches because it gets too big 
 > too fast on clients, need to store most of the large binary history
 > on a server.  Is there a way to specify a partial history like this
 > now?  Are stacked branches something that could help here?  It'd
 > have to be per-file, though, not global to the entire branch.  In
 > other words, I want all the code revisions local (or most of them),
 > but only the past two large binary revisions, or whatever.  The
 > code would need to delete old history locally as new history is
 > checked in (assuming it's been successfully pushed to the server,
 > of course).

Except for the autodelete of old revisions of binaries, the above
should all be straightforwardly scriptable in git, assuming keeping
BLOBs in BLOB-only subdirectories is acceptable.  I know you didn't
want to hear that, but there you go.  You should keep that in the back
of your mind if bzr doesn't get a usable feature soon.  (My bet is
that Anteru's project will pay off, by the way, so it's likely a moot
point.)

The closest you can come in current bzr is the two-branch scheme, one
a regular branch with a local repo containing the code and the other a
lightweight checkout of, or branch stacked on a branch, on the server.
(I think you are the one who described the lightweight checkout
version of the idea.)  Using a stacked branch will not get you the
autodelete feature, though, and the lightweight checkout is probably
too draconian (only the current version is accessible locally).

On the other hand, I'm not sure that autodelete of old revisions is
such a good idea.  There has to be an easy-to-invoke way to prune
them, of course, but I have the feeling that autodelete is going to
mess up people who are editing and getting relatively rapid series of
revisions.  In an autodelete environment, though, they're inevitably
going to want to refer to rev. N-1, where rev. N is the most recent
available locally.

 > 3.  Need some kind of locking protocol so two artists don't edit an 
 > unmergable file at the same time.  I know this is heresy for dvcs,

The reason that it's heresy is that it's really not do-able by the
VCS, even a centralized one, unless your artists never refer to other
people's work while they're editing their own.  Once your artists have
local checkouts of files they're not editing at the moment but might
decide to edit at any time, VCS-based locking is either unreliable or
excruciatingly painful for the user.  The only time VCS-based locking
works well is when you have a strong division of labor, and only
occasionally run into clashes.  But then you mostly don't need it
anyway....

If the editor does it, however, things become very simple.  If the
artists are offline, they can't communicate anyway.  You warn the
user, who can then proceed at own risk or not.  If they are online,
they can see the server, and dotfile locking on the server by the
editor is basically what you want, plus some discipline of "commit
early".  This may require some scripting or the GUI equivalent to make
the discipline transparent to the users, of course.