FW: Re: EOL: patch.eol=auto setting

[Martin Geisler]

alexrayne <alexraynepe196 at lavabit.com> writes:

> Martin Geisler пишет:
>>
>>>> i cant beleave that you checkout .hgeol every time for take hgeol
>>>> setting, i suspect you use working copy of .hgeol, so why you need
>>>> commiting one? just for sure?
>>
>> I've tried to explain it already: we want to carry the .hgeol file
>> around with clones, similarly to how .hgignore is moved around.
>
> hgignore is not required to be under version control, and this is very
> helps to work with it - i always can calculate what .hgignore realy do
> because i shure that current work version always used, so i shure what
> i have. if i think that it should be passed to other people, i always
> can commit it, no problems here

Yes, and I'm trying to make .hgeol behave the same.

> one big differences of svn and hg, imho, we are undervaluate - svn is
> central repository system, hg - distributed. so some tech even with
> eol-handling good for svn, may not work\or work bad in hg.

Oh, you are correct. This extension is an attempt to solve a problem
which is much more complicated here than in a central system such as
Subversion.

> to illustrate it i talk about cleanup commit and distributing of
> .hgeol. for svn this operation once done automaticaly stay
> repository-consistent and distributed for all. mercurial cant guaranty
> that this operation is done ONCE by ONE commiter and automaticaly
> distributes for all.

True, we cannot guarantee that. If people don't pull the cleanup commit,
then they wont get it, it's a simple as that and we cannot change that.

> Therefore techniq of using cleanup and .hgeol commiting, imho, can be
> producted anly after some period of havily use, and before this
> expirience achieved should be implemented safe and compatible methods,
> as i understand this methods must not affect repository and must not
> depend on repository state. therefore i vote for rules like
> some=native\auto

You're the first who has asked for a mode that wont affect the
repository. So far, everybody else has asked for a restrictive extension
which will stream-line the repository -- you'll see this when you read
the mails in the archive.

I can see how such a native/auto mode would be useful and I will try to
implement it if I can.

>> You might want to go back in the archives and read the discussions we've
>> already had about win32text:
>>
>>   http://markmail.org/message/yj4so736t4cfdulv
>>   http://markmail.org/thread/5volevnxgaisx2sc
>>
> wow, - i can read it very very long.

Yes, very long... A lot of people have said a lot of things about this
and you have sort of jumped into the middle of a huge discussion :-)

>> Sure -- I've just pushed a change that makes eol look for .hgeol in
>> the working copy first, and then in the tip revision if there is no
>> .hgeol in the working copy.
>
> how it can be? if .hgeol exist in tip revision, then it automaticaly
> appear in work dir after update.

Yes, this is flawed... As the TODO says (see the code), we should not
always read 'tip', but instead the target revision after a clone or
update. The problem is that we want to read .hgeol before it has been
written to the working directory. We need to read it so that we can
install the correct EOL rules, and so far we just read it from 'tip'.

> if i delete .hgeol by some reason, i expect that if it is not in work
> - then it is not play, but for my surprice it play like a ghost, like
> soul of one deleted file comes from other-world.

Yeah, I see what you mean. We don't want to have zombie .hgeol files
running around...

> i see strange diffs, to ensure i look for .hgeol, see that it is
> absent in work dir, and starts thinking deeply about anything else,and
> write issue reports....

Yeah, that's not so good... :-)

Merry X-mas!

-- 
Martin Geisler

VIFF (Virtual Ideal Functionality Framework) brings easy and efficient
SMPC (Secure Multiparty Computation) to Python. See: http://viff.dk/.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20091225/f8a12cf6/attachment.pgp>