Getting started with a content filter

[Stephen J. Turnbull]

Chris Hecker writes:
 > 
 > > On the other hand, I'm not sure that autodelete of old revisions is
 > > such a good idea.
 > 
 > I'd be okay with a manual prune of old history if it was fast and worked 
 > well.  But, once the feature is in, there's no reason you couldn't also 
 > have it run automatically for artists as an option.

True.  My bet is that you'll need to tune frequency for some of them,
though.

 > I'm not sure why you say the locking thing doesn't work with a 
 > centralized vcs; it works fine in practice.

Well, as I said it will work if you have a sufficiently low frequency
of collisions.  I'm surprised you consider lock-management-by-walking-
around a reasonable workflow, but obviously I've underestimated the
cost of a simultaneous edit or overestimated the cost of "walking
around" in your environment (probably both).

I'm also surprised that you expect editors to universally refuse to
edit read-only files.  Some text editors, at least programmers'
editors on Unix, are perfectly happy to allow you to edit content
loaded from a read-only file.  You only find out about that when you
try to save, and the editor tells you the original is read-only and
asks for an alternative name, or (given POSIX semantics for
directories) whether you want to try to force-write the original.

 > It has to be supported by the vcs because the reality is it isn't
 > supported by all (any?) editors, so that's a non-starter.

Well, you'd have to wrap the editors in scripts or a GUI front-end to
make the workflow transparent.  

 > I'm not sure what you could do about the online requirement to make it 
 > less heresy,

Requiring that the VCS be online most of the time is not heresy in
Bazaar.  Bazaar supports lightweight checkouts (and does it well),
which require contact with the server for anything related to
revisions other than the one checked-out.

Edit-locking is a serious design problem, though, because it can only
be made to work reliably in a very centralized context.  As you've
acknowledged (indirectly) it's probably quite possible to come up with
a robust design presuming your environment, but it's going to be very
tough nut to crack for the general user if there's even a teeny bit of
distributedness (eg, stacked branches) involved.