EOL extension

Brett Cannon brett at python.org
Mon Nov 30 14:56:49 CST 2009


On Mon, Nov 30, 2009 at 03:42, Martin Geisler <mg at lazybytes.net> wrote:

> Mark Hammond <mhammond at skippinet.com.au> writes:
>
> > On 30/11/2009 7:41 PM, Martin Geisler wrote:
> >> The old extension had a safety check in place so that it would not
> >> convert a file containing a NUL byte. We should add that to the new
> >> extension too. If Subversion's logic is equally simple, then you can
> >> get the Subversion behavior by putting
> >>
> >> [patterns]
> >> ** = native
> >>
> >> into .hgeol in the repository root. Here '**' is the glob pattern
> >> that will expand through directory separators, i.e., it will match
> >> all files.
> >
> > I seem to recall some objections to guessing based on the file
> > content. Maybe there needs to be different spelling for "this is
> > exactly what I want - please don't look at the content" vs "please use
> > my preference if the file contents indicate it is suitable"?
>
> I'm not sure it's necessary -- do you have any text files with NUL bytes
> in them? That's what we're talking about: excluding binary files (where
> we define a file to be "binary" iff it contains a NUL byte).
>
> >> I originally expected people to add the necessary patterns to .hgeol
> >> as they are discovered. Remember that this is *easier here than* with
> >> Subversion: the patterns are stored inside the repository instead of
> >> in ~/.subversion/config and so only one developer needs to update the
> >> pattern list when a new type of file is added.
> >
> > Being "easier than subversion" is an excellent goal, but we shouldn't
> > let a good assertion get in the way of actual experience ;) In this
> > particular case, that one developer who knows the pattern list needs
> > to be updated may not be the same developer who adds the new file.
>
> Is that a big problem? I don't think it is if we make it easy to correct
> mistakes.
>
> I think we should aim for a simple mechanism that get's it right 99% of
> the time. Simplicity is important here in order to make it easy to
> correct mistakes.
>
> So if you see a file called foo.xyz with Unix EOL style on your Windows
> platform, then you should only have to add "**.xyz = native" to the
> .hgeol file and run "hg eolupdate" to fix this.
>
>
I agree with Martin here. Simplicity with acceptable verbosity to correct
issues is the best path. A bad guess can lead to problems. Plus it's a
one-time fix that can be made by any developer.

-Brett



> > Subversion lets you make one (global) configuration change, and from
> > then on it does the right thing without further action being
> > necessary, regardless of the pattern of new files.
>
> You will also be able to specify a global pattern in your ~/.hgrc file
> (or the equivalent for Windows). That will then apply to all
> repositories.
>
> > IOW, my experience with subversion is "set preferences once, globally,
> > and it works as expected from then on." Aiming for easier than that is
> > certainly ambitious, but personally, I would be happy with nothing
> > more than that.
>
> Yeah, we're definitely some way from being able to make a full "easier
> than Subversion" claim :-) The claim only referred to the point about
> being able to specify patterns in the repository itself instead of
> having to do it in a per-user file.
>
> --
> Martin Geisler
>
> VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
> SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20091130/ab390bb5/attachment.htm>


More information about the Mercurial-devel mailing list