Last day to vote/reject on proposed EOL names

[Talden]

On Thu, Apr 2, 2009 at 3:04 PM, Mark Hammond <mhammond at skippinet.com.au> wrote:
>> You're counting on every users editor to do the right thing.  They
>> don't.  So the alternatives are this, pre-processing at point of use,
>> using hooks to prevent commits reaching the repo with incorrect
>> content.
>
> I'd argue for simply preventing the commit from succeeding.  IIUC, this is
> only likely in practice if, say, someone on Windows edits this shell script,
> then checks it in without testing it.  If they tested it (say, using
> cygwin), they would detect the breakage.  The other scenario seems to be a
> linux user makes changes to the Visual Studio project file - again, without
> testing.  In both these cases the user was (a) using a brain-dead editor and
> (b) probably has no real business changing that file in that way.  Therefore
> I'd think rejecting the checkin is a safer option - they may have *meant*
> the file to be checked in that way for some different scenario - rejecting
> the change means they can either (a) fix the file, or (b) fix the rule for
> that file.

In a DVCS world doesn't commit prevention assume everyone has
responsibly set up their hooks appropriately?  This can't be embedded
or enforced in the project itself right? Likewise, assuring that
enough testing occurs is tricky too - however the new EOL mechanism
should work correctly unless deliberately tampered with.

The users need to be able to edit the files and, with the range of
tools available, some of them are going to do something stupid
(clipboard handling is one example already given).  Ideally I guess we
could have tests to ensure correctness and use a gatekeeper workflow
that prevents commits to mainline with such violations - I won't be
able to sell that workflow to my organisation though (despite the fact
that it's probably the better choice).

--
Talden