Getting started with a content filter

[Chris Hecker]

> I'm surprised you consider lock-management-by-walking- around a
> reasonable workflow,

It's way better than the alternative, which is two different artists 
spending a day working on the same file, and then having to either 
choose which version to keep, pissing off one of the artists, or forcing 
them to spend another day "merging" their work, pissing off both of 
them.  And yes, the rate of collisions is low, because everybody is 
working on different stuff most of the time, and that stuff is (at least 
roughly) centrally planned by producers or art directors.  But, the VCS 
has to at least put up a fight if two people try to work on the same 
thing.  Walking around, IM, a phone call, these are all reasonably 
efficient ways of dealing with the problem, even on distributed game 
teams.  If you're in Montreal and you find somebody in Shanghai has 
locked a texture file you want to edit, you send them an email, and then 
go work on something else until they reply.  It's just a different set 
of use-cases from programming, where that would block you completely 
because you can't fix the header or whatever and you can't finish your 
feature because of that.  It works fine for art assets.

> I'm also surprised that you expect editors to universally refuse to
> edit read-only files.

It may not be universal, but they almost all warn if the file is 
read-only, mostly because they've been made to work well with p4 over 
the past decade.

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

Artists can be trained to use p4win and similar things just fine.  They 
just need help for things they can't magically know, like somebody else 
on the team is in the middle of editing the same psd.  That's the 
problem we're trying to solve here, and it's totally solvable with a 
couple reasonable assumptions.

> Edit-locking is a serious design problem, though, because it can
> only be made to work reliably in a very centralized context.

Sure, which is why I was musing about the general dvcs case in my 
previous mail, but the centralized case is still an incredibly important 
use-case (at least for my industry, and I would assume any industry that 
has humans editing large unmergable binary files).  It's important not 
to get hung up on not being able to solve the hard theoretical problem 
perfectly, and not use that as an excuse to not solve the important and 
relatively easy practical problem that people actually need solved.

Again, all this may be totally specific to my industry (video games), 
but I'd guess it isn't.  And, as I was remarking to Martin and John 
offlist, if bzr solved these problems right, like making large binary 
files 1st class citizens rather than handled with hacky plugins, then it 
would be a big leap forward for dvcs.  I know a lot of people in the 
game industry who would love to switch to dvcs from p4/svn, but they 
have to have the large unmergable binary file problems solved first.  My 
guess is open source projects will start to get more and more assets 
like these in them as things become more graphically oriented, too.

Chris




On 2011/07/28 02:13, Stephen J. Turnbull wrote:
> 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.
>