Re: [fossil-users] Email notifications content transfer encoding
Hi, On 2018-06-26 at 09:35 -0400 Richard Hipp wrote: >Since Rafal's original inquiry, I have modified the email notification >logic to use quoted-printable instead of base64. Quoted-printable is >not as clean as plain-old 8bit, but it is much more readable than >base64. Acceptable compromise? For me it's perfectly acceptable compromise. I'd like to note however, that for non-latin based alphabets QP has much higher overhead than base64 and is exactly as non-readable. But for latin-based ones it's "good enough" and that's what I'm interested in ;-). Thank you. >On 6/26/18, Rafal Bisingier wrote: >> Hi >> >> Richard asked me to post it on the list for discussion, so here it is: >> The new email notification functionality in fossil use base64 as >> Content-Transfer-Encoding. I personally prefer use of 8bit encoding, >> which have a side-effect of human-readable source of message. I admit >> that it does not matter much in a normal situation (reading the message >> in an email client), but on a few occasions I had to grep/cat through >> mailbox files, and having a readable message body was of great help >> then. That's why I want to submit for consideration using a 8bit >> content transfer encoding for email notifications. Nowadays there are >> practically no problems in transport of such messages. The only down >> side I could think of is that theoretically there is a limit of 1000 >> chars in a line in an email message (and base64 encoding bypasses it). >> But would it really be a bigger problem? >> On the pros there is simplified debugging (no need to decode message, >> which fossil store in his database file in "transport-ready" form - >> so currently with base64 encoded body). Of course DRH already wrote a >> tool to help in this ;-) so it is already doable without much trouble >> https://www.fossil-scm.org/fossil/file/tools/decode-email.c >> Nevertheless I'd like to have a readable source of messages. ;-) -- Greetings Rafal Bisingier ___ 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] fast-import crash (mark not declared)
Hi, On 2017-02-17 at 07:37 -0500 Richard Hipp <d...@sqlite.org> wrote: >On 2/17/17, Rafal Bisingier <ra...@itec.com.pl> wrote: >> >> Out of curiosity: what will happen, when commited parent have timestamp >> far away in future? > >You could move the defective commit onto a branch (a branch named >"mistake" is a popular choice). Or you could change the date on the >defective commit. Thank you for quick answer. Again. ;-) -- Greetings Rafal Bisingier ___ 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] fast-import crash (mark not declared)
Hi, On 2017-02-17 at 07:03 -0500 Richard Hipp <d...@sqlite.org> wrote: >On 2/17/17, Richard Hipp <d...@sqlite.org> wrote: >> On 2/17/17, Rafal Bisingier <ra...@itec.com.pl> wrote: >>> >>> Shouldn't Fossil at least warn user trying to commit a child wit >>> timestamp earlier than parent? >> >> I think it does that, now. > >Confirmed: That fix went in 7 years ago: >https://www.fossil-scm.org/fossil/info/8fdac87b688c3ea0 It's even harder than I proposed - abort instead of warning. Thank you for confirmation. Out of curiosity: what will happen, when commited parent have timestamp far away in future? Do we have to skew our clock to commit a child? Or is there some mechanism to get around it without breaking next commit? -- Greetings Rafal Bisingier ___ 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] fast-import crash (mark not declared)
Hi On Fri, 17 Feb 2017 at 06:07 -0500 Richard Hipp <d...@sqlite.org> wrote: > On 2/17/17, Rafal Bisingier <ra...@itec.com.pl> wrote: > > > > Shouldn't Fossil at least warn user trying to commit a child wit > > timestamp earlier than parent? > > I think it does that, now. The timewarps all happened a while ago. Oh, then sorry for the noise... ;-) -- Greetings Rafal Bisingier ___ 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] fast-import crash (mark not declared)
Hi On Thu, 16 Feb 2017 at 14:15 -0800 Ross Berteig <r...@cheshireeng.com> wrote: > Sure, we'd all love it if everyone kept their clocks in sync, but in the real > world skew is simply going to happen. In the absence of a central server to > provide the authoritative time stamp, a DVCS like both Fossil and Git has no > real choice other than to trust the time provided by each local machine as > authoritative enough to document each commit. > > If commits from each user of a project end up lined up in order on the > timeline, that is just a happy side effect of people keeping their clocks > synchronized. > > Having a parent committed after a child does look odd, but I think it has to > be simply accepted as part of the record, warts and all, of the work on the > project. Shouldn't Fossil at least warn user trying to commit a child wit timestamp earlier than parent? I suppose that in the moment of commit fossil is able to check this two timestamps (system time and ts of parent checkin) and compare it? I'd even say that in case of local time misconfiguration (when commiting child will end up with earlier timestamp than it's parent) it's possible to semi-automagically "fix" this by setting "computed timestamp" a the new commit timestamp. or better by simply executing what "fossil amend --date" do. -- Greetings Rafal Bisingier ___ 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] symlinks (was Re: xkcd on git)
Hi, On 2015-11-05 at 08:18 CET Stephan Beal <sgb...@googlemail.com> wrote: >On Tue, Nov 3, 2015 at 7:59 PM, David Mason <dma...@ryerson.ca> wrote: > >> It's simple: a symlink is a filesystem artifact and should be reflected as >> such in the repository. It should not be followed; if foo is a symlink and >> I say "fs add foo/bar" it should probably give an error. (This might >> surprise people the first time, but it's easy to explain - foo/bar isn't >> part of the repo, regardless of where foo points.) > >But it's not quite that simple, philosophically speaking: we expect Fossil >to extract _exactly_ what we put in it, and that's not portably possible >when it comes to symlinks. As soon as someone checks out your repo on a >non-Unix system, fossil is creating output which you did not put in fossil. >That's a tremendous psychological/philosophical hurdle for me. i'd rather >live without symlinks than know that my repos check out differently >depending on the platform. Thank God there's no DOS port of fossil, or we would end with 8.3 filenames... ;-) Symlinks are sometimes crucial _on_ _unix_, and not supporting them, only because of the existence of Windows port, would be very bad choice. For me it would be better to not have Windows port than symlinks support. Thankfully for others, I'm not a developer ;-) -- Greetings Rafal Bisingier ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
