Getting started with a content filter

[Chris Hecker]

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