Getting started with a content filter

[Stephen J. Turnbull]

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.