Getting started with a content filter

[Chris Hecker]

> alienbrain

Yeah, I asked around, and nobody uses/likes it (some tweets below). 
Like I said at the beginning of this thead, this is a great opportunity 
for bzr to provide a more modern (not to mention OSS) alternative to p4 
for games and other mixed code+data projects if large binary support is 
really done right.

Chris

@kenpex Angelo Pesce
@ChristinaCoffin @checker Ye I've used AB, 5 yrs ago. It was ok-ish for 
data and terrible for code. Perforce is better for both.
14 minutes ago

@CornyKorn21 Nick Korn
@checker We use Alienbrain at our studio... I'm personally not a fan of 
it one bit. At least not for code.
1 hour ago

@justin_liew Justin Liew
@checker we used it once and it was a disaster.
2 hours ago

@ChristinaCoffin Christina Ann Coffin
@checker used that ages ago on a ps2 era project and hated it, most 
places lately just use perforce now for code+data
2 hours ago

@LukeHalliwell Luke Halliwell
@checker used it briefly early on at rtw. It was awful in so many ways. 
Switched to perforce.
2 hours ago

@polygonhell Rob Povey
@checker I don't kn ow of anyone who uses it anymore. I know of lots of 
companies who bought it.
3 hours ago

@TomHammersley Tom Hammersley
@tenpn @checker wasn't it all the coders' fault? Sigh...
10 hours ago

@ancient_james James Brown
@checker We used to use it at Lionhead
11 hours ago

@tenpn tenpn
@checker ...and they weren't happy about moving, let me tell you.
11 hours ago

@tenpn tenpn
@checker Codies used to use it for art. utterly useless but has max 
integration so the artists dig it. Recently moved them on to perforce.
11 hours ago

@cowbs John Bellomy
@checker I shipped a game with it, once, seven years ago.
11 hours ago

@plushapo Borut Pfeifer
@checker I worked on a team (@ SOE) where the artists insisted they use 
it, so we had 2, P4 for code, it was as horrible as you'd imagine.
11 hours ago


On 2011/07/28 23:14, Chris Hecker wrote:
>
>
> On 2011/07/28 21:27, Stephen J. Turnbull wrote:
>> But you're not terribly happy with the plugin idea, at least in the
>> long run.
>
> No, for the locking feature, a plugin is fine as long as it works
> seamlessly and robustly if it's installed. I think it's probably best as
> a plugin, actually, since it is specific to a setup. For the large
> binaries, I'm pretty sure it needs to be in core to be truly robust and
> have the right features to make it useful. At least, that's my opinion
> from my understanding of things right now; just making it clear.
>
> I think the "advances in merge technology with solve the locking
> problem" is a technological-solution-to-an-aesthetic-problem fantasy.
> There is no tool for the next 50+ years that will merge two textures to
> an artist's satisfaction (which, of course, won't stop a lot of useless
> siggraph papers being published on the topic that never get used in
> production, but that's a different problem altogether).
>
> On 2011/07/28 21:43, Matthew D. Fuller wrote:
>> Actually, I thought games/film/etc were more Alienbrain territory.
>
> Most people I know looked at it and decided not to use it years ago. I
> assume they have customers since there's a big list on their site, but
> at least at EA/Maxis, I didn't know of a single project that used it.
> All the content was in p4 (usually split up using p4's partial checkouts
> feature so everybody didn't have to sync everything). You want all the
> content and code in the same system so you can recreate a build exactly.
> Maybe Alienbrain will use p4 as a backend or something nowadays. I'll
> ask around.
>
> Chris
>
>
> On 2011/07/28 21:27, Stephen J. Turnbull wrote:
>> Chris Hecker writes:
>>
>> > 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.
>>
>> The long-run solution needs to be fixing the merge process. But
>> that's not going to happen soon.
>>
>> > > 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.
>>
>> Right, and what I'm suggesting is that you wrap the editor in a more
>> functional equivalent of
>>
>> #! /bin/sh
>> if ssh lockmgr at server mkdir $1.lock; then
>> edit-blob $1
>> if ! ssh lockmgr at server rmdir $1.lock; then
>> echo "Call admin, something went wrong with lock removal."
>> fi
>> else
>> echo "$1 is locked, please try again later. Lock information:"
>> ssh lockmgr at server ls -l $1.lock
>> echo "If it's taking too long, call locker or admin to find out what's
>> up."
>> fi
>>
>> If a user invokes edit-blob directly and forces a merge, then guess
>> who gets to spend Saturday doing it? :-)
>>
>> Of course, this only addresses the locking issue; the storage problem
>> has to be solved in the VCS somehow.
>>
>> > > 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.
>>
>> The problem is that code to deal with important (to you) practical
>> problems can easily impact the more important (to a large fraction of
>> the user community) already solved use cases and cause a regression.
>> It's not obvious to me that it's easy to determine when the use case
>> is "very centralized" and when it's not.
>>
>> I have no objection to doing this in a plugin, because that requires
>> that you, the user who needs it, enable it and you (only) can deal
>> with any fallout. But you're not terribly happy with the plugin idea,
>> at least in the long run.
>>
>> > Again, all this may be totally specific to my industry (video games),
>> > but I'd guess it isn't.
>>
>> In theory, it's not. In practice, my uninformed suspicion is that not
>> only is it fairly unique to video games and maybe movies, but there
>> are likely to be breakthroughs in merge technology that remove them
>> from the list. But you'd be better off asking Perforce and Subversion
>> developers about other use cases, since they've probably had bug
>> reports and feature requests from the relevant users.
>>
>>