Need a way to set content-filtering rules across a project

[Marius Kruger]

Hi,
there has been some discussion about the implementing branch-specific
rules in this bug https://bugs.launchpad.net/bugs/395731

I'm forwarding it to the list because I think we should rather discuss
the implementation here (and document on the wiki) rather than in the
bug.
Hope its ok, please see the bug for more context and previous discussion.

> --
> Need a way to set content-filtering rules across the project
> https://bugs.launchpad.net/bugs/395731
> You received this bug notification because you are a member of bzr-core,
> which is subscribed to Bazaar.
>
> Status in Bazaar Version Control System: Confirmed
>
> Bug description:
> We need a way to set content filtering rules in the tree.
>
> ----
>
>
> Context:
> I want to use content filtering to fix the line endings horror. Content filtering only works when a lot of preconditions are met, otherwise it fails silently (simply does not work WITHOUT reporting an error) even though it is configured in .bazaar/rules.
>
> [This by itself is a serious bug in my eyes because it causes silent corruption of the repository (files containing a full delta because their line endings are incorrect). This is quite horrible and cannot really be seen by the developer - he just sees the files he's worked on being committed. Only a long time after this merge will the problem be seen, when another merge is attempted causing a full conflict.]
>
> Problem:
> One of the preconditions to have content filtering work is to have "Working Tree Format 5", earlier versions do not support it (and do not fail but continue to work, committing garbage = files with incorrect line endings).
> When you branch locally from a repository containing a "Working Tree Format 5" tree the resulting branch will be correct, and will have a version 5 tree also. This is correct.
>
> However when branching from a smart server (which uses branches in a shared init-repo) you get the "default" working tree format 4, which is incapable of content filtering. This results in a working tree having incorrect line endings and corruption when files get commited having incorrect line endings.
>
> Solution:
> A proper solution would be to use at least format 5 when the repository format itself is capable of content filtering. Or to be able to specify a minimal format in the server repository.
>
> For now I have to resort to patching bazaar for all my developers, changing the default working tree format to 5 in bzrlib/workingtree.py, last lines 8-(.
>
> A final note:
> In addition, it starts to become very important to be able to force some bazaar configuration into the tree somehow. The current solution for line endings depends on every developer having a properly configured workstation. Any failure to properly configure will cause problems in the repository which is shared by everyone, this is quite unacceptable. This does not ony go for line endings but also for things like required plugins (commit checkers and such).
>
> It might be sufficient to have a version controlled ".bazaar-config" directory in the root of a tree containing the master rule file, and a list of required plugins and their version (not the plugins themselves). At this moment it is way, way easier to get things wrong than to get things right.
>


On 11 November 2010 02:16, Frits Jalvingh <jal at etc.to> wrote:
> Ok, my first proposal was delightfully naive 8-(. Always fun to see something that appears to be easy to have a huge pile of hair..
> So, I did some more thinking to try to get a more failsafe solution- and it proves to be quite nasty. I have written down the details as far as I see them now at http://wiki.bazaar.canonical.com/fjalvingh. A short rundown of the conclusions is:
> * Any filtering rule change MUST go through the bzr UI. The file should NOT be user-editable at all (there is an alternative but it is more ugly)
> * Changing rules is allowed for a non-dirty working tree only
> * Changing rules may (must) cause the rewrite of the working tree, forcing those files to be proper for the new rules.
> * Some changes must fully-change the repo with a commit. It would be good if the user would be warned when this happens because merging stuff from before that point could be almost impossible..
>
> @Marius: thanks for your answer. I see some trouble with maintaining the
> rules file there and imposing a normal (file based) merge on it. I don't
> like the idea of my users mucking around in there- there's all kinds of
> stuff below .bzr and allowing them to edit there (as they will when
> there is a conflict) can open cans of worms attracting fishy problems.
>
> The versioned properties thing looks more like it, although the merge
> rules for the rules file would actually be quite funny if you do it
> right; it should not just give two copies of a big multi-wildcard spec
> there. I would be surprised if actually merging files would be a good
> idea there. It might be best just to merge serialized structures using a
> special UI.