Getting started with a content filter

[Chris Hecker]

> 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.

I think I know about all the workarounds with the various dvcses right 
now, and they're all pretty bad.  If I don't get something in bzr by the 
time my content directories grow (either the separate server hack with 
stub files, or the Real Thing), I will just put those in svn or p4 since 
I know they work.  That will suck, but I'm mentally prepared for it. 
Most game developers just say dvcs isn't worth they trouble if they 
can't have all their files in one system, and I can empathize with that.

I'm not sure why you say the locking thing doesn't work with a 
centralized vcs; it works fine in practice.  The file is marked as 
exclusive-checkout, it's read-only until checkout, you check it out, 
it's made writable, your name is added to a list on the server, when 
somebody else tries to check it out, it says "Stephen has it checked out 
already", you can walk over and ask them what's up, or the admin can 
force uncheckout the file, and you can always toggle the read-only flag 
locally if you know what you're doing.  That workflow is not fancy, but 
it works fine, and it prevents two artists from modifying an unmergable 
file.  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.

I'm not sure what you could do about the online requirement to make it 
less heresy, but the fact is, the feature is needed if the large binary 
support is going to be usable by production teams, even if it only works 
online and warns heavily if you're offline.  The good news is it seems 
artists work on laptops on planes and cafes way less frequently than 
programmers do, so the online-only constraint won't actually be that 
painful.

Chris




On 2011/07/27 21:30, Stephen J. Turnbull wrote:
> 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.
>
>