Getting started with a content filter

[Chris Hecker]

> This one is tricky. And because of this requirement, I feel it should
> be a specialized plugin/storage mechanism. There are lots of things
> like lightweight checkouts/stacked branches etc that one could do. It
> just feels like storing them out-of-band works best here.

My guess is this means the feature is pretty much doomed to not work 
robustly in all cases, sadly.  It's exactly like the 
submodules/externals problem, but it's maybe worse, because the files 
are part of the core project, not some recognized modular external 
library or whatever.

I really wish I could convince one of the big three dvcs core teams that 
this set of features could form a foundation for a "next generation" 
dvcs, and that this is a big hole in the supported use-cases of existing 
dvcs.

Frustrated,
Chris


On 2011/08/05 02:50, John Arbash Meinel wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> ...
>
>> 2.  Can't have entire history in all branches because it gets too
>> big too fast on clients, need to store most of the large binary
>> history on a server.  Is there a way to specify a partial history
>> like this now?  Are stacked branches something that could help here?
>> It'd have to be per-file, though, not global to the entire branch.
>> In other words, I want all the code revisions local (or most of
>> them), but only the past two large binary revisions, or whatever.
>> The code would need to delete old history locally as new history is
>> checked in (assuming it's been successfully pushed to the server, of
>> course).
>
> This one is tricky. And because of this requirement, I feel it should be
> a specialized plugin/storage mechanism. There are lots of things like
> lightweight checkouts/stacked branches etc that one could do. It just
> feels like storing them out-of-band works best here.
>
>>
>> 3.  Need some kind of locking protocol so two artists don't edit an
>> unmergable file at the same time.  I know this is heresy for dvcs,
>> but it's going to have to get solved somehow if people are going to
>> use bzr for these media projects that need the large binary files.  I
>> think this isn't that big of a deal for this use-case, because #2 is
>> going to require a server be accessible often anyway.  Not sure what
>> to do when both artists are offline, but at least warning would be
>> something.
>>
>> Chris
>
> There are 2 plugins I know of that provide some sort of cooperative
> locking support for bzr. I had been working on one (about 50% complete,
> IIRC), and someone else put one together. Though I can't find it now.
>
>   lp:~jameinel/+junk/file_locking
>
> I was happy with how mine was fleshing itself out. It basically writes a
> file to a shared location that tracks what files are/aren't locked. It
> tracked what *needed* to be locked by glob, IIRC.
>
> In a distributed system, locking is going to be cooperative, but if the
> tool support is reasonable, then I think it is fine to add. I still
> don't quite understand *why* two people would be trying to edit the same
> large-binary in incompatible ways. Although, maybe it is say editing the
> beginning and ending of a video. Which is perfectly compatible, just bad
> tool support for merging the changes together.
>
> John
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (Cygwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk47vMgACgkQJdeBCYSNAANkUwCglXpEBiLzfsjVncINHb2KnDpf
> D1MAoM/fgq8NxgLRZStNwRIXNihumCFz
> =yhtU
> -----END PGP SIGNATURE-----
>