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

[Robert Collins]

On Mon, 2005-03-28 at 00:39 -0600, John Arbash Meinel wrote:
> Robert Collins wrote:
> >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.

Yet its the working tree that matters when this matters. having arch
deal with different line endings / enforce them for patch logs is really
not a problem.

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

Sure, if the rcs is line ending ignorant.

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

Uhm. If the toolchain supports a tree specific policy, then you don't
need a server. We're not talking about attempts to crack the system,
we're talking about to make the right thing happen in a sane way. And
users of systems with different line endings just want it to work - they
are very unlikely to attempt to circumvent a good system. See for
instance CVS, I've never seen a user there circumvent the line mangling
supported by the client - because it does the right thing. (when its all
setup right, of course).

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

Would this work ? For some use cases yes. Its got problems though..
1) It breaks annotate
2) It makes dealing with this problem a per-project problem, rather than
something we fix for all projects.
3) It doesn't work for a single user that develops on both platforms, in
the same archive / branch.

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

In the context of this discussion, my deployment is the code for
hackerlab, package-framework, libarch etc. I want to get Windows users
and developers excited and developing this code base, and doing it
easily. I want them able to use their preferred toolkits - visual studio
for some, ultraedit for others, vim or emacs for others. I want their
archives to be directly mergable by me for review and interoperation,
and I want it to be *easy*.

I don't see any reason to do this *outside* the RCS. And I see many
reasons to do it *in* the RCS.

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

Uhm. Merge conflicts due to changed line endings are frusting as all get
out. They waste everyones times. Big diffs to review for the same reason
are also a huge timewaste.

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

Why? Seriously, imagine this scenario:
$ tla set-native-eol-style unix *.c
foo.txt will commit your CRLF change if you make it.
bar.c if you run dos2unix will not commit any change at all. (And diff
will show no changes).

All our underlying tools - patch and diff - already support this, we
just need a way to tell the tree our user policy, and to pass the right
options down.

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

Sure, thats a useful workaround. Wouldn't it be nice to have it JustWork
for the files you want it to ?

Rob

signature.asc
Description: This is a digitally signed message part