Re: [Gnu-arch-users] windows/linux interop status - line endings?

[John Arbash Meinel]

Robert Collins wrote:

> On Sun, 2005-03-27 at 23:01 -0600, John Arbash Meinel wrote:
>
>
> > Robert Collins wrote:
>
>
>
> > > The one common point of interchange is the RCS. I think it has to be
> > > there that the solution is hooked in, whether its native to the RCS or
> > > not.
> > >
> > > Makefiles are not sufficient.
> > >
> > > Rob
> > Once we have pre-precommit hooks, you could always add a "dos2unix"
> > command to make sure commits are all done with a specific line ending.
>
> Sure, but it will be hugely substandard. It will then leave the contents
> of the tree in a different state than the user expected, with the
> following side effects:
> * cause spurious rebuilds
> * break environments that need the other format line endings
>
> If you then say 'ok, we can add a reversing rule in the post commit
> hook', you then have to deal with failed commits leaving the tree with
> converted files.
You could run "dos2unix" in the precommit hook on the patch entries.
This leaves the working tree alone, and just affects the patch logs.

You also have to be careful that when tla gets the pristine tree it is
going to build the same as in the archive. So ++pristine-trees or
$REVLIB (which is what tla does the diff against) is going to be in unix
line endings.

> > If you really want to enforce rules at the server, and you don't have
> > disciplined developers, then you need a server process.
>
> Who mentioned a server ?
You said that you wanted "unix line endings in the archive". With arch
only having smart clients and no server, there is no way to enforce
anything specific for commits to the archive. You can request that
anyone who has commit right uses your specific configuration of
precommit hooks, etc. But there is no guarantee. You need a
centralization point to create archive-side guarantees.

> > The best that
> > tla offers (which is pretty good) is a patch-queue-manager.
> > It changes how things work, but it does give you server side control
> > over what is committed into your archive.
>
> Sure it does. I maintain arch-pqm for baz and tla. And it doesn't solve
> this problem except in 'patch-text mode', which is a pretty limited and
> unsatisfying deployment.
I can't say what currently exists in the arch-pqm. But it seems like it
wouldn't be very hard to tell it to merge changes, and then fix line
ending issues before committing to the mainline archive.
Since you can tell it to run "make test" before you commit, I don't see
why you can't "runCustomLineEndingFix" as part of the testing.

Then you can have a "unix" archive, "mac" archive, "win32" archive,
where in each archive the files are in the appropriate line endings, a
commit to one wakes up the pqms to merge it into the other archives.

I honestly don't see why you *need* to have line endings automatically
converted. But I'm not in your deployment, so my needs are different.

It seems like you can just make the statement "line endings = LF", make
sure that is true on your mainline, and work with people whose patches
break this rule.

> > The "consistent" action that tla does is leave things alone, and commit
> > exactly what you gave it.
>
> Which is /not/ the same as a pre-pre-commit hooks impact (see above).
I agree. I would prefer tla accidentally commit a CRLF change if I
accidentally make the change, rather than secretly doing a conversion
behind the scenes.

Actually, what I prefer is to have tla warn me if I try to commit
something as CRLF. Which is why I created a precommit hook script that
aborts the commit if it finds a file with wrong line endings (but lets
me override it with a comment in .arch-inventory).

> Rob
John
=:->

signature.asc
Description: OpenPGP digital signature