Re: [fossil-users] Web comment editor transforms LF into CRLF

[Ross Berteig]

On 6/17/2016 5:33 PM, Scott Robison wrote:

On Fri, Jun 17, 2016 at 6:04 PM, Warren Young > wrote:

For any blob data that Fossil considers “text,” why not strip all
CRs on ingest, then based on either a setting or platform check
inject CRs as necessary when expelling a copy from the DB?  Then
users checking out on Windows will see the CRLFs they want, and
Fossil doesn’t have to deal with CRs appearing and disappearing as
different users on different platforms edit the same files?

Ah. I was just thinking for the text that fossil itself injects, not
something that would impact all blobs. I wouldn't be opposed to that
myself, but I can appreciate why it isn't a desirable thing for fossil
to do.


IMHO, I think that one of fossil's strong points is that it is 
remarkably unaware of text vs. binary issues. Storing all files byte for 
byte as they are in the file system is a reflection of that. So is being 
agnostic about line ending when implementing text presentation features 
such as diff.


For text that is the property of fossil itself, such as checkin 
comments, it is completely fair and reasonable for it to pick a 
preferred line ending and convert to it from entry and from it on display.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Web comment editor transforms LF into CRLF

[Scott Robison]

On Fri, Jun 17, 2016 at 6:04 PM, Warren Young  wrote:

> On Jun 17, 2016, at 1:59 PM, Scott Robison 
> wrote:
> >
> > Would it be a bad thing to just settle on LF only going forward, always
> stripping CR?
>
> The argument over canonicalizing all text input to LF has been had here
> before — with me as at least one of its proponents — but I did not get the
> sense that the proposal was getting much traction.
>
> But what the hey, I’ll make another stab:
>
> For any blob data that Fossil considers “text,” why not strip all CRs on
> ingest, then based on either a setting or platform check inject CRs as
> necessary when expelling a copy from the DB?  Then users checking out on
> Windows will see the CRLFs they want, and Fossil doesn’t have to deal with
> CRs appearing and disappearing as different users on different platforms
> edit the same files?
>

Ah. I was just thinking for the text that fossil itself injects, not
something that would impact all blobs. I wouldn't be opposed to that
myself, but I can appreciate why it isn't a desirable thing for fossil to
do.

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Web comment editor transforms LF into CRLF

[Warren Young]

On Jun 17, 2016, at 1:59 PM, Scott Robison  wrote:
> 
> Would it be a bad thing to just settle on LF only going forward, always 
> stripping CR?

The argument over canonicalizing all text input to LF has been had here before 
— with me as at least one of its proponents — but I did not get the sense that 
the proposal was getting much traction.

But what the hey, I’ll make another stab:

For any blob data that Fossil considers “text,” why not strip all CRs on 
ingest, then based on either a setting or platform check inject CRs as 
necessary when expelling a copy from the DB?  Then users checking out on 
Windows will see the CRLFs they want, and Fossil doesn’t have to deal with CRs 
appearing and disappearing as different users on different platforms edit the 
same files?

If the CR stripper sees that after stripping the CRs that reinjecting them 
before every LF gives a different blob, it should cope in some intelligent 
fashion:

1. Report that a text-like document seems to have mixed line ending styles, and 
ask the user if it’s okay to canonicalize it anyway.  This addresses the case 
where a non-text file that merely happens to pass the “is it text?” check 
shouldn’t be molested.

2. Use the crnl-glob setting to bypass case 1.  This gives you a way to 
whitelist certain files as always being text, and thus always safe to 
canonicalize.

3. Add a disabled-by-default setting to turn all this off, returning Fossil to 
its current behavior.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Web comment editor transforms LF into CRLF

[Scott Robison]

On Fri, Jun 17, 2016 at 1:53 PM, Warren Young  wrote:

> While trying to replicate the problem reported in another thread,[1] I
> noticed an odd behavior.  If I edit a comment via fossil ui, then pull the
> change and try to edit it locally with fossil amend, Vim shows ^M
> characters at the end of every line, implying that Fossil UI has
> transformed the LF line endings in the original comment into CRLF.
>
> I haven’t seen this until now because I always check in via the command
> line with EDTIOR=vim (because Vim is the One True Editor) but always in the
> past have edited comments via Fossil UI.  Today was the first time I tried
> fossil amend -e.
>
> According to the Internets[2], this is specified behavior, and is thus
> independent of browser or platform.
>
> I propose that Fossil UI scan the original comment text for CRs, and if it
> doesn’t find any, it should strip them out of the changed comment text
> before storing it in the DB.
>

Would it be a bad thing to just settle on LF only going forward, always
stripping CR?

-- 
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Web comment editor transforms LF into CRLF

[Warren Young]

While trying to replicate the problem reported in another thread,[1] I noticed 
an odd behavior.  If I edit a comment via fossil ui, then pull the change and 
try to edit it locally with fossil amend, Vim shows ^M characters at the end of 
every line, implying that Fossil UI has transformed the LF line endings in the 
original comment into CRLF.

I haven’t seen this until now because I always check in via the command line 
with EDTIOR=vim (because Vim is the One True Editor) but always in the past 
have edited comments via Fossil UI.  Today was the first time I tried fossil 
amend -e.

According to the Internets[2], this is specified behavior, and is thus 
independent of browser or platform.

I propose that Fossil UI scan the original comment text for CRs, and if it 
doesn’t find any, it should strip them out of the changed comment text before 
storing it in the DB.


[1]: 
https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg23395.html
[2]: http://stackoverflow.com/a/14217315
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL does not push edit comment changes, is this normal?

[Warren Young]

On Jun 17, 2016, at 8:07 AM, Tony Papadimitriou  wrote:
> 
> After editing a couple of check-in comments

How, exactly?  Via fossil ui or fossil amend?

> I did ‘push’ and saw zero artifacts sent.

I just did two edits, one via ui on the remote server and one via amend in the 
local checkout followed by a push, and both edits appear on both sides now.  
This is with

  fossil version 1.36 [63313a5f16] 2016-06-15 15:00:15 UTC
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL does not push edit comment changes, is this normal?

[Tony Papadimitriou]

I tried to reproduce the general sequence of actions on a fresh repo but I 
can't seem to repeat the problem.


However, it does it consistently on my end for this one repo.  I'm keeping a 
'frozen' backup of these two files (local and remote) for future 
investigation, if possible at a later time.  You know, like cryonics ... in 
hopes of finding a future cure :)


So, I guess that's one yet unfortunate test case because I can not possibly 
give it as is with the actual source code content (the comments and other 
peripheral info I do not care about).


Is there some way (via SQL) to delete just the file contents (I only need to 
blank or garble the content for certain file extensions that represent 
proprietary code -- many files) and then I can send you

the repo database so you can check its state, if this might help?

I realize there will be tons of warnings opening the now 'malformed' repo in 
order to attempt the push, but it may still be good enough for you to see 
the problem on your end.  I don't know.
So, if there is a way to obscure the file contents, and I can still 
reproduce it here on the 'dummy' repo files, I'll send them to you for 
examination.
(I suppose this is a somewhat common issue with sharing non-public repos for 
troubleshooting, so maybe you already know of a way to do this.)


-Original Message- 
From: Richard Hipp

Sent: Friday, June 17, 2016 5:15 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] FOSSIL does not push edit comment changes,is 
this normal?


On 6/17/16, Tony Papadimitriou  wrote:

This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC

After editing a couple of check-in comments, I did ‘push’ and saw zero
artifacts sent.  Here’s the output:

I don’t think this is expected behavior, is it?  If not, what could be the
problem?



It is not expected behavior.  Comment changes should always be pushed.
Do you have a reproducible test case?

--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users 


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] FOSSIL does not push edit comment changes, is this normal?

[Richard Hipp]

On 6/17/16, Tony Papadimitriou  wrote:
> This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC
>
> After editing a couple of check-in comments, I did ‘push’ and saw zero
> artifacts sent.  Here’s the output:
>
> I don’t think this is expected behavior, is it?  If not, what could be the
> problem?
>

It is not expected behavior.  Comment changes should always be pushed.
Do you have a reproducible test case?

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] FOSSIL does not push edit comment changes, is this normal?

[Tony Papadimitriou]

This is fossil version 1.35 [3aa86af6aa] 2016-06-14 11:10:39 UTC

After editing a couple of check-in comments, I did ‘push’ and saw zero 
artifacts sent.  Here’s the output:

Push to file://E:/db/xxx.fossil
Round-trips: 1   Artifacts sent: 0  received: 0
Push done, sent: 281962  received: 12407  ip:

I tried again and again with the same results.

This made me check the remote repo and, indeed, I did not see the comment edits.
Doing a ‘tim –R e:\db\xxx.fossil’ shows the same final check-in as the local 
repo.  So, only the following two edits are missing.

(The edits were done from the command with the ‘f am check-in –e’ command.)

Running ‘db –db-check’ on either repo says ok.

The only obvious difference I can see is that the remote repo still has a 
private branch which has been purged (and rebuilt) on the local repo but not on 
the remote.
(However, that branch is unrelated to the edits, obviously, or I couldn’t have 
done them – on a purged branch.)

I don’t think this is expected behavior, is it?  If not, what could be the 
problem?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users