Last day to vote/reject on proposed EOL names
lists08-bzr at davor.org
Tue Mar 31 02:30:02 BST 2009
On Tue, 2009-03-31 at 08:43 +1000, Ian Clatworthy wrote:
> In general, wt-format[:repo-format] where the default
> repo-format is lf. I'm happy to change the separator to -, +, / or
> something else but : seems as good as any.
How about splitting the two config items into separate
properties? E.g., what you have as "native:crlf" would instead
be something like:
eof = native
repo-eof = crlf
and one (presumably) common configuration for Windows developers
working on cross-platform projects would be:
eof = crlf
repo-eof = lf
Your defaulting of the repo-format is easily arranged by having
the "repo-eof" config property default to "lf". (Probably "eof"
should default to "native", but that's a whole other discussion.)
My property names, "eof" and "repo-eof", are just off-the-cuff
suggestions, btw; I'm sure they can be improved on.
Why is this an improvement?
Part of the difficulty with the current proposal is that cramming
both config items into one property makes for confusion (witness
the complaints that it seems "backward", that "crlf:crlf" is
confusing, etc.) Worse, it limits flexibility.
The wt-format and repo-format config items have different
audiences. As a few people have pointed out, the person who
cares about the working-tree format is the user of that working
tree, i.e. the individual developer. But if anyone at all cares
about the choice of repo format, it's the project's owner,
administrator, source-control guru, etc.; most users don't (and
shouldn't) give a hoot about repo formats, as long as bzr does
the Right Thing with the working trees.
Suppose that enforceable, versionable, project-wide configuration
were to be implemented some day. What one would want then for
configuring EOL treatment would be that the Big Cheese could
enforceably specify the repo-format, while still allowing each
individual developer to specify their own wt-format. The
eol = wt-format[:repo-format]
scheme doesn't allow for that; separate properties would do.
Even with the current config infrastructure, separate properties
are still better. Suppose a Big Cheese wants a repo-format of
CRLF. With the one-property scheme, they have to tell all their
developers: "You can set the first part of 'eof' to whatever you
like, but you MUST make sure the part after the ':' is 'crlf'".
With separate properties, they could say "set 'eof' to whatever
you like, but set 'repo-eof=crlf'". The two are semantically
equivalent, but IMHO, the latter is both clearer and less
More information about the bazaar