Re: [fossil-users] Fossil_v_2_0 Bug: Abandoning commit due to long lines in Foo

[Joerg Sonnenberger]

On Tue, Mar 21, 2017 at 08:05:33PM -0400, Richard Hipp wrote:
> Those servers are all hosed by OVH at https://www.ovh.com/us/ - to
> whom I have written multiple time and who seem utterly unconcerned.
> Be sure to say bad things about OVH on all your social media posts.

I've filled a complain with the Canadan Spam Reporting Center against
OVH Canada now. Let's see if they are more concerned about it.

Joerg
___
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_v_2_0 Bug: Abandoning commit due to long lines in Foo

[Warren Young]

On Mar 21, 2017, at 5:49 PM, Martin Vahi  wrote:
> 
> I tried to commit the batch of small files
> individually. No luck:

The error tells you why:

> ...facebook.html
> contains long lines. Use --no-warnings or the "binary-glob" setting to
> disable this warning.
>Commit anyhow (a=all/y/N)?

So either:

1. Say “yes” or “all” to the query

2. Give --no-warnings with the commit command

3. Add an *.html rule to your binary-glob setting to make it skip the “looks 
like UTF-8 text” check during the commit.

That check exists because Fossil is primarily meant to store text, and the 
exceptions are generally easy to match with binary-glob rules (e.g. *.png).  
Fossil is warning that you may be committing something you didn’t mean to 
commit, like an executable.

The only reason it thinks these long-line HTML files are “binary” is that the 
“looks like UTF-8” heuristic doesn’t scan the entire file looking for newlines 
and such.  It gives up after a certain number of bytes checked, since proper 
text files rarely have very long lines.  But, all heuristics are imperfect by 
definition, which is why there are workarounds.

Fossil will store and reliably retrieve binary data.  This is one of those “are 
you sure you want to do that?” things, not a “you’re an idiot if you do that” 
things.

Fossil is second-guessing you only because binary files defeat many features of 
Fossil:

1. Many binary file types are also compressed, so that as little as one bit 
changed in the raw data format could potentially change every byte in the 
output file format, utterly defeating Fossil’s delta compression algorithm.  If 
you’re storing bitmaps, therefore, store Windows BMPs in preference to PNG or 
JPEG.  If you need PNG or JPEG outputs, generate them from the stored BMPs as 
part of the build process.

Bonus: this lets you change things like color space or transparency rules 
without re-storing all the bitmap files, simply by changing the conversion 
script.

(Incidentally, “uncompressed” bitmap formats like TIFF can also be a problem 
because they may contain metadata that changes with each save, like timestamps 
and GUIDs.  In one test I did here, changing one pixel in a TIFF image caused 
something like 10 kB of deltas in the resulting TIFF!)

2. Most binary file formats can’t be displayed in Fossil UI unless it’s one of 
a small number of well-known web file formats.  There may be an alternative 
file format that will avoid these problems and still solve the same problem, 
such as SVG instead of Adobe Illustrator format, or Markdown over PDF.  (And 
plain-text SVG over compressed SVGZ to avoid problem #1.  Let Fossil compress 
your data, so it can see inside the file.)

3. A “fossil diff” command can’t do anything useful with binary data.

4. Fossil can usually merge two changes to a single text file automatically, 
without user intervention, and when it can’t, it writes conflict data to disk 
to help you merge the files manually.  Fossil can’t help you at all if two 
users edit a binary file at the same time unless the changes are 
well-separated, and they’ll only be so if you avoid problem #1 above.

Again, none of this prevents you from storing binary files in Fossil.  They 
just give you…encouragement…to use some equivalent text based file format 
instead.

> I received a spam email that used my own subject

These emails are typically similar enough that spam filters learn about them 
pretty quickly.  About once every few months, whoever is doing this changes the 
emails enough to start slipping them through the filters again.

It’s possible that info is outdated, since I haven’t seen such spam since 
changing our company email servers over to a provider with a reputation for 
strong spam filtering with a low false positive rate.
___
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_v_2_0 Bug: Abandoning commit due to long lines in Foo

[Richard Hipp]

On 3/21/17, Martin Vahi  wrote:
>
> P.S. Right after sending my previous Bug report
> to this list, like, literally in 10 seconds,
> I received a spam email that used my own subject
> line with the "Re:" prefix as its email subject.

From "Eboni"?  I'm very sorry about this.  I wish I was able to track
down who is doing this, but I don't know how.  Eboni has been a curse
on this mailing list for a long time.

I managed to stop the Eboni porn-spam coming to me by blocking the
following IP addresses on my email server:

  144.217.94.196
  144.217.165.151
  2607:5300:201:3000::/64

Those servers are all hosed by OVH at https://www.ovh.com/us/ - to
whom I have written multiple time and who seem utterly unconcerned.
Be sure to say bad things about OVH on all your social media posts.

-- 
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_v_2_0 Bug: Abandoning commit due to long lines in Foo

[Martin Vahi]

I unpakced the stblob that I tried to commit
at the case that I described at my previous bug report
and I tried to commit the batch of small files
individually. No luck:

---citation--start

./wiki_references/2017/software/MaidSafe_net/doc/2017_03_21_wget_copy_of_blog_maidsafe_net/bonnet/blog.maidsafe.net/2013/07/25/open-source-more-freedom/index.html?share=facebook.html
contains long lines. Use --no-warnings or the "binary-glob" setting to
disable this warning.
Commit anyhow (a=all/y/N)?
Abandoning commit due to long lines in
./wiki_references/2017/software/MaidSafe_net/doc/2017_03_21_wget_copy_of_blog_maidsafe_net/bonnet/blog.maidsafe.net/2013/07/25/open-source-more-freedom/index.html?share=facebook.html
Push to
http://martin_v...@www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/
Round-trips: 1   Artifacts sent: 0  received: 0
Push done, sent: 1237  received: 334  ip: 185.7.252.74
---citation--end---


P.S. Right after sending my previous Bug report
to this list, like, literally in 10 seconds,
I received a spam email that used my own subject
line with the "Re:" prefix as its email subject.
I suspect that either spam bots have been signing
up to this mailing list or someone, who receives the
mailing lists posts individually in stead of ordering
a Digest is using some crappy, bot-infested, email
service that scrapes email addresses from
all incoming email. I know that it is not me, because
it has not happened to me with other mailing lists or
at least I haven't noticed.

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