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

[Bjoern Michaelsen]

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.

> 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 ...

Have Fun,

Björn

-- 
===========================================================================
Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1, D-85551 
Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schröder,Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering

===========================================================================
_______________________________________________
Dev mailing list
Dev at lists.go-oo.org
http://lists.go-oo.org/listinfo.cgi/dev-go-oo.org