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

[Jens-Heiner Rechtien]

Hi Bjoern,

Bjoern Michaelsen wrote:
> Jens-Heiner Rechtien wrote:
>> Martin Hollmichel wrote:
>>> any reason why ?
>>
>> Not on principle, just because of the overriding per log message
>> mechanism. The same guys who can't be bothered to do a diff before
>> committing will almost certainly use the overriding mechanism without a
>> second thought.
>> The problem is that the overriding mechanism would be needed to often,
>> mostly because of the check for tabs.  Without that one a python
>> implementation of that script might be acceptable though I would do
>> things differently.
> My hope was that becoming "the guy that always gets the tabs wrong"
> might be enough of an embarrassment to keep that from happening. Maybe I
> am a bit naive.

Well, I guess barring them for 2 days from committing after they have
been found out will be far more effective :-)

> 
>> The script would also at least need to discern between commits done for
>> rebasing and others. You'll almost always have an exceptional file in
>> every rebase and people will be annoyed if their scripted rebase fails
>> due to such checks.
> True.
> 
>> The other thing is I have to check first if bzr, git or mercurial have a
>> similar mechanism. Once these things are in place people get so used to
>> it they can't live without it any longer. Might sound stupid but it is a
>> fact of live ... I learned that the hard way.
> 
> bzr, git and mercurial cannot do that in the way svn does by definition.
> With those you commit locally and thus commits are out of the control of
> RelEng. However:

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.

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

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.

> - Commits to tags/trunk/whatever shouldnt be possible with DSCM as the
>   repos holding those should be owned by RelEng and be readonly for the
>   rest of the world(*). Anyone unhappy with the way RelEng handles their
>   repos will be easily able to clone and pull from those, so this is not
>   at all "less open".

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

> 
>> But: Do you really want RE impose such stupid things on you? I rather
>> don't want to police things. If really a majority of the developers want
>> that RE polices your commits ... well, I've got a number of ideas there
>> ... :-)
> 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 :-)

> What otherpolicies do you have in mind? ;-)

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 :-)

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