It seems like we should either be consistent and set svn:eol-style: native in all the appropriate files or remove it from all of them. Having a some files with the property arbitrarily seems like a bunch of unneeded entropy.
Adam On Tue, Jul 21, 2009 at 4:11 PM, Peter Kasting<[email protected]> wrote: > If you do not develop on Windows, you may skip to the "*** Question ***" > portion below. > *** PSA for Windows developers *** > Until now WebKit developers on Windows have had to use the Cygwin version of > svn, rather than a "standard" Windows svn, due to limitations in the WebKit > scripts, build process, etc. > On https://bugs.webkit.org/show_bug.cgi?id=27323 I have been working to > remove those roadblocks, and today I have locally succeeded in using my > Windows SVN to: > * check out > * update (via update-webkit and resolve-ChangeLogs) > * build (via build-webkit) > * run (via run-safari) > * prepare patches (via prepare-ChangeLog and svn-create-patch) > * apply and unapply patches (via svn-apply and svn-unapply) > * commit (using commit-log-editor) > Added bonus of a couple other fixes: I did this with a > WebKit-inside-Chromium checkout. In theory this means projects that wish to > include WebKit from the master repository (via svn:externals or some other > mechanism) as part of their source tree may be able to develop in a single > checkout. > Not all these patches have been reviewed and landed yet, but things are > close. > *** Question *** > There is one roadblock to this setup. SVN-on-Windows seems to have a bug > where sometimes (depending on the state of the repository and the checkout), > the diffs it produces for files without svn:eol-style set won't > apply/unapply cleanly, due to line ending issues. > The obvious workaround is to set svn:eol-style everywhere. This has other > side benefits (e.g. preventing files from being checked in with mixed line > endings, and preventing line-ending-sensitive files from being changed > accidentally), and I am told by Eric Seidel that in fact some time ago Darin > Adler used to try and maintain something like this. As a result, a large > portion of the WebKit tree already has this property set. > My question is, how desirable and feasible would it be to return to having > eol-style everywhere? > For a relevant anecdote, in Chromium we enforce that files have > svn:eol-style. This was done using three steps: > * Scripts were used to find files lacking svn:eol-style and set it > appropriately. > * A commit hook was added to prevent developers from regressing this. > * We document a set of auto-props to configure SVN with, so that it will > automatically add eol-style on new files without developers having to do it > manually. > I am not capable of doing the first two of these steps myself, but there are > Chromium team members who could consult if we decided this was a desirable > path for WebKit. The goal would be to minimize disruption and not cause any > ongoing annoyance. > Comments? > PK > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
