Rule-based preferences - format marker RFC, etc.

[Ian Clatworthy]

John Arbash Meinel wrote:
> John Arbash Meinel has voted tweak.

> I don't really prefer putting the file in as a versioned file in the
> users workspace, but I understand the tradeoffs and I'm will to concede
> on this one. I would just make a strong request for a required format
> marker at the top of the file. Having one for .bzrignore would have
> meant we could have retained proper compatibility across versions.

I'm in agreement about supporting a format marker at the top of the file.
The issue is whether it ought to be required or optional. I'm pretty sure
poolie has a strong(?) preference for it to be optional. I'm OK with it
being required as long as the text is chosen in such a way that users
are unlikely to get it wrong. In other words, I think it needs to be as
simple as possible, case insensitive and probably whitespace insensitive.
How about the suggestion below?

  # format 1

In terms of regular expressions, I'm thinking ^#\s*format\s*(\d+)\s*$.
I considered putting the word "rules" in there as well but I think that
increases the chance of someone typing it incorrectly for no noticeable
benefit. (It's inside a file called rules or .bzrrules so I don't think
repeating that information buys much.)

Another option is to use a bzr version # instead of a simple integer.
My leaning is against this but I could easily change my mind if someone
made a strong case for it.

I guess it would be nice if the pattern chosen was adopted (in the future)
for .bzrignore as well?

> +``BZR_HOME/rules``. Either or both files may be missing. If a rule is
> 
> ^- I *think* convention is to use $BZR_HOME/rules. Whatever our standard
> is, should be used.

Our "standard" is to leave the $ out because that is too Unix-centric.
Windows users expect to see %BZR_HOME% for env variables, so we keep the
doc platform-agnostic by favouring neither. (I appreciate that there's
a risk someone won't appreciate that BZR_HOME is an env variable but
I'm yet to hear of anyone doing that.)

> I kind of feel like "patterns" should be its own topic, so that both
> ignore and rules can share it.

OK.

> I also wonder if we want '.bzrrules' to have an explicit file id. Like
> ('bzr:rules', etc). Something to think about.

I'm against this idea but I'd like to hear what others think.

At a minimum, it probably complicates every importer and the add code.
I'm not sure how it would impact performance. I can't think of a reason
why it would make things quicker, while increased complexity of code
paths to look for it could well slow things down. I'm also against it
because we might decide at some stage in the future to support a
.bzrrules file per directory (ala .gitattributes) instead of per tree,
so a special file-id doesn't scale. I suppose we could always go with
a family of special ids (rules:*) if that were the only issue though.

Any particular reason you suggested this? I'm probably missing some
obvious advantages?

Ian C.