Getting started with a content filter

[Chris Hecker]

> Re locks: Locking files can be done already with a plugin, can't it?

Yeah, let's worry about locking later, since it's the _way_ easier 
problem to solve.  Doing the large file handling is much harder and more 
important to get right for moving forward.

I'll check out Simon's plugin at some point, it sounds like a good 
starting point, and yeah, I think I plugin can handle the locking just fine.

Chris



On 2011/07/28 13:12, Anteru wrote:
> Hi,
>
> so just before this discussion gets completely out-of-scope :)
>
> Is there some wiki/discussion page/blueprint where we can take down
> notes so the use cases can be gathered somewhere? It seems to me that
> use-cases and solutions get mixed up a bit, which is not a good thing.
>
> I totally agree with Martin that large files should just work as small
> files. Ideally, you just set some per-branch value of how much space I'm
> willing to allocate to old revisions of binary files. That doesn't sound
> too hard in theory, once the actual work-flow is written down.
>
> As I don't have the expertise to improve bzr to the point where all data
> is passed around as streams, I'll focus on the proof-of-concept plugin
> which just adds some support for storing large files. I'm away for the
> next three weeks though, so progress might be a bit slow.
>
> Re locks: Locking files can be done already with a plugin, can't it? You
> just have to perform a commit to add some metadata on check-out and
> another one on check-in, and your editor must pick up the metadata. I
> can't see how file locking can be built in into a DVCS unless you run a
> lightweight checkout, and honestly, isn't that enough for artists
> anyway? Do artists really need old revisions from the repository? My
> feeling is that artists are fine with tons of local copies that they
> somehow manage on their own, so having a lightweight checkout for them
> shouldn't be much of a problem. For developers, you want real branches
> of course, but that's fine as developers shouldn't collide on binary
> content anyway.
>
> Cheers,
>    Anteru
>