[ooo-build] [go-oo.org Dev] CRLF line endings

[Jens-Heiner Rechtien]

Bjoern Michaelsen wrote:
> Jens-Heiner Rechtien wrote:
>> Well, I guess barring them for 2 days from committing after they have
>> been found out will be far more effective :-)
> 
> Thats too much of an BOFH for me. I would prefer something like an
> "worst abuser" posting to your blog featuring some embarrassing
> statistics every six month ;-)
> 
>> Well at least for the Python implemented DSCMs I can easily imagine that
>> hooks and scripts could be "inherited" via the cloning command. Or we
>> require a custom plugin that does these kinds of checks. As I said I
>> have to check out what's possible, I wouldn't rule out the possibility
>> of implementing these things categorically. There will always be a way
>> around that of course if someone dares to do so.
> I would never trust the client. Custom plugins are nice, but there is no
> way to rely on them.
> 
>>> - Formatting can easily be checked when a cws is nominated
>>>   (and wont be integrated unless cleaned up)
>> Same situation as now. Where's the difference?
> Mutiple devs working on one cws. Although that is rather rare by now, I
> guess (but that might be different with a DSCM).
> 
>> It's not that "easily" done by the way, there are a huge number of files
>> in a typical nomination/integration round and there are already a number
>> of things to be inspected. Anyway I will in future refuse to integrate
>> CWSs where I notice such things and I'll ask my fellow REs to do so
>> likewise.
> Yes, please. I think the most important part of it is feedback to the
> dev so he might do better next time.
> 
>> Comitting on tag is a SVN specialty, granted. But I've got no problem to
>> imagine any number of things people do wrong with a DSCM as well: I've
>> deleted my WC ... oh my, my changes are gone as well ... got no backup
>> ... can you implement something which prevents me from doing a "rm -rf"?
>> ... OK I'm being sarcastic here. But all DSCM I've tested have some very
>> subtle ways to go wrong. With mercurial it's the easiness with which
>> there are unwanted "heads" created or the clumsiness of named branches.
>> With git it's everything which is related to the index (I'm sure I've
>> committed everything. Wait ... I forgot to stage that file, oh oh).
> True, but this is a bit beside the point. DSCM is so different in
> concept, that switching to one would create a lot of issues to solve
> (but is also the chance to do some things a lot more elegant). I would
> assume each cws would get its own hosted repo, to allow people to watch
> what is going on elsewhere.
> If you like I would certainly enjoy having a brainstorming session with
> you and some others on how one would do DSCM for OOo ...
> 
>>> Things that are easily checked (like certain formatting issues) should
>>> be. Tabs and linebreaks should be reliably checkable.
>> They aren't reliable without an elaborate heuristics. Certain makefiles
>> require tabs. Third party stuff shouldn't be changed unnecessarily.
>> Patches to third party stuff might contain legitimate tabs. Generated
>> files might contain legitimate tabs - on the other hand committing these
>> files is a mistake in itself, one I would check for :-)
> Which is why my proposal contained the write-some-special-string in the
> log message escape door (and only checked *.cxx|*.c|*.h|*.hxx files).
> ;-)
> While there are those exceptions, they are rare in day-to-day commits.

Yeah and that's exactly the problem. Heuristics that work 90% or even
95% of time are *evil* because everyone expect them to work always.
Really, we've been there before.

And you don't really want to antagonize the Java, Objective-C++, Perl
and Python developers in our community, do you? :-)

> 
>> No restructuring on release branches. Yup that's a policy and one I care
>> much more about than tabs. Will be implemented first if I start policing
>> the commits. Of course, YMMV :-)
> I wonder how you want to check for those reliably in a hook ...

No file deletions, no file adds for a starter. Simple. Oh, there might
be some legitimate exceptions (5% or so where it doesn't work otherwise,
like for those poor Java guys) but we can easily implement a system
where RE approves these few cases. Of course RE will only notice such
requests for approval if bribed properly ... :-)

Heiner

-- 
Jens-Heiner Rechtien
rechtien at sun.com
_______________________________________________
Dev mailing list
Dev at lists.go-oo.org
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org