[MERGE] Merge Check EOL plugin into the core.

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jelmer Vernooij wrote:
| Am Dienstag, den 11.03.2008, 15:32 +0200 schrieb Alexander Belchenko:
|> From help topic:
|>
|> 	The 'checkeol' plugin installs special pre-commit hook to Bazaar VCS.
|> 	This hook allows you to check content of committed files for kind
|> 	of line-endings. If your project has strict policy about style of
|> 	source files you could automate EOL check with such plugin.
|> 	If some of committed files will have inappropriate line-endings
|> 	commit will be aborted.
|>
|> Here is the patch to merge this plugin into the core.
| No objections here code-wise, I'm just a bit worried that having this in
| core implies that we're going to support this particular file format in
| the future or at least would have to be able to upgrade from it. Is it
| really necessary to have this in the core? I'd rather see it being a
| separate plugin until actual line conversion support lands.
|
| Cheers,
|
| Jelmer

I also have my concerns about pulling it into core before it has cooked a while
as a plugin.

I wonder if we wouldn't want a file format marker at the beginning of the file.
This would have helped us transition .bzrignore in a compatible manner. We ended
up introducing support for **, etc without worrying about compatibility, but it
would have been nice to know what format the user was originally thinking when
they created their ignore pattern.

It would be nice to have an answer for people who want to require a certain
plugin/feature to be present. The answer for it with bzr has always been a
format bump. That way we know that older clients that do not support X won't be
reading and writing to a format they don't know about.

One way it worked in the past was the "post_commit=XXX" line in config files.
Technically we still support this.

Basically, you could do:

post_commit = bzrlib.plugins.my_plugin.commit

And it would evaluate that as a python function, passing it in the branch and
revision_id that was just committed.

The idea, though, was that you would set something in a config file, and bazaar
would run that function. If a plugin,etc, wasn't installed then bzr would fail,
rather than just not run the function. (Of course, as a post-commit hook this
didn't do anything but raise an ugly traceback that confused everyone who wanted
post commit emails, but the idea was there.)

I'm not sure that I have a good answer for it. It falls back to the problems of
centralized authority in a distributed system. It isn't hard to make sure that
anyone committing to "trunk" has all their checks passing, but making sure it
happens for every user at every commit is a bit tricky.

We've generally addressed this sort of thing by having a "policy plugin" that
would be given to people working on a project. That plugin could then make sure
that all of the "required" plugins were installed, etc.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH1/xjJdeBCYSNAAMRAoDsAKCTaF3Qnx1IaH4cZxyAGfW5em3I8QCgsR8+
Mjvrom5fwY8oj/w+RQoGbJQ=
=Hr15
-----END PGP SIGNATURE-----