Re: [fossil-users] clone a repository over ssh where the path includes whitespace characters

[Stephan Beal]

On Thu, Aug 8, 2019 at 10:20 AM Poor Yorick 
wrote:
>
> Hello,
>
> Attempting to clone a repository over ssh where the path contains
whitespace
> characters:
>
> fossil clone 'ssh://user@domain://path/to/directory with
spaces/my.fossil' my.fossil
>
> Various attempts, including percent or plus encoding, all fail.  Is there
some
> incantation that works?

This mailing list isn't used any more. The current support forum is:

https://fossil-scm.org/forum/

That said, i'm going to take a wild guess as to a workaround:

fossil clone 'ssh://user@domain://path/to/"directory with
spaces"/my.fossil' my.fossil

(Note the extra quotes.)

i've no idea if that will really work, though.

-- 
- stephan beal
https://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Different file count after FOSSIL REBUILD --COMPRESS

[Stephan Beal]

On Mon, Apr 8, 2019 at 12:36 AM Tony Papadimitriou  wrote:

> (Apologies if this message appears twice – I’m having some SMTP issues.)
>

This mailing list isn't used any more. The forum is now the preferred
channel:

https://fossil-scm.org/forum


>  I attempted to minimize storage by running “fossil reb --compress” on
> various fossils.  Only one result was unexpected.
> Below is a copy of the db --db-check before and after a REBUILD with
> –-COMPRESS option.  The ‘after’ is counting one file less.
>
> 1. What could be the reason for that (4299 files instead of 4300)?
>

Possibly a shunned artifact.

2. Is there some way to find out which file is missing by comparing to a
> backup?
>

You can use use sqlite's "ATTACH" command to attach both the new and old
DBs and do a SELECT to find the extra blob.uuid entry in the older copy.
There's a CONTENT() SQL function (via fossil's built-in copy of the sqlite
shell) to get the full, uncompressed content of a blob, but it outputs
using sqlite's hex-encoded mode, and i'm not sure how to get it unencoded:

echo "select content('rid:1')" | fossil sqlite3 -R repofile

replacing 'rid:1' with the UUID of the newly-missing artifact.

3. Is it safe to assume (based on the db –db-check command) that the repo
> is not corrupt in any way?
>

Definitely.

-- 
- stephan beal
https://wanderinghorse.net/home/stephan/
<http://wanderinghorse.net/home/stephan/>
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Corrupt database at first commit after a Fossil update

[Stephan Beal]

On Thu, Nov 8, 2018 at 2:15 AM Zoltán Kócsi  wrote:

> Oh. That's really, really sad. I much prefer mailing lists to any web
> based forum.


Most of us do as well, but: bots and spammers are making it ever more
difficult to manage mailing lists. The forum can send you mail
notifications, but replying requires going through the forum. (i don't know
if there are plans to eventually support replies via email.) Unlike the
mailing list, the forum allows anonymous posts, but such posts are always
moderated before they're visible to the public. "So far" we haven't had any
spammers/bots on the forum, but that might be because it's not yet a big
enough target for them ;).

Well, times are a changin'...
>

We have the spammers and their bots to thank for that :/.

-- 
- stephan beal
https://wanderinghorse.net/home/stephan/
<http://wanderinghorse.net/home/stephan/>
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Corrupt database at first commit after a Fossil update

[Stephan Beal]

On Thu, Nov 8, 2018 at 1:13 AM Zoltán Kócsi  wrote:

> I've updated Fossil from 1.29 to 2.7 on the server and on a client. The
> database files on the server were left alone.
>

PS: this mailing list is no longer active. Please use the new forums for
future questions:

https://fossil-scm.org/forum

-- 
- stephan beal
https://wanderinghorse.net/home/stephan/
<http://wanderinghorse.net/home/stephan/>
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Why no EXE+DLL like SQLite?

[Stephan Beal]

On Tue, Aug 7, 2018 at 4:15 PM Donald Griggs  wrote:

> Re:  http://www.tortoisefossil.org/index.cgi/index  "What you'll find
> here is a work in progress  "
>
> Unfortunately, it appears the project is at least on hiatus, if not
> abandoned.  The last code commit in the timeline was in late 2014.
>

That time frame is familiar to me, so i had to check... a couple timeline
entries mention his use of libfossil, and late 2014 was when chronic RSI
knocked me out of my hobby projects (which included libfossil).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Stephan Beal]

If it was that common we would have realized the problem sooner ;).

The problem with generating output for "no changes" is that we potentially
break any automation which relies on an empty diff to mean "no changes".
(That lnly applies to "diff", not gdiff.) That could, i guess, be "fixed"
by adding a --quiet option, suppressing any non-diff output. Something to
consider, in any case.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Sat, Aug 4, 2018, 17:11 Gilles  wrote:

> On 04/08/2018 16:43, Stephan Beal wrote:
>
> That means there are no diffs to show. Try:
>
> fossil gdiff --from prev test.html
>
> That was it.
>
> Grrr, I should have thought about it :-/
>
> I don't know how common this mistake is, but if it, it might be a good
> thing if Fossil said something like "No change."
>
> Thanks much everyone.
> ___
> 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 gdiff" doesn't launch WinMerge; fossil.exe with autocompletion?

[Stephan Beal]

On Sat, Aug 4, 2018 at 4:25 PM Gilles  wrote:

> On 04/08/2018 15:51, Gilles wrote:
> > d:\Temp>fossil gdiff test.html
> >
> > Nothing.
>
> I don't know if it means anything, but incidently, "fossil diff" doesn't
> return anything either:
>
> d:\Temp>fossil diff test.html
>
> d:\Temp>fossil finfo test.html
>

That means there are no diffs to show. Try:

fossil gdiff --from prev test.html

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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's (lack of) use of the Ticket system

[Stephan Beal]

On Sat, Aug 4, 2018 at 12:38 PM Gilles  wrote:

> A lot of "How do I…?" questions can be answered by searching the archives
> of the mailing list :
>
> https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/
>

People don't do that, though. In every support forum in the universe, some
appreciable percentage of posts are asking the same thing which the fellow
3 posts down from them is asking. (The BoardGameGeek forums are _prime_
examples of this.)

Since it's apparently not mentionned currently — I had to google "fossil
> scm mailing list" to find it —, I suggest updating the Docs section of
> www.fossil-scm.org page to add a link.
>

Richard is in the process of replacing the mailing list, so it's unlikely
to get a link on the home page.


> And maybe one day, move the mailing list to a web-based forum entirely so
> that people can post questions directly.
>

That's exactly what Richard is currently implementing. That alone won't
stop the "how do i" posts - it's a Cosmic Rule that many people won't
bother searching a forum (beyond a casual Google effort) before posting
their own (oft-repeated) query. :/.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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's (lack of) use of the Ticket system

[Stephan Beal]

On Fri, Aug 3, 2018 at 8:11 PM Dan Barbarito  wrote:

> I am trying to understand why Fossil itself does not use the built-in
> ticketing functionality. I understand that trolls + spammers may be a
> problem, but can't ticket changes simply be approved/denied? Using the
> ticketing system would give more people the opportunity to understand what
> bugs are being worked on, what features are being added, etc. Having a
> single place to document bugs and feature requests is the best way to see
> the status of a project at a glance. Yes, we have this mailing list and
> soon we will have forums, but I don't think bug reports should reside in
> these places.
>

Fossil used to use its own ticketing system more, but experience showed
that it was simply less hassle to use the mailing list. That certainly
isn't true for all projects. In the majority of cases, reported bugs are
literally not bugs - they're misunderstandings of how to use fossil. A
large portion of the "real bugs" reported often ended up resolved within
hours of someone reporting them on the mailing list, making the
administration via a ticket system more overhead than it was worth. Yes,
there's always that minority of bugs for which tracking them in the ticket
system makes sense, but it simply fell out of fashion to do so.

i see that Richard just answered, so i'll stop there and see what he says
on the topic. If there's any conflict of opinions, he wins, of course ;).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] CMake project for Fossil development using IDE [branch: cmake-ide]

[Stephan Beal]

On Thu, Aug 2, 2018 at 12:59 PM Artur Shepilko  wrote:

> The rationale is to leverage the usual IDE conveninces such as code
> browsing, auto-complete, visual debugger etc. Also, having a Fossil
> source control plugin helps navigating the changes.
>

One forewarning about code browsing: the build process filters the files
under src/, copying them to bld/, which means that if you accidentally
browse (via "symbol-following" features) into bld/*.c and start editing,
any changes will be lost the next time you build. Been there, done that.

Also, many C files under src/ use custom markup (lines starting with @)
which will confuse most C editors (any which do syntax highlighting).
That's only "cosmetic confusion", though - it doesn't break anything.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Backup traffic

[Stephan Beal]

On Fri, Jul 20, 2018 at 10:13 AM Florian Balmer 
wrote:

> I have created a (surprisingly simple) patch to attach a separate
> login cookie database (shared among all repositories in the same
> directory), so that plain login and logout actions will no longer
> cause repository database writes. With admin and user logs turned off,
> and "PRAGMA optimize" removed, the repository database is only touched
> if there's new contents, or new configuration settings.
>
> What's your comments to this? Does anybody care about the repository
> database, holding all your valuable contents, being modified
> frequently with simple non-contents state information?


This behaviour doesn't bother me at all (in 10 years of using Fossil), but
if a patch for working around it is simple and non-intrusive, i would
consider it to be an interesting feature (with the caveat that it might
impact future changes).

i conceptually like the idea of the login cookie/timestamps being in a
separate db, but i'm not sure that i like it enough to justify the idea of
maintaining two files where one file is sufficient. That wouldn't really
impact me much, as i keep all of my hosted .fsl files in one directory, but
for a hoster like chisselapp, where each repo is (probably) in its own
directory, it doubles the number of fossil-related files. One _potential_
problem i see, but it's largely hypothetical, is that the login cookie db
could become a point of locking contention if is used together with many
very active .fsl files. That is probably only possible if several of those
repos are _extremely_ active, though.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Can't believe --branchcolor would be platform-specific

[Stephan Beal]

On Sat, Jul 7, 2018 at 2:12 PM Martin Gagnon  wrote:

> My guess is that on a bash shell, # is the symbol for comments. Try to put
> it in double quotes;
>e.g.:—branchcolor "#f0a0a0"
>

That is definitely what's happening, and it's not bash-specific: every[^1]
Unix-style shell known to man treats an unescaped # as the start of a
comment. An alternate approach, aside from quotes is:

--branchcolor \#f0a0a0


[1] = obviously, since i say "every" in public, someone will now point out
an exception to that rule. That said, i'm not aware of any exceptions.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Segfault on json test

[Stephan Beal]

On Thu, Jul 5, 2018 at 5:38 PM Dingyuan Wang  wrote:

> Hi,
>
> The following test:
>
>   tclsh test/tester.tcl fossil json
>
> fails with:
>
> [...]
> /home/gumble/dev/fossil/fossil json --json-input anon-1
> ERROR: child killed: segmentation violation
>

https://www.fossil-scm.org/index.html/info/f488a5aa97a3b15f

There are still 2 json tests which fail, but i didn't write those and can't
say anything useful about them :/. The segfault is resolved, in any case.

Thanks for the report!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Segfault on json test

[Stephan Beal]

On Thu, Jul 5, 2018 at 5:38 PM Dingyuan Wang  wrote:

> The following test:
>
>   tclsh test/tester.tcl fossil json
>
> fails with:
>

i believe the fix is simply:

[stephan@host:~/fossil/fossil]$ f diff
Index: src/cgi.c
==
--- src/cgi.c
+++ src/cgi.c
@@ -211,11 +211,12 @@
   const char *zValue,   /* Value of the cookie.  Automatically escaped */
   const char *zPath,/* Path cookie applies to.  NULL means "/" */
   int lifetime  /* Expiration of the cookie in seconds from now */
 ){
   char *zSecure = "";
-  if( zPath==0 ){
+  if(!g.isHTTP) return /* likely JSON CLI mode */;
+  else if( zPath==0 ){
 zPath = g.zTop;
 if( zPath[0]==0 ) zPath = "/";
   }
   if( g.zBaseURL!=0 && strncmp(g.zBaseURL, "https:", 6)==0 ){
 zSecure = " secure;";


but i need to test more before committing.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Markdown wiki relative links

[Stephan Beal]

i don't _think_ that you can use %2f in a path component and have it apply
different semantics than a slash. How would software know to differentiate
between the two? That would be similar to expecting a local file name of
a\/b to work. (If it did work, it would cause no end of confusion.)

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Wed, Jul 4, 2018, 23:26 Andy Goth  wrote:

> On 07/04/18 16:01, Stephan Beal wrote:
> > Fwiw, a few years back i created a patch which caused generated wiki
> > links to always emit wiki/x rather than name=x, but it was pointed out
> > to me that wiki/x doesn't work when x contains a slash, which is a valid
> > wiki page name character. Thus the portable approach is to use name=x. :/
>
> Well, I totally forgot slashes could be in page names.  What about %2f?
>
> --
> Andy Goth | 
> ___
> 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] Markdown wiki relative links

[Stephan Beal]

Fwiw, a few years back i created a patch which caused generated wiki links
to always emit wiki/x rather than name=x, but it was pointed out to me that
wiki/x doesn't work when x contains a slash, which is a valid wiki page
name character. Thus the portable approach is to use name=x. :/

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Wed, Jul 4, 2018, 22:54 Andy Goth  wrote:

> To create a link in the Markdown wiki, the syntax is [like this](url).
> That's all well and good, but what precisely does url need to be for one
> page to link to another?  In writing embedded documentation, I've gotten
> used to relative paths, so in order to link /doc/trunk/doc/foo.md to
> /doc/trunk/doc/bar.md, I write (bar.md).
>
> However, with the wiki, there's an issue.  Most (if not all) of the
> links into the wiki use the ...?name=page syntax rather than the
> theoretically equivalent .../page syntax.  This throws off relative
> paths entirely.  Relative links between wiki pages will be different
> depending on which "equivalent" syntax was used to access the wiki.
>
> Suppose wiki page foo wants to link to wiki page bar.  If foo was
> accessed as wiki?name=foo, then it must link to (wiki?name=bar) or
> (wiki/bar).  But if foo was accessed as wiki/foo, it must link to (bar),
> which it what I hoped would work all along.
>
> To make intra-wiki links work regardless of which syntax is used to
> access the wiki, it appears it's necessary to use "absolute" (actually
> relative to the project root) paths: (/wiki?name=bar) or (/wiki/bar).
> This is not something I've had to deal with (yet?) when doing embedded
> documentation.
>
> My preference would be for Fossil to never send the name query parameter
> to the user.  If a name query parameter is received from the user, I
> think maybe Fossil should not call the webpage function (other than
> confirming that one exists) and instead immediately send a 301 Moved
> Permanently back to the user to rewrite the URL to use /.
>
> Or maybe I'm missing something fundamental here.
>
> There's one other style of relative link I'll mention: (?name=bar).
> This replaces the name query parameter.  I don't think this would work
> very well if linked from /wiki/foo.  Also it gets even weirder when
> clicking a link in the preview shown by wikiedit, since it takes the
> user to the editor for the target page.  But this last would still occur
> should we replace all ?name= with /.  To avoid that, the link would have
> to be either (/wiki/bar) or (../wiki/bar), though of course that last
> one combines the worst of all worlds.
>
> For now, I'll make sure all my wiki links are to /wiki/whatever.
>
> Note: I'm talking about Fossil version 83e3445f67 (2.1), since that's
> what Chiselapp uses.
>
> --
> Andy Goth | 
> ___
> 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] `unversioned' questions

[Stephan Beal]

On Tue, Jun 26, 2018 at 5:45 PM  wrote:

> ​Can unversioned files respect their original paths when added?
> I have several locations for bitmaps, icons, pdf's, etc.
> They do not necessarily reside in an isolated folder.​
>

That wouldn't work cross-platform. You might store file the C:\D\e\f.txt

which i could not extract on Unix because we don't have drive letters. If
we ignore the C: part, i still couldn't extract to /D/e/f.txt, unless i was
the root user. Case sensitivity is another problem in that regard. If you
store C:\D\e.txt and C:\d\e.txt, those would map to two different folders
on Unix systems.

Likewise, Unix /a/b/c.txt has no direct mapping on Windows (which drive
should it use?).

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

On Mon, Jun 25, 2018 at 2:30 PM Warren Young  wrote:

> On Sun, Jun 24, 2018 at 4:48 PM, Stephan Beal 
> wrote:
>
>> Isn't adding hundreds (literally) of gotos just as fraught with
>> opportunities for failure ;)?
>>
>
> #ifdef LIBFOSSIL
> #  define FOSSIL_EXIT(n) longjmp(blabla)
> #else
> #  define FOSSIL_EXIT(n) exit(n)
> #endif
>

Yeah, i was exaggerating, but still... i think the required effort is being
underestimated by at least an order of magnitude. That said: i would
_absolutely love_ to be proven wrong.

$ sed -i -e 's/exit(/FOSSIL_EXIT(/g' src/*.c
>

i recommend a slight variation:

perl -i -pe 's/\bexit\(/FOSSIL_EXIT(/g' src/*.c

sed probably also has a \b (at-word-boundary) equivalent, but i'm not as
well-versed in that flavor of regex.

Sidebar: i once corrupted a fossil checkout db by using $(find . -type f)
as my target for some perl -i-style refactoring :|. Never perlify your
sqlite db files.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

On Sun, Jun 24, 2018 at 11:19 PM David Mason  wrote:

> I really don't understand the reticence to use setjmp/longjmp to turn all
> of these short-cut exits into library return-to-API trampolines.  It
>

To be clear: that's my reticence, not Richard's. libfossil was always
effectively a third-party effort which had Richard's blessing.

My aversion to setjmp/longjmp is that they're effectively global gotos, and
gotos, except in very tightly-controlled circumstances, quickly produces
spaghetti messes.

would allow you to retain all the existing fossil codebase.  Rewriting the
> code into library form is an interesting project, but it seems like a huge
> amount of work and unless Richard is going to change fossil to use the API,
> it is also going to be a huge ongoing maintenance nightmare and fraught
> with opportunities for failure.
>

Isn't adding hundreds (literally) of gotos just as fraught with
opportunities for failure ;)?

It's a few dozen lines of code (in addition to the actual API interface
> code).  Sure seems like worth the experiment to me!
>

i'll go make some popcorn :).

(To be fair: my [strong] aversion to that solution isn't intended to imply
that you can't pull it off. My journey with libfossil was always _at least_
as much about reimplementing it "cleanly" as it was about getting it
running at all. Without the former, the latter would have been, at best, a
hollow success.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] No rule to make target 'src/email.c', ...

[Stephan Beal]

Richard just fixed that moments ago - update again and it will work.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Wed, Jun 20, 2018, 22:02 Sergei Gavrikov 
wrote:

> [FYI]
>
>$ f info
>project-name: Fossil
>...
>project-code: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
>checkout: 25eafed11494e801c28babfbc5784f877c3aa0b7 2018-06-20
> 19:04:04 UTC
>parent:   9a2e5f47170b4f2d86e23c1b2cb37d5b284e7982 2018-06-20
> 18:47:46 UTC
>tags: trunk
>comment:  Add a new capability that allows signup for email
> notification.
>  Change the name of the older "EMail" privilege to
> "View-PII" to
>  avoid confusion. (user: drh)
>check-ins:11308
>
>$ make distclean && ./configure --quiet && make -s
>rm -rf bld/* fossil
>rm -f autoconfig.h config.log Makefile
>make: *** No rule to make target 'src/email.c', needed by
> 'bld/email_.c'.  Stop.
>
> --
> sg
> ___
> 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] A fossil library

[Stephan Beal]

On Tue, Jun 19, 2018 at 8:13 PM Sam Putman  wrote:

>
>>
>>> I got the sense from the docs that the hash is using the SQLite style
>>> versioned API, so it follows that
>>> the old hash code is sitting where it needs to.
>>>
>>> Does this amount to following the style of that file for another similar
>>> file in fossil(1)?
>>>
>>
>> i'm not clear what you mean :|.
>>
>>
> I'm sure that could have been more clear.
>
> Did some poking around between fossil and libfossil, it looks like they
> both have a sha-1.c,
> the difference starts with the copyright, 2006 vs 2013.  A cursory scan
> suggests that the ~200
> line difference is more tests, and some framework code that presumably
> libfossil doesn't need.
>
> fossil also has sha1-hard.c (let's ignore this for now?) and sha3.c.
>
> I haven't yet found where in libfossil sha-1.c is called, and what the
> substantive differences
> are between the two.  What I'm wondering is, can the wrapper for sha-1.c
> be rewritten to also
> wrap sha-3? Possibly sha1-hard as well, if it's on a critical path.
>

A few of the utility classes (most notably sha1 and md5) were originally
copied over 1-to-1 and renamed to match the libfossil project conventions.
sha1-hard and sha-3 came along after my RSI fallout, and are not included
in libfossil. i have _no_ idea what the differences are between sha1 and
sha1-hard, so can't comment on those. The buffer sizes differ between sha1
and sha-3, so i'm not sure whether those two could be reasonably/cleanly
combined. i have to resist the temptation to go poking around in the code
rabbit hole, as that almost invariably leads to days of hand pains :(.
(Software development was always like a drug to me, and i am very much a
recovering addict.)

I know there's some wrinkles around how fossil picks a sha that allowed for
> the transition, I'm
> content with being able to wield those sha functions in a fossil context
> at a fairly low level, for now.
>

It "should" be trivial to port the core sha1-hard and sha-3 to libfossil -
porting of sha1 and md5 was literally a copy/paste/rename job. However, the
assumption that SHA1 is "the" hash is "strongly embedded" in many places in
libfossil (md5 is only used in the manifest files and its usage does not
need to be modified/extended). It "should" be simple to find all such
places by grepping for FSL_UUID_STRLEN (defined in
include/fossil-scm/fossil-hash.h), and porting all such places to support
variable hashes is, AFAIK, the only critical piece needed for making
libfossil compatible (again) with fossil(1). If that hurdle can be
surpassed, the rest is "easy" (even the merging - it simply needs to be
ported over from fossil, adapting the API to a library interface along the
way).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Are commits with "a lot" of small files still an issue?

[Stephan Beal]

On Tue, Jun 19, 2018 at 7:56 PM Martin Vahi  wrote:

> The reason, why I write the current letter
> is that IF the insertion of large amounts of
> very small files is still an issue, then
> there would be an opportunity to fix it
> before anybody reports the issue.
>

i think we're all curious what you mean by (1) "large amounts" of files
(hundreds, thousands, tens of thousands?) and (B) "is still an issue"?

Have you had problems importing hundreds or thousands of small files? And
what were the problems?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

On Mon, Jun 18, 2018 at 7:18 PM Sam Putman  wrote:

> A Capitalized pure-C struct being referred to as an object is not unheard
> of! But it did lead me down
> the wrong path.
>

Here's my little contribution to spreading the word about OO in C:

http://www.wanderinghorse.net/computing/papers/DoingOOInC.pdf

:)


> I got the sense from the docs that the hash is using the SQLite style
> versioned API, so it follows that
> the old hash code is sitting where it needs to.
>
> Does this amount to following the style of that file for another similar
> file in fossil(1)?
>

i'm not clear what you mean :|.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

On Sun, Jun 17, 2018 at 11:11 PM Sam Putman  wrote:

> On Sun, Jun 17, 2018 at 6:39 AM, David Mason  wrote:
>
>> Just had a quick thought that might make the conversion to library much
>> easier.
>>
>> If you have a relatively small API interface, each of the API functions
>> could do a setjmp https://en.wikipedia.org/wiki/Setjmp.h
>>
>
>
This is the kind of approach I glossed over as a "goto cleanup", so we're on
> the same track here.
>
> I haven't had a chance to go over some of the core C files in libfossil
> yet,
> curious to what degree it follows this pattern already.
>

i have to admit that you lost me at setjmp. There are certain C APIs which
i won't touch unless absolutely forced to, and setjmp/longjmp belong to
that category. gotos are widely used in libfossil to simplify error
handling/deallocation within a given function.

In libfossil, all error state is propagated as an integer, with some cases
providing additional information in an Error object owned by the Context
object (each Context manages, at most, one opened repo instance). The API
docs describe, where relevant, which result codes must be considered
fatal/unrecoverable (allocation error being the primary case). An example
of propagating more information is SQL query preparation failure - the
error string from sqlite would be propagated back up via the Context's
Error object. An allocation error, on the other hand, is simply returned as
the enum entry FSL_RC_OOM, as we can't provide more information for that
case without more allocation (which would presumably fail).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

On Sun, Jun 17, 2018 at 11:07 PM Sam Putman  wrote:

> About those objects...
>
> What your docs call fossil(1) is written in plain C. Or rather C, Tcl, SQL
> and TH1, if you prefer.
> In any case, not C++.
>

liubfossil is 100% C89 except that it requires "long long" because sqlite3
requires it. long long is not strictly C89 but all compilers supports it.
The C++ code in the tree is simply optional high-level wrappers, intended
primarily to allow me to "exercise" the core API, to make sure that it
would be useful in other contexts.


> I'm still pretty convinced the work on libfossil won't go to waste.
>

> The excellent documentation alone has advanced my understanding
> considerably.
>

:)


> What might make sense is a sort of 'parallel construction'. Nice thing
> about a revision control
> system, it's got all the revisions.
>
> So to write a clean C libfossil, we can start with the first commit and
> follow the breadcrumbs.
>

The only "problem" with that (for a given definition of "problem") is that
i'm rather chaotic in terms of how i work on code: there's little rhyme or
reason, nor any specific ordering to commits or (for the most part)
features. You won't find any reasonable order to the timeline. The
implementation required, of course, certain features before others, though,
so... there is that.


> I don't think it's strongly tied to the patch-centric model, it's a
> (relatively) simple matter of
> representing possible outcomes as distinct states.  There might be some
> potentially
> exponential bad behavior, we are talking about permutations after all.
>

It might even be feasible to store each such variation in the 'stash' table
(llibfossil never got far enough to implement the 'stash' or 'undo' parts,
as both depend on the merge process, which was the final "big/scary" hurdle
left to port).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Backups of deconstructed fossil repositories

[Stephan Beal]

On Sun, Jun 17, 2018 at 10:08 PM Warren Young  wrote:

> On Jun 17, 2018, at 2:05 PM, Warren Young  wrote:
> >
> > If you’re willing to gamble that if the first test returns true that the
> second will also returns true, it buys you a big increase in speed.  The
> gamble is worth taking as long as the files’ modification timestamps are
> trustworthy.
>
> I just remembered something: “fossil up” purposely does not modify the
> mtimes of the files it writes to match the mtime of the file in the
> repository because it can cause difficult-to-diagnose build system errors.
> Writing changed files out with the current wall time as the mtime is more
> likely to cause correct builds.
>

To that i'm going to add that fossil doesn't actually store any file
timestamps! It only records the time of a commit. When fossil is asked
"what's the timestamp for file X?", the answer is really the timestamp of
the last commit in which that file was modified.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Change textarea for textnotes to placeholder text

[Stephan Beal]

On Sun, Jun 17, 2018, 15:26 Zack Scholl  wrote:

>
>
> [1]: https://www.w3schools.com/tags/att_textarea_placeholder.asp
>
> [2]:
> https://www.fossil-scm.org/index.html/artifact?udc=1=on=5d4a12252f765b5a
>

Just fyi: the ln= param accepts both a single line number or range of lines
(e.g. ln=20-30):

https://www.fossil-scm.org/index.html/artifact?udc=1=544=5d4a12252f765b5a

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.
___
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] A fossil library

[Stephan Beal]

 type of merging decisions which are made during, e.g., a
checkout). Speaking of merging: that's often an interactive process, and
interactivity is difficult to define in a UI-ignorant library.


> The one area of fossil I've done enough reading into to feel comfortable
> in my understanding is the
> file format itself. There's an edge to the documentation and I'm kinda
> peering over that edge slightly.
>

The "artifact format" documentation is really Fossil's heart. All of the
other parts are implementation details for supporting that. Nonetheless,
any port will certainly want to take advantage of as many of those details
as possible (much of fossil's "heavy lifting" is done with sqlite, and
reimplementing many of those pieces without sqlite would be a massive
undertaking).

i would be thrilled to see someone implement a library for fossil, but
>> anyone doing so needs to understand, in advance, that it's a large
>> undertaking.
>>
>>
> I'm happy to sign contribution agreements and otherwise smooth the way to
> collaborating on this.
>

None are needed if you just want to access to libfossil (initially they
were, but that requirement was later dropped). If you'll send me your
preferred user name off-list i'll get it set up.

Thanks again, Stephan.  I'll be looking into those links, please don't feel
> as though a back-and-forth on each
> email is necessary, whatever is comfortable for you.
>

My hands have "good days" and "bad days", but today's relatively good. In
any case, every now and then i have to sit down and type for a while just
to see if my hands can take it.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

On Sat, Jun 16, 2018 at 12:07 PM Stephan Beal  wrote:

> libfossil had essentially all of the core-most functionality
> running (documented, too)
>


http://fossil.wanderinghorse.net/repos/libfossil/doxygen/

Ah, those were the days... (i actually _miss_ documenting software.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

On Sat, Jun 16, 2018 at 12:46 AM Stephan Beal  wrote:

> i will write a longer response when i'm back on the PC, but short version:
>
> - refactoring to a lib is a huge effort.
> ...
> More details upcoming about that first point in the morning.
>

So...

http://fossil.wanderinghorse.net/r/libfossil

that's now effectively defunct, though, as i've been on medical leave for
RSI most of the past 3.5 years and am currently on track to be forced
into early retirement within the next couple of months.

Several aspects of fossil make it very tedious (but not difficult, per se)
to port to a library:

1) it uses a great deal of global state. That's simple enough to factor
into a Context object, but...

2) it relies on a fail-fast-and-fail-loud allocator. Any allocation error
will immediately (intentionally) crash the app. While that saves literally
half (sometimes more) of code/error checking any place where memory is
allocated (that's a lot of places), that pattern is unusable for libraries.
Granted, allocation errors are rare, but every single C call which
allocates has to check for failure or risk Undefined Behaviour. To simplify
the vast majority of the implementation, Fossil does this checking in a
single place and abort()s the app if an allocation fails.

3) Fossil effectively uses exit() to handle just about any type of
non-allocation error. i.e. there's little library-friendly error handling
in fossil.

4) Last but not least: Fossil implements a great many intricate algorithms
which, if not ported 100% perfectly, could lead to all sorts of Grief, some
of it difficult to track down. Such ports typically require 2x as much
code, sometimes more, because of the addition of error checking and
handling (as opposed to using abort() and exit()).

libfossil had essentially all of the core-most functionality running
(documented,
too) when RSI knocked me out, and was mainly missing network-related
functionality. It took, according to the timeline, about 16 months to get
it to that point (noting that i also worked on other projects at the time,
so that's not "16 months of effort"). My plan was to pick it back up when
my RSI problems passed, but whether they will is now an open question. In
the mean time, the SHA-related changes have made libfossil incompatible
with fossil, meaning that it would be much more difficult to get it back up
and running.

i would be thrilled to see someone implement a library for fossil, but
anyone doing so needs to understand, in advance, that it's a large
undertaking.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] A fossil library

[Stephan Beal]

i will write a longer response when i'm back on the PC, but short version:

- refactoring to a lib is a huge effort.

- up until late 2014 i was actively working on a library port and had most
of the core features working.

- RSI struck me down and has since effectively removed me from the
programming world, so libfossil has remained unmaintained and is not longer
compatible since the addition of non-SHA1 hashes (and i have no estimate
for what it would take to bring it up to date).

More details upcoming about that first point in the morning.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Fri, Jun 15, 2018, 22:26 Sam Putman  wrote:

> First post. Hi!
>
> I've been lurking along, following the discussion here.
>
> Common thread is a desire for 'more fossil'. I'm in this camp myself.
>
> But I see the attraction of the core fossil application. It works perfectly
> for a fairly close-knit community, and it follows a philosophy that's been
> working for decades now. One that is, if anything, more effective as it
> becomes less fashionable.
>
> Let me make a suggestion: what we need is not more fossil, it is less
> fossil.
>
> I wrote Dr. Richard Hipp about this earlier, his response was positive
> enough
> that I felt encouraged to bring it to the community.
>
> For my own projects, I've switched to fossil. It's the obvious choice,
> we're
> using SQLite in preference to the old pile o' files already.
>
> The fossil codebase has all the core algorithms for storing deltas in a
> single database file, merging, deduplication, Merkle hashing, key signature
> management, extensible metadata... I don't have to sell you on the virtues
> of this VCS!
>
> I would benefit greatly from being able to use this excellent collection of
> SQLite best practices and algorithms, the same way I use SQLite: as a
> static
> or linked library, one which can be wrapped in various FFIs for VMs, or
> linked
> directly from a systems language.
>
> My own case would call this from LuaJIT, what matters is everyone can be
> happy.  fossil proper can stay attuned to the SQLite/Tcl/Tk alliance, as it
> should, and adventurers could wire it to mailing lists, wikis, forums.
>
> I think this would help fossil really stand out.  Just the fact that here
> we
> have tools to read and write git to a single-file database, that's huge!
>
> Tools for revision control would be a real boon to applications already
> using
> SQLite as an AFF. I could go on.
>
> I always feel some trepidation towards what amounts to asking other people
> for
> free work. I feel this refactoring could benefit fossil as well as my own
> software. I'd be a part of such an effort as soon as anything halfway
> plausible
> was compiling, if invited.
>
> Sincerely,
>
> -Sam Putman
> --
> Special Circumstances
> ___
> 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] Perception of Fossil

[Stephan Beal]

On Thu, Jun 14, 2018 at 10:51 PM Ron W  wrote:

> In another forum I follow,a commented claims that Fossil is designed for
> "cathedral development" not "bazaar development", so would be of little
> interest to anyone. Unfortunately, the poster did not elaborate on why.
>

Maybe he's just young and full of beans.

Maybe he's equating "bazaar" with one of its more extreme implementations,
"github". Or maybe he's not aware of the scope of the term "bazaar", which,
n this context, predates all DVCSs that i can find record of via:

https://en.wikipedia.org/wiki/Distributed_version_control#History

That term was already in use by the time ESR popularized it[^1], at a time
when CVS (centrally administered, like Fossil) was still king.

[1] = https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Bug in /finfo not showing Deleted anymore.

[Stephan Beal]

On Wed, Jun 13, 2018 at 6:17 PM, Stephan Beal  wrote:

> On Wed, Jun 13, 2018 at 5:12 PM, Richard Hipp  wrote:
>
>> On 6/13/18, Svyatoslav Mishyn  wrote:
>> > (Wed, 13 Jun 08:49) Andy Bradford:
>> >> I haven't  had the time to  investigate further, but it  seems that
>> with
>> >> this  commit, the  /finfo  timeline no  longer shows  when  a file
>> gets
>> >> Deleted:
>> >>
>> >> http://www.fossil-scm.org/index.html/info/4c268999d5
>> >
>> > I've reported it before:
>> > https://www.mail-archive.com/fossil-users@lists.fossil-scm.o
>> rg/msg27146.html
>>
>> I'm tied up with a mailing-list infrastructure issue, so if you can
>> suggest a patch, that would be helpful.
>>
>
> This is very possibly closely related to the recent json patch which
> restored missing files in its timeline:
>
> http://www.fossil-scm.org/index.html/info/cd55efe7754dd7e5
> http://www.fossil-scm.org/index.html/info/4c268999d5
>
> Notice how the current UUID is SELECTed in each (previous and current
> versions: that section of code in the 2 links above is essentially
> mirrored).
>

Now i'm not so sure: the finfo change removes the subselect (which is
working on /json/timeline/checkin) into part of the join, which looks
correct to me. The json change switched the join to a left join, though, to
pick up the deleted files.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Bug in /finfo not showing Deleted anymore.

[Stephan Beal]

On Wed, Jun 13, 2018 at 5:12 PM, Richard Hipp  wrote:

> On 6/13/18, Svyatoslav Mishyn  wrote:
> > (Wed, 13 Jun 08:49) Andy Bradford:
> >> I haven't  had the time to  investigate further, but it  seems that with
> >> this  commit, the  /finfo  timeline no  longer shows  when  a file  gets
> >> Deleted:
> >>
> >> http://www.fossil-scm.org/index.html/info/4c268999d5
> >
> > I've reported it before:
> > https://www.mail-archive.com/fossil-users@lists.fossil-scm.
> org/msg27146.html
>
> I'm tied up with a mailing-list infrastructure issue, so if you can
> suggest a patch, that would be helpful.
>

This is very possibly closely related to the recent json patch which
restored missing files in its timeline:

http://www.fossil-scm.org/index.html/info/cd55efe7754dd7e5
http://www.fossil-scm.org/index.html/info/4c268999d5

Notice how the current UUID is SELECTed in each (previous and current
versions: that section of code in the 2 links above is essentially
mirrored).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 binary file size on FreeBSD (amd64)

[Stephan Beal]

Try stripping the debug symbols:

strip fossil

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.


On Mon, Jun 11, 2018, 07:55 Florian Balmer  wrote:

> When building Fossil on a recent out-of-the-box FreeBSD (amd64)
> virtual machine, the resulting binary file is about 10.1 MB. The
> binary files downloaded form [0] are at most 3.8 MB.
>
> [0] http://pkg.freebsd.org/
>
> I have tried various ./configure options, FOSSIL_DYNAMIC_BUILD is
> enabled (=1), and TCL seems to be disabled by default (or, is it?).
>
> Not that it matters (these times are over), but out of curiosity, why
> is there such a difference?
>
> --Florian
> ___
> 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] Show time...

[Stephan Beal]

On Tue, Jun 5, 2018, 23:19 Stéphane Aulery  wrote:

>
> Barely one day and I have already received this link [1] by Hacker News
> RSS feed.
>
> Maybe you can make your advocacy here.
>
> [1] https://tutswiki.com/github-alternatives/


Which reminds me: i saw an ad on SourceForge (remember them? The first
platform of its kind?) offering git sync from github.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.
___
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] Repository reports as JSON

[Stephan Beal]

On Tue, Jun 5, 2018, 19:03 Offray Vladimir Luna Cárdenas 
wrote:

> Hi,
>
> I would like to have access to the activity reports information in JSON
> format. I know that the json interface is enabled and that is mostly
> used by preceding the usual url by the "json/" command (see for example
> [1]), but for some reason I can not get any output for several commands
> like json/timeline or json/reports in my Fossil repositories. What I'm
> missing? Is reports activity available as JSON data?
>
> [1] http://mutabit.com/repos.fossil/dataweek/json/dir?ci=tip


The timeline requires that you tell it which timeline you want, e.g.:

http://mutabit.com/repos.fossil/dataweek/json/timeline/checkin

For the full json API docs, see:

https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/edit?usp=drivesdk

The reports are not currently available in json. That would not be
difficult to implement but i am still on years-long medical leave for
severe chronic RSI (from too much programming/documenting) and can't
implement it myself :(.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.
___
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] Rumor: Microsoft has acquired github

[Stephan Beal]

On Mon, Jun 4, 2018 at 2:08 AM, Jan Danielsson 
wrote:

> On 2018-06-04 00:35, Stephan Beal wrote:
> [---]
> > It does kind of make sense: the global leader in creating
> > market-leading-yet-unusable software acquires one more piece of
> > market-leading-yet-unusable software.
>
>This appeals to my sense of order.  :)
>

Though, to be fair: github goes to great lengths to make git usable, but
with a piece of software so thoroughly misanthropic as git, one can only do
so much.

We'll supposedly find out "on Monday" whether this rumor is true. It's
already Monday in my timezone, but the news outlets don't seem to care
about non-US timezones :/.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Rumor: Microsoft has acquired github

[Stephan Beal]

This is currently just a rumor, but a juicy one which should interest some
Fossil users:

https://www.theverge.com/2018/6/3/17422752/microsoft-github-acquisition-rumors

It does kind of make sense: the global leader in creating
market-leading-yet-unusable software acquires one more piece of
market-leading-yet-unusable software.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] JSON timeline missing deleted files?

[Stephan Beal]

On Tue, Mar 13, 2018 at 5:17 PM, Stephan Beal  wrote:

> suggests that it "looks okay". However, a quick local test also shows that
> a removed file is indeed not reported. The first suspect is the related
> query:
>
> https://www.fossil-scm.org/index.html/artifact/5a9ce59def16a55b?ln=323-332
>
> i don't recall (it's been far too long) whether or not that catches
> deleted files, nor how to make it do so if it doesn't. Anyone wanting to
> look into it should start there, though.
>


i was sent an off-list fix for this today by Edgardo Cruz, which is now in
trunk:

http://www.fossil-scm.org/index.html/info/cd55efe7754dd7e5

Here's an example of the output for deleted files:

  {
"type":"checkin",
"uuid":"77b624ba022fbd2c832cc0103e8b0c8fb2610d46",
...
"comment":"removed a long-obsolete file.",
"files":[{
"name":"include/wh/cwal/cwal_list.h",
"parent":"7548ada2f5007797846125812424c5ae49192a1f",
    "size":0,
"state":"removed",
"downloadPath":"/raw/include/wh/cwal/cwal_list.h?name="
  }]
  },


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Purging attachments

[Stephan Beal]

On Thu, May 31, 2018 at 10:51 PM, Eugene MIndrov 
wrote:

> Now, if it was against the implementation then it wouldn't have been
> implemented, right?
>

It was implemented only as a last resort, not for daily use. The very real
use case that "needs" to be supported by this feature is that someone
commits copyrighted material into someone else's repo. if i were to make a
copy of copyrighted ebook and post it as an attachment to someone's fossil
wiki, the owner of that wiki _needs_ (for legal reasons) to be able to
banish it. Shunning was not one of Fossil's original features - it was
added to enable that sort of worst-case scenario.


> The main reason I haven't used shun for my purposes is the attachment I
> was trying to nuke was taking 90% of the entire repo and shun leaves
> shunned artifacts lying around, just adding their SHA into the shun list so
> they would be excluded from sync operations.
>

That's not true: see the very first sentence the documentation of the shun
page:

"A shunned artifact will not be pushed nor accepted in a pull and the
artifact content will be purged from the repository the next time the
repository is rebuilt."

You simply need to rebuild the repo after shunning. That won't eliminate it
from any closes, but it will keep them from re-synching it back to your
copy.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Purging attachments

[Stephan Beal]

On Thu, May 31, 2018 at 8:03 PM, Миндров Евгений 
wrote:

> Well, now I'm in a situation which has been discussed here many times - I
> need to "unmake" certain file attachment from a repo, make it look like it
> had never been there.
>
> I know it goes against the core values of Fossil philosophy and it's akin
> to replacing all fossilized trilobite remains in Paleozoic strata with
> Oreos so paleontologists would scratch their heads, but anyway.
>

It's not just against the values, it's against the implementation!

There is only one way to nuke data in fossil, and it should only be used as
a last-resort option, not in day-to-day maintenance. (i've been using
fossil since Christmas of 2007 and have never once used this feature.)

fossil help purge

provides these warnings:

 WARNING: This command can potentially destroy historical data and 
 leave your repository in a goofy state. Know what you are doing!  
 Make a backup of your repository before using this command!   

 FURTHER WARNING: This command is a work-in-progress and may yet   
 contain bugs.


i.e. don't use that feature ever unless you know for a fact that you
absolutely need to.

Instead, you "want" (but don't REALLY want) the shun feature. It's only
accessible in the UI under the Admin pages (the URI is /shun). You enter
the UIDs of the artifacts to shun and it will permanently remove them from
your repo. Be sure to read the documentation on that page.

PS: you _really_ don't want to remove data from your repo unless someone
checked in a password, private SSH key, something copyrighted by someone
else, or similar cases.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 delete user

[Stephan Beal]

On Tue, May 15, 2018 at 4:59 PM, Peter Vonča <pvo...@gmail.com> wrote:

> I understand, how about anonymization then. User "Jane" is deleted.
> Replace all references with default user "Anonymous".
>

Another point to consider is that fossil does not synchronize user
information unless it's explicitly told to. e.g. when i pull a copy of the
main Fossil SCM repository, it does not copy the users "drh", "jan", etc.
etc. Those users exist only as entries in commits (in "manifests", to use
the official Fossil terminology). The central repo can add any number of
users, but my local copy doesn't know them as users - it only knows them as
static strings in commit entries.

In short: what you're asking for is, by design, not possible in Fossil. (i
don't _think_ it's possible in any SCM, for that matter, but i _know_ that
it's not possible in Fossil.)


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 delete user

[Stephan Beal]

Anonymization is not possible because the user name is part of each commit
entry, which means that it affects the hash code of each commit. Changing
any data in a commit, including the user name or timestamp, would change
the hash, and thereby invalidate every commit which derived from that.
Fossil, by design, cannot modify historical data.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Tue, May 15, 2018, 16:59 Peter Vonča  wrote:

> I understand, how about anonymization then. User "Jane" is deleted.
> Replace all references with default user "Anonymous".
>
>
>
>
> On Tue, May 15, 2018 at 12:41 PM, Victor Wagner 
> wrote:
>
>> On Tue, 15 May 2018 12:34:07 +
>> Peter Vonča  wrote:
>>
>> > Is there a practical reason why users can't be deleted or was it just
>> > a design decision? I guess if I stop fossil server I can manually
>> > edit the sqlite db and delete from table?
>>
>> Fossil keeps history forever. How would it do so, if author of some
>> commits or wiki edits disappears from the repository completely.
>>
>> Disable access, revoke privileges, but keep the user in the DB,
>> because it has log of his activity.
>> --
>> ___
>> 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
>
___
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] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?

[Stephan Beal]

On Sat, May 12, 2018 at 5:35 PM, Chris Drexler <ckolum...@ac-drexler.de>
wrote:

> Does this make sense? At least from a workflow perspective?
>

Personally, i don't think so ;), but i tend to be admittedly pessimistic
when it comes to "oddball setups".

How do you expect to sync changes with such users? How do you expect to
handle multiple copies of the binary (i.e. multiple copies of the repo) on
each user's machine? At some point they'll overwrite one fossil bin with
another one, thereby losing any changes they had made to the first.
Upgrading the binary should not destroy any associated data, and that's
exactly what will happen if all users aren't 100% careful with their copies
of the binary.

If it's truly static and users only have read-only access to the data, then
it's far simpler for them to forego the binary altogether and use
http://your-IP to connect to a central copy running on your workstation.

"Can of worms" is what immediately comes to mind. An interesting idea, i
admit, but "can of worms" trumps "interesting" for me.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] [Q] Possibility to use SQlite Feature "Append VFS" with fossil?

[Stephan Beal]

On Sat, May 12, 2018 at 1:51 PM, Chris Drexler <ckolum...@ac-drexler.de>
wrote:

> Thoughts? If someone could hint me at the right place within the
> fossil code I could also try to provide an implementation.
>

IMO: every clone would not have that feature, so it would seem (to me) to
be of limited use. The only benefit would be that you only have 1 file,
instead of 2, to copy to the remote server. (If you build your binary on
that server, even that benefit is lost.) If your server is upgraded in a
way which becomes incompatible with your fossil binary (incompatible SSL
upgrade or (possibly) libc upgrade), you're hosed: the repo is then locked
inside a binary file which other fossil binaries cannot read. (i've had
hoster-side OS upgrades break my CGI binaries before, though i don't think
i've seen it happen to my fossil binaries.)

Another point to consider: the binary itself would have to be writable by
the web server process, which opens up a potential security hole. In my
experience, Apache runs CGI scripts as the account holder (as opposed to
some generic 'www' user), and that account holder already has write access
to the binary. However, i make my CGI bins read-only, even to myself, "just
in case" (because one too many wordpress vulnerabilities have made me
paranoid in that regard).

It sounds to me like such a feature is tantamount to walking a minefield in
which any given mine could leave you unable to access the repository data.

Just my opinion, of course. It may very well work out fine for you.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] "malformed database schema"

[Stephan Beal]

i suspect that the old sqlite version has something to do with this. Try
using "fossil sqlite" instead of sqlite3.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.


On Wed, Apr 11, 2018, 00:09 Jan Danielsson 
wrote:

> Hello,
>
>I made a fresh clone of https://src.fossil.NetBSD.org/ and it seemed
> to run to completion without any problems, but once it's done I can't do
> simple queries in it:
>
> gauss$ sqlite3 netbsd.fossil
>
> SQLite version 3.8.3.1 2014-02-11 14:52:19
> Enter ".help" for instructions
> Enter SQL statements terminated with a ";"
> sqlite> .schema
> Error: malformed database schema (artifact) - near "(": syntax error
> sqlite> select * from config;
> Error: malformed database schema (artifact) - near "(": syntax error
>
>I redid the clone but it ended up in the same state.
>
>Browsing the source online repo seems to work fine, so I'm assuming
> it's a local problem -- but how can it end up in this state?  I did no
> more than clone it.
>
> --
> Kind Regards,
> Jan Danielsson
> ___
> 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] Web interface: "ls -l" list of files?

[Stephan Beal]

On Mon, Mar 19, 2018 at 7:30 PM, The Tick <the.t...@gmx.com> wrote:

> Is there a was to get a "ls -l" style list of the files in a repository
> from the web interface? I see "Tree-View" or "File Ages" but the listing of
> "ages" seems to be relative to the last commit time.


A related sidebar: fossil doesn't actually store the creation- or
modification times of files. The only timestamps it remembers are when
changes are made to the repository (a checkin, wiki/ticket edit, new tag
applied to a commit, etc.). When fossil tells you the age of a file, it's
really showing you the timestamp of the commit which most recently modified
that file.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Experimental timeline "View Mode" changes.

[Stephan Beal]

Fwiw, i prefer the Classic, with the uid at the start of the message. When
it's at the end, the eyes and mouse hand have to look for it in a different
place for every entry.

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Sat, Mar 17, 2018, 17:02 Richard Hipp  wrote:

> A new "Classic" viewing mode has been added to the timeline.
> "Classic" looks the same as "Verbose" did in the previous release.
> "Verbose" has now been modified to look the same as "Compact" except
> that the check-in details come up expanded.
>
> I prefer to look at timelines using the new-Verbose.  That's why I added
> it.
>
> I'm open to restoring "Verbose" to the old style and then coming up
> with a new name for the new-Verbose if anybody has any suggestions.
>
> The new prototype is installed on the Fossil and SQLite servers if you
> want to give it a test run.
>
>https://fossil-scm.org/fossil/timeline
>https://sqlite.org/src/timeline
>
>
> --
> 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] JSON timeline missing deleted files?

[Stephan Beal]

On Tue, Mar 13, 2018 at 10:09 AM, Stephan Beal <sgb...@googlemail.com>
wrote:

> On Tue, Mar 13, 2018 at 12:17 AM, João Batista <jmn.bati...@gmail.com>
> wrote:
>
>> With fossil 2.5, it seems that "fossil json timeline checkin" does not
>> show deleted files in a checkin, but "fossil timeline -t ci" does:
>> ...So which is it? A bug? A "feature"? Or just a PEBCAK error...? :-)
>>
>
> i _think_ what happened here is that at the time (late 2011) is that the
> timeline page didn't list deleted files, and the json timeline simply
> adopted that behaviour. i may be misremembering, but i can't conceive of
> another reason i may have left that out. ...
>

More details...

The JSON docs:

https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2qNUkBEgiUvoqFN4/view

Say that each file's state is reported as one of the strings (modified,
added, removed). A quick glance through the related code:

https://www.fossil-scm.org/index.html/artifact/5a9ce59def16a55b?ln=353-354
and
https://www.fossil-scm.org/index.html/artifact/6530c919e6671cbe?ln=282-288

suggests that it "looks okay". However, a quick local test also shows that
a removed file is indeed not reported. The first suspect is the related
query:

https://www.fossil-scm.org/index.html/artifact/5a9ce59def16a55b?ln=323-332

i don't recall (it's been far too long) whether or not that catches deleted
files, nor how to make it do so if it doesn't. Anyone wanting to look into
it should start there, though.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] JSON timeline missing deleted files?

[Stephan Beal]

On Tue, Mar 13, 2018 at 12:17 AM, João Batista <jmn.bati...@gmail.com>
wrote:

> With fossil 2.5, it seems that "fossil json timeline checkin" does not
> show deleted files in a checkin, but "fossil timeline -t ci" does:
> ...So which is it? A bug? A "feature"? Or just a PEBCAK error...? :-)
>

i _think_ what happened here is that at the time (late 2011) is that the
timeline page didn't list deleted files, and the json timeline simply
adopted that behaviour. i may be misremembering, but i can't conceive of
another reason i may have left that out. Unfortunately, i'm still on
long-term medical leave for a severe case of RSI in both arms, so my typing
is limited and my programming even more so, so i can't personally commit to
correcting this for the foreseeable future. (That's not to say that someone
else couldn't do it, though!)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] JSON timeline missing deleted files?

[Stephan Beal]

That sounds like an omission, but i don't recall off hand (that code is
about 5 years old now). i will take a look at it tomorrow (Central Euro
Time).

- stephan
Sent from a mobile device, possibly left-handed from bed. Please excuse
brevity, typos, and top-posting.

On Tue, Mar 13, 2018, 00:18 João Batista  wrote:

> Hello all,
>
> With fossil 2.5, it seems that "fossil json timeline checkin" does not
> show deleted files in a checkin, but "fossil timeline -t ci" does:
>
> # fossil version -v
> This is fossil version 2.5 [188a0e2904] 2018-02-07 18:48:14 UTC
> Compiled on Feb 28 2018 23:03:00 using gcc-5.4.0 20160609 (64-bit)
> Schema version 2015-01-24
> zlib 1.2.8, loaded 1.2.8
> hardened-SHA1 by Marc Stevens and Dan Shumow
> SSL (OpenSSL 1.0.2g  1 Mar 2016)
> JSON (API 20120713)
> UNICODE_COMMAND_LINE
> FOSSIL_DYNAMIC_BUILD
> SQLite 3.22.0 2018-01-22 18:45:57 0c55d17973
> SQLITE_DEFAULT_FILE_FORMAT=4
> SQLITE_DEFAULT_WAL_SYNCHRONOUS=1
> SQLITE_ENABLE_DBSTAT_VTAB
> SQLITE_ENABLE_FTS3_PARENTHESIS
> SQLITE_ENABLE_FTS4
> SQLITE_ENABLE_FTS5
> SQLITE_ENABLE_JSON1
> SQLITE_ENABLE_LOCKING_STYLE=0
> SQLITE_ENABLE_STMTVTAB
> SQLITE_LIKE_DOESNT_MATCH_BLOBS
> SQLITE_MAX_EXPR_DEPTH=0
> SQLITE_OMIT_DECLTYPE
> SQLITE_OMIT_DEPRECATED
> SQLITE_OMIT_GET_TABLE
> SQLITE_OMIT_LOAD_EXTENSION
> SQLITE_OMIT_PROGRESS_CALLBACK
> SQLITE_OMIT_SHARED_CACHE
> SQLITE_THREADSAFE=0
> SQLITE_USE_ALLOCA
> # fossil timeline 0d11ea056b -t ci -v | grep www
>EDITED www/changes.wiki
>EDITED www/env-opts.md
>EDITED www/index.wiki
>DELETED www/mkdownload.tcl
>EDITED www/server.wiki
> # fossil json timeline checkin 0d11ea056b -v -n 1 | grep '"name":' | grep
> www
> "name":"www/changes.wiki",
> "name":"www/env-opts.md",
> "name":"www/index.wiki",
> "name":"www/server.wiki",
> #
>
>
> So which is it? A bug? A "feature"? Or just a PEBCAK error...? :-)
>
> Regards,
> J Batista.
>
> ___
> 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] Repo extension in "fossil cgi" when used with "directory:"

[Stephan Beal]

On Wed, Feb 21, 2018 at 6:01 PM, Richard Hipp <d...@sqlite.org> wrote:

> I tried to do this.  It turns out to be non-trivial.  Can you not
> simply rename your repositories to use the standard ".fossil" suffix?
>

i'm not sure, off-hand, whether symlinks (or hard links) are a problem
via-a-vis sqlite or 'fossil rebuild', but either symlinks or hard links
might be another option, simply aliasing the .fsl files.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Windows GUI that allows diff between two, revisions?

[Stephan Beal]

On Thu, Feb 15, 2018 at 10:43 PM, Gilles <codecompl...@free.fr> wrote:

> Alternatively: As a work-around, what about offering an easy-to-parse
> output from the EXE ?
>
> For instance, I'd like to find all the release versions for a given file,
> so as to display the list and let the user pick two to perform a diff:
>  Current
> C:\>fossil finfo myfile.c
> History of myfile.c
>


fossil json finfo myfile.c

e.g.

[stephan@lapdog:~/fossil/fossil]$ f json finfo BUILD.txt | head -20
{
"fossil":"6b41a7e803348a9247818a66c9b968a9fd8e5d3408cecdad905c08dc018a",
"timestamp":1518732431,
"command":"finfo",
"procTimeUs":4000,
"procTimeMs":4,
"warnings":[{
"code":1,
"text":"Achtung: the output of the finfo command is up for change."
}],
"payload":{
"name":"BUILD.txt",
"checkins":[
{
"checkin":"06ffd8009ff257ded9f98e179fd52513081ddcf2",
"uuid":"976db410b019ec100c95da8aa977d6209fee9a4e",
"timestamp":1428028595,
"user":"mistachkin",
"comment":"Merge updates from trunk.",
"size":2704,
[stephan@lapdog:~/fossil/fossil]$

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Windows GUI that allows diff between two, revisions?

[Stephan Beal]

On Thu, Feb 15, 2018 at 3:48 PM, Gilles <codecompl...@free.fr> wrote:

> On 15/02/2018 15:17, Richard Hipp wrote:
>
>> ...There was a project to rewrite Fossil as a DLL, but there has been no
>> recent progress on that.
>>
> Too bad.
>

That's my fault. Severe RSI has left me on medical leave for most of the
past 3 years (with no end in sight), which has effectively removed me from
the programming scene. While libfossil was quite far along (aside from
networking support, it had, at the library level, essentially all of the
required features)), the SHA1 "attack" and subsequent reworking on fossil
have left libfossil requiring a non-trivial amount of rework to catch up,
and i'm physically unable to do it :/. If someone would like to take it
over, the code is here:

http://fossil.wanderinghorse.net/r/libfossil

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Bug Report: Fossil 2.3 runs out of Memory During Check-in

[Stephan Beal]

On Sat, Jan 27, 2018 at 8:20 AM, Martin Vahi <martin.v...@softf1.com> wrote:

> About  5GiB of it is the Fossil repository file and
> about 17GiB of it is a tar-file with about 140k files that
> the test tries to insert to the fossil repository.
>

i'm gonna go ahead and say it because every else is thinking it:

Short answer:

Nope.

The longer answer:

As Warren said before, Fossil is going to need some multiplier of that size
in memory. Simply reading that file for insertion into the db requires 1x
its size. The sqlite3 bind process is, i see now, already optimized as far
as it can be to eliminate yet another in-memory copy of that blob:

http://fossil-scm.org/fossil/artifact/6d07632054b709a5?ln=350-351

Your system is very likely failing on that first allocation of 17GiB. If
it's not, then it's going to fail further down the line when...

a) you use the 'zip' or 'tar' commands, which build their archives in
memory. If it doesn't fail here then it will fail when...

b) you try to commit a change to that file. In that case, fossil needs 2-3x
that amount of memory (in separate allocations) in order to be able to
create and apply the delta: 37.x-51GiB of RAM _just for that one file_.
That's excluding any other memory costs it has.

Fossil is intended for managing source code, not... whatever it is that you
believe a 17GiB blob needs to be doing in a source control system (in a
piece of hardware containing only a small fraction that amount of memory,
no less). Barring major architectural upheaval (one step of which would be
reimplementing the delta generator and applicator to stream their i/o,
rather than working in-memory), your use case simply is not realistic in
fossil.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] 413 Request Entity Too Large

[Stephan Beal]

On Thu, Jan 11, 2018 at 2:43 PM, Dingyuan Wang <gumb...@aosc.io> wrote:

> When I committed a large blob,


How large?

Fossil requires a great deal of RAM to process diffs of blobs:

1) the memory for version 1
2) the memory for version 2
3) the memory for the diff of v1 and v2.

e.g. if you are trying to commit a 5-byte change to a 1GB blob, fossil
needs just over 2GB of memory to commit that.

I can't sync with my server, which uses
> nginx for reverse proxy.
> "server says: 413 Request Entity Too Large"


i can find "413" nowhere in fossil's source code except in unrelated
Unicode bits. It seems like this message is coming from your nginx.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Errors in current trunk (24c2b99d) related to TIMESPEC

[Stephan Beal]

On Tue, Jan 9, 2018 at 9:09 PM, The Tick <the.t...@gmx.com> wrote:

>   src/cson_amalgamation.c: In function 'cson_str_to_json':
>   src/cson_amalgamation.c:3888:51: warning: '%04x' directive writing 4
> bytes into a region of size between 3 and 5 [-Wformat-overflow=]
>rc = sprintf(ubuf, "\\u%04x\\u%04x",
>  ^~~~
>   src/cson_amalgamation.c:3888:40: note: directive argument in the range
> [56320, 57343]
>rc = sprintf(ubuf, "\\u%04x\\u%04x",
>   ^~~~
>   src/cson_amalgamation.c:3888:24: note: 'sprintf' output between 13 and
> 15 bytes into a destination of size 13
>rc = sprintf(ubuf, "\\u%04x\\u%04x",
>~~~^
> (0xd800 | (ch>>10)),
> 
> (0xdc00 | (ch & 0x3ff)));
> 
>

That buffer has been increased to 20 bytes. Please try with the latest
trunk. Thank you for your persistence!

http://fossil-scm.org/fossil/info/e508424e7d7863e1

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Errors in current trunk (24c2b99d) related to TIMESPEC

[Stephan Beal]

i will take a look at the cson warnings - that fike is generated from an
upstream tree.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Jan 9, 2018 21:17, "jungle Boogie"  wrote:

> On 9 January 2018 at 06:32, Richard Hipp  wrote:
> > A new version of Fossil is now on trunk.
> > (https://www.fossil-scm.org/fossil/info/9a33a240a2101ede)  Please try
> > again to build on every platform you have at hand, but especially all
> > variations of MSVC and MinGW, and let me know whether or not you run
> > into build issues.
> >
>
> I don't see any build errors when using MS Visual Studio 2017,
> v15.0.26730.16.
> I just performed a fossil up trunk and the make flags.
>
>
> > --
> > 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-users Digest, Vol 120, Issue 2

[Stephan Beal]

(this time back to the list)
On Tue, Jan 2, 2018 at 3:43 AM, Andy Bradford <amb-fos...@bradfords.org>
wrote:

> Thus said Stephan Beal on Tue, 02 Jan 2018 03:07:20 +0100:
>
> > That will  still strip  any newlines from  his input,  though, because
> > that's how $(...) works.
>
> It actually only strips the trailing newline. Any newlines in the middle
> of the file are fine.


That's not what i'm seeing:

[stephan@host:~]$ echo -e "1\n2\n3"
1
2
3
[stephan@host:~]$ echo $(echo -e "1\n2\n3")
1 2 3

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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-users Digest, Vol 120, Issue 2

[Stephan Beal]

On Tue, Jan 2, 2018 at 2:25 AM, Ron W <ronw.m...@gmail.com> wrote:

> Try splitting the long text file into 2 or more smaller files, then add
> the ticket using the first file. Then you can append to the comment:
>
>$ fossil ticket change TICKETUUID +comment "$(cat content_next)"
>

That will still strip any newlines from his input, though, because that's
how $(...) works.

To get the comment text imported verbatim, i suspect that the ticket
command needs to support a -M FILENAME option to import a comment, like
checkin does.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] mimetype of a ticket with specified mimetype

[Stephan Beal]

On Mon, Jan 1, 2018 at 1:58 PM, Sergey Bronnikov <este...@gmail.com> wrote:

> $ fossil ticket add title "title" comment "$(cat bugs-example1)" mimetype
> "text/plain"
>
> When I open this ticket in a Web UI it shows as "formatted" and all lines
> are stick together. Content view becomes fine with switch to 'plaintext'
> mode above ticket.
> The question is: why fossil shows me formatted text when I specified it as
> "text/plain"?
>

Running a command through $(...) strips any newlines from the output, which
is likely mangling your comment text.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Import --svn "internal error: out of memory"

[Stephan Beal]

On Wed, Dec 27, 2017 at 12:44 PM, Olivier Mascia <o...@integral.be> wrote:

> Being "rookie" with Fossil, I'm starting some tests to migrate some of our
> subversion repositories to Fossil and have a better test bed to learn
> fossil before eventually deciding on a switch.
>

To quote the Oracle:

"[Because] You didn't come here to make the choice, you've already made it.
You're here to try to understand why you made it."

Welcome aboard!

:)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 hack: quickly finding the first checkin via the web UI

[Stephan Beal]

i sometimes want to find out how old a given 3rd-party repo is, and paging
through the timeline is a tedious way to do it. It can be done more quickly
by drilling down through the /reports (by year, selecting the first year,
then the first week-of-year). What i didn't know, until today, is that it's
possible to use fossil's "rid:#" artifact ID alias with the /info page,
e.g.:

https://fossil-scm.org/fossil/info/rid:1

RID #1 is always the first artifact ever stored in the fossil db, which is
(historically, at least) the empty initial checkin. i'm not sure that that
always applies after a rebuild/reconstruct, but it works on all the repos
i've tried so far.

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] tangent vs. wyoung on recent commti

[Stephan Beal]

Fwiw, i agree completely, plus suspect (without knowing for certain) that
including a user's IP (and thus, indirectly, location) in the permanent
record _might_ run afoul of privacy laws in some jurisdictions.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Dec 18, 2017 10:12, "Jan Nijtmans"  wrote:

> 2017-12-18 5:58 GMT+01:00 Ron W:
> > All I'm suggesting is that the information already being put in the
> > "rcvfrom" table (that DRH mentioned) also be saved as tags to the commits
> > they refer to. Therefore, the tags will have the same meaning as the
> entries
> > in the existing "rcvfrom" table.
>
> Well, I don't think this is even possible, neither does it help
> accomplishing
> what you want. Tags can easily forged as well. Another problem: tags, when
> created in one repository will later synchronized to other repositories
> (even back to the original one), so I'm really not sure what the
> value of the information in it really is . I wouldn't go this path.
>
> My suggestion would be: try to come up with a patch, which does what
> you suggest. I don't think it would help anything, but feel free to prove
> me wrong!
>
> Thanks!
>   Jan Nijtmans
> ___
> 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] tangent vs. wyoung on recent commti

[Stephan Beal]

On Thu, Dec 14, 2017 at 9:38 PM, Ron W <ronw.m...@gmail.com> wrote:

> Local, command line usage seems to grant the command line user full
> permissions as long as the user has RW access to the repo file, itself.
>
> Right now, I can't test this to confirm this behavior.
>

That's correct: all CLI commands simply bypass (i.e. don't check)
permissions. Only client/server commands check permissions.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] How to share a fossil repo using static http (without the cgi)?

[Stephan Beal]

In short, no. To be able to clone, fossil needs a server process of some
sort, which means either CGI or a the built-in standalone http server. It
can use SSH, but that uses fossil's built-in server to do the real work.

PS: the db does not store raw user passwords, but does store hashes of
those passwords.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Dec 12, 2017 20:55, "Juan Francisco Cantero Hurtado" 
wrote:

> Something like:
>
> https://git-scm.com/book/en/v1/Git-Internals-Transfer-Protoc
> ols#The-Dumb-Protocol
>
> https://www.mercurial-scm.org/wiki/StaticHTTP
>
> IIUC, the .fossil files include the users passwords and I don't know if
> those include more private info. So, I can't just share directly the file.
>
> Let me give you an example, so it's more clear. I want share a fossil repo
> using a static http server, without the cgi. And I want share only the
> "code part" without the wiki or the issues. The user could clone the repo
> and pull regularly the changes. Can I do something like that with fossil?.
>
> Cheers.
>
>
> --
> Juan Francisco Cantero Hurtado http://juanfra.info
>
> ___
> 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] Older fossil archives are not rebuild-able

[Stephan Beal]

On Tue, Dec 12, 2017 at 6:57 PM, J Knight <j...@j2mfk.com> wrote:

> Hello. I have some older fossil archives that report:
>
>
>
> SQLITE_ERROR: table config has no column named mtime
>
> fossil: table config has no column named mtime: {REPLACE INTO
> config(name,value,mtime) VALUES('hash-policy',1,now())}
>
>
>
> issuing a ‘rebuild’ and a ‘rebuild –force’ gives the same error. Is there
> some way to bring these up to date or somehow migrate?
>

i'm not 100% certain that this will do the job, but it's worth a try...

See:

[stephan@host:~]$ f help decon
Usage f deconstruct ?OPTIONS? DESTINATION


This command exports all artifacts of a given repository and
writes all artifacts to the file system. The DESTINATION directory
will be populated with subdirectories AA and files AA/B.., where
AAB.. is the 40+ character artifact ID, AA the first 2 characters.
If -L|--prefixlength is given, the length (default 2) of the directory
prefix can be set to 0,1,..,9 characters.

Options:
  -R|--repository REPOSITORY  deconstruct given REPOSITORY
  -L|--prefixlength N set the length of the names of the DESTINATION
  subdirectories to N
  --private   Include private artifacts.

See also: rebuild, reconstruct

[stephan@host:~]$ f help recon
Usage: f reconstruct FILENAME DIRECTORY

This command studies the artifacts (files) in DIRECTORY and
reconstructs the fossil record from them. It places the new
fossil repository in FILENAME. Subdirectories are read, files
with leading '.' in the filename are ignored.

See also: deconstruct, rebuil


So... (untested)...

fossil decon -R repo.file ~/tmp/xxx

Then:

fossil recon repo-new.file ~/tmp/xxx


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Lots of web interface changes

[Stephan Beal]

On Wed, Dec 6, 2017 at 10:59 PM, Richard Hipp <d...@sqlite.org> wrote:

> On 12/6/17, Stephan Beal <sgb...@googlemail.com> wrote:
> > On Wed, Dec 6, 2017 at 8:33 PM, Richard Hipp <d...@sqlite.org> wrote:
> >
> >> know.)  Are you still having the same problem with the latest
> >> code, even after hitting multiple "Reloads"?
> >>
> >
> > Just tested: no :)
>
> I just brought up chrome here on my desktop and on a Win7 laptop and
> they both seems to be working fine.  Can you give me more information
> on how to repro the problem?


Sorry, i could have been more explicit: no, i don't have the problem
anymore - it may have been a transient problem. :)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Lots of web interface changes

[Stephan Beal]

On Wed, Dec 6, 2017 at 8:33 PM, Richard Hipp <d...@sqlite.org> wrote:

> know.)  Are you still having the same problem with the latest
> code, even after hitting multiple "Reloads"?
>

Just tested: no :)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Lots of web interface changes

[Stephan Beal]

On Wed, Dec 6, 2017 at 8:22 PM, Richard Hipp <d...@sqlite.org> wrote:

> There have been lots of changes (hopefully, "improvements") to the web
> interface of Fossil over the past few days.  If you have not be
> following the developments, I encourage you to visit a few of the main
> sites running the latest code and let me know what you think.  Your
> suggestions and comments are very important.
>

FYI: i noticed two days ago that on my tablet (Chrome browser) that the
various timeline links all point to the honeypot page. It seems the bot
detection got unduly stringent (i know that's an ongoing war).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Trolling GitHub for ideas

[Stephan Beal]

On Mon, Nov 27, 2017 at 10:50 AM, Javier Guerra Giraldez <jav...@guerrag.com
> wrote:

> ideally, on any diff view (a commit, a diff between two versions, a
> merge preview), i'd like to add comments right there, interleaved with
> the code. optionally added to a ticket too; so that opening the ticket
> would show all related comments, each with a short view of the code
> and a link to the full context.
>

GoogleCode (or one of the similar platforms) had the ability to comment on
lines of files/diffs, and i have missed that feature at least twice in
fossil.

i.e. +1

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] More timeline changes

[Stephan Beal]

On Sat, Nov 25, 2017 at 11:06 PM, Tony Papadimitriou <to...@acm.org> wrote:

> The idea looks very good to me.  But the ellipses are indeed barely
> visible.
> How about replacing ... with [*] as a generic (foot)note mark?
>

LOL! i didn't even notice that the ellipsis were there. i recommend doing
away with them entirely, an simply making "click a timeline entry to expand
its details" a new documented feature.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] More timeline changes

[Stephan Beal]

On Sat, Nov 25, 2017 at 2:47 PM, Richard Hipp <d...@sqlite.org> wrote:

> In the latest code on https://www.fossil-scm.org/fossil/timeline and
> at https://sqlite.org/srcx/timeline has a "Declutter" button on the
> sub-menu bar to simplify the screen.  In the simplified timeline,
> there is a "Details" button to get all the details back again.
>

i was about to suggest that clicking on a single entry declutter only that
entry, but it seems you already did that :).

(2) Decluttered should be the default.  Currently Details is the
> default.  I spent a lot of time experimenting last night, and what I
> found myself doing every time I encountered a timeline was immediately
> pressing the "Declutter" button to get a high-level overview of the
> graph, then clicking on "Details" if I wanted to see more.  From that
> experience, I think coming up in Decluttered mode would be a much
> better approach.
>

"This should be the default" was my first impression.


> ...decluttered mode (showing only the check-in comment for each entry)
> but with ellipses or some other small icon at the end of each comment
> that you can click on to expand the details.
>

i like the way it works now, that you simply click anywhere on the row.
Granted, it's possibly not intuitive without some visual indicator to click
on ("..."), but it's visually elegant.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Interface improvement ideas from GitHub

[Stephan Beal]

A short sidebar for those unfamiliar with this particular quirk of JS:

On Sat, Nov 25, 2017 at 3:49 PM, David Mason <dma...@ryerson.ca> wrote:

> node.setAttribute('title','Click to '+(expand || 'expand'));
>

In JS the || operators evaluates to the first value of its left/right sides
which itself evaluates to true in a "boolean context". i.e.:

2 || 3

in almost every other language that evaluates to true, whereas in JS it
evaluates to 2. Likewise (0 || 7) evaluates to 7.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Clone a repo served by a winsrv service

[Stephan Beal]

On Fri, Nov 24, 2017 at 1:00 AM, Stéphane Aulery <lk...@free.fr> wrote:

> Hello,
>
> Yet an error form winsrv feature.
>
> I try to clone a new repo and get this error :
>
> $ fossil clone -v http://fossil/eulalia/ eulalia.fossil
> Bytes  Cards  Artifacts Deltas
> waiting for server...
> getaddrinfo() fails: Hôte inconnu.
>

It cannot resolve the name "fossil" a your computer. What does "ping
fossil" (from a "cmd" window) say?


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] unexpected tcl error dialog via diff -tk

[Stephan Beal]

On Thu, Nov 16, 2017 at 3:45 AM, Richard Hipp <d...@sqlite.org> wrote:

> I also fixed a couple other key bindings while I was at it.  Control-q
> now exits.


:-D

  I noticed the pressing Escape twice also exits.  (That is
> not new, I just hadn't noticed it before.)
>

i saw a comment to that effect a week or two ago but it didn't do anything
on the version i had. After an update, both ctrl-q and escesc close it (and
both are equally finger-friendly).

Thank you!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] unexpected tcl error dialog via diff -tk

[Stephan Beal]

Minor "cosmetic bug" report...

fossil diff -tk

Once the tcl window starts up, simply tap ENTER (i did it by accident).

That pops up a dialog saying:

Error: bad window name/identifier "bb.files"

The Details button says:
bad window name/identifier "bb.files"
bad window name/identifier "bb.files"
while executing
"event generate bb.files <1>"
(command bound to event)


It does not happen if ENTER is pressed in the Search field.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Could not find a valid check-in for RID xxxx. Possible checkout/repo mismatch.

[Stephan Beal]

On Wed, Nov 15, 2017 at 10:35 AM, Stefan Bellon <sbel...@sbellon.de> wrote:

> Hi Fossil Users,
>
> we are getting the following message when attempting a commit:
>
>   Could not find a valid check-in for RID .
>   Possible checkout/repo mismatch.
>
> What could be the reason for that?
>

RIDs are internal numbers which can be different for any given copy of a
repository. This error mostly likely means that someone replaced an opened
repository with a copy from a different source. For example, if you cloned
it, then checked it out, then replaced the cloned copy of the repo from a
backup. In that case, the checkout RIDs might not match those of the repo
file.

i recommend trying the following from the checkout directory:

1) fossil close
It will warn about uncommitted changes. Tap "Y" to accept it (you won't
lose any data except fossil's "stash" and "undo").

2) fossil open /path/to/repo.fossil --keep
that will open the repo again, keeping any local changes.

That "might" solve the problem.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] [Nmh-workers] Merging Source Files with git. (fwd)

[Stephan Beal]

On Tue, Nov 14, 2017 at 4:26 PM, Warren Young <war...@etr-usa.com> wrote:

> https://tangentsoft.com/pidp8i/finfo?name=libexec/mkos8


Don't take this the wrong way, but that is a mighty fine skin you have, sir.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] "snapshot" alias...

[Stephan Beal]

Apropos nothing at all, i wanted to share a fossil shell alias which i have
often found useful:

alias fsnap='fossil stash snapshot -m "snapshot @ $(date)" && echo
"snapshot created"'

(Remember to replace $(date) with `date` if you're using an older-style
shell or if you simply prefer backticks.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] JSON API

[Stephan Beal]

On Sun, Nov 12, 2017 at 1:12 PM, <bytevolc...@safe-mail.net> wrote:

> Good day to you all,
>
> I have been trying to find up-to-date information about the JSON API
> built into Fossil. Is there any plans on moving forward with this?


i'm the original developer of the JSON API, but a severe, long-term case of
RSI (since Dec. 2014) has forced me to retire from my open source work
(except for occasional tiny patches), thus i don't personally work on it
any more. It's unclear if/when my damaged elbow nerves will ever recover,
so i can't make any code-related commitments (my left elbow is still not
fully recovered after an OP last May, and i've got a second operation
planned for early 2018 to try to alleviate the problem in the right elbow).

That's not to say that the JSON API is off-limits to other developers! i
would love to see someone take it over and actively work on it.


> The latest information I could find is a link to a document on Google
> Docs in a mail dated back in 2013 or so, and I cannot tell when the
> document was last updated. The last time it was mentioned on the
> official fossil-users mailing list was in March 2017
> (https://www.mail-archive.com/fossil-users@lists.fossil-scm.
> org/msg24857.html)
> but simply mentioned the same Google Docs document:
> https://docs.google.com/document/d/1fXViveNhDbiXgCuE7QDXQOKeFzf2q
> NUkBEgiUvoqFN4/view


Those are still the current/complete docs. If someone has mutated the JSON
code such that it no longer matches those docs, i'm not aware of it.


> Has this API been abandoned?


Not abandoned, just not currently actively developed.


> It seems like a nice feature if you
> want to develop a custom UI or application that uses Fossil as a
> back-end, such as a full-blown wiki, for example.
>

That's exactly what i use the JSON API for. e.g.:

http://fossil.wanderinghorse.net/wikis/cson

that uses a custom front-end to server/manage wiki content from/in a fossil
repo. It uses client-side rendering using the GoogleCode wiki format,
rather than Fossil's built-in one.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] feature request: diff -tk: 'q' to quit

[Stephan Beal]

Lol - i never even noticed that there was a search box in the diff view.

i'd be just as happy with ctrl-q - anything which is left-hand friendly.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Nov 12, 2017 01:06, <fos...@pointsman.de> wrote:

>
> Stephan Beal  writes:
> > Sometime in the far past, tapping 'q' (or maybe it was 'x') in the diff
> -tk
> > widget used to exit that widget. Nowadays one has to click the "Quit"
> > button or tap Alt-F4 (a really finger-clumsy holdover from early Windows
> > versions).
>
> It was 'q'. It was removed by
> http://fossil-scm.org/index.html/info/f6d9583173cbd6d2
>
> It missed it so much that I use a for that patched fossil.
>
> > Can we please, please, please get the 'q'==>quit functionality back? It
> > sounds like a trivial thing to add, but the tcl code is all Greek to me
> :/.
>
> I second that plea.
>
> I still use the proposed patch from
>
> https://www.mail-archive.com/fossil-users@lists.fossil-scm.
> org/msg24885.html
> ___
> 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

[fossil-users] feature request: diff -tk: 'q' to quit

[Stephan Beal]

Sometime in the far past, tapping 'q' (or maybe it was 'x') in the diff -tk
widget used to exit that widget. Nowadays one has to click the "Quit"
button or tap Alt-F4 (a really finger-clumsy holdover from early Windows
versions).

Can we please, please, please get the 'q'==>quit functionality back? It
sounds like a trivial thing to add, but the tcl code is all Greek to me :/.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Main repository moved from http to https?

[Stephan Beal]

On Tue, Nov 7, 2017 at 11:25 AM, Stefan Bellon <sbel...@sbellon.de> wrote:

> Dear Fossil users,
>
> until recently a fossil remote of http://www.fossil-scm.org/ worked,
> but now I get
>
> cannot connect to host www.fossil-scm.org:80
>

fwiw, that also happened to me when i typed "sqlite.org/src" into my
browser's URL bar today. Only after saying to myself "wha!?!?" and googling
did i get the https link and land on the site (at which point i realized
that https was the missing puzzle piece).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] bug(?) in glob handling on exact match?

[Stephan Beal]

On Thu, Nov 2, 2017 at 4:53 PM, Francis Daly <fran...@daoine.org> wrote:

> From the doc page above:
>
> Pattern Effect
> README  Matches only a file named README in the root of the tree. It does
> not match a file named src/README because it does not include any
> characters that consume (and match) the src/ part.
>

Fair enough. i only checked the 'f set' help text before posting.

Thank you!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] bug(?) in glob handling on exact match?

[Stephan Beal]

i'm not sure if this is a bug or not, but it looks like one...

i'm trying to import an ancient SVN repo into fossil:

# cat .fossil-settings/crlf-glob
makefile
# f com -m 'initial import from sourceforge.net/p/toc (20090708).'
./original/examples/ch04-extent/makefile contains CR/LF line endings. Use
--no-warnings or the "crlf-glob" setting to disable this warning.
Commit anyhow (a=all/c=convert/y/N)? ^C

note that 'makefile' is an exact match for the crlf-glob entry. If i modify
crlf-glob to:

*/makefile

then it works just fine.

i rather expected 'makefile' to work just like a normal glob and match any
matching filename.

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] CI thinks check-in is empty

[Stephan Beal]

It sounds like code.exe is starting up in "the background" (for lack of a
better word) and returns control to the caller before code.exe exits. What
happens when you start code.exe from the console? If the console continues
accepting input after code.exe has started, then it's incompatible with
fossil in this reg6, as fossil expects the call to return only after the
editor has quit.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Nov 1, 2017 00:24, "jungle Boogie"  wrote:

> Hi All,
>
> I would like this to be my editor on Windows:
> "C:\Program Files\Microsoft VS Code\Code.exe"
>
> I was able to set it up as my editor:
> >fossil set editor
> editor   (local)  "C:\Program Files\Microsoft VS Code\Code.exe"
>
> I wanted to commit a change:
> >fossil ci
>
> This opened VS Code and generated a text file in my project directory.
> I typed my message, saved and closed. Fossil had moved on long ago and
> assumed my check-in was empty and asked if I wanted to proceed:
>
> >fossil ci
> Autosync:  http://localhost:8080
> Round-trips: 1   Artifacts sent: 0  received: 0
> Pull done, sent: 306  received: 772  ip: 127.0.0.1
> "C:\Program Files\Microsoft VS Code\Code.exe" "./ci-comment-636BBE9D36FF.
> txt"
>
> empty check-in comment.  continue (y/N)? n
>
> Fossil opened VS Code in a couple seconds and I started typing my message.
>
> Is it likely VS code is too slow for fossil before it thinks there's
> an empty check-in?
>
> What's an editor Widows folks use? I have gvim installed, so I can
> switch to that familiar editor if you folks think VS Code is just a
> bit too slow for fossil.
>
> Thanks!
>
> --
> ---
> inum: 883510009027723
> sip: jungleboo...@sip2sip.info
> ___
> 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] Bug Report: Cloning with --private Fails

[Stephan Beal]

An unrelated tip: with that url, anyone can download your whole repo via
your web server, bypassing fossil's login. It's far safer to store your
repo db in a path unreachable by your web server so that the db can only be
accessed via fossil.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Oct 23, 2017 10:27, "Martin Vahi"  wrote:

>
> It doesn't even prompt for a password.
> Both, client side and server side, Fossil binaries
> are of version 2.3
>
> ---citation--start-
> time nice -n18 fossil clone --unversioned --private --admin-user
> martin_vahi
> https://www.softf1.com/cgi-bin/tree1/technology/flaws/silktorrent.bash/
> ./repository_storage.fossil
> Round-trips: 2   Artifacts sent: 0  received: 238
> Error: not authorized to sync private content
> Round-trips: 2   Artifacts sent: 0  received: 238
> Clone done, sent: 683  received: 65921513  ip: 185.7.252.74
> server returned an error - clone aborted
>
> real1m31.898s
> user0m5.254s
> sys 0m2.647s
> ts2@linux-0fiz:~/Projektid/progremise_infrastruktuur/andmevahetustarkvara/
> rakendusvõrgud/silktorrent/publitseerimishoidla$
> ---citation--end
>
>
> ___
> 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] An idea about mutable history*

[Stephan Beal]

On Sat, Oct 21, 2017 at 10:51 AM, Stanislav Paskalev <ksh...@gmail.com>
wrote:

> I would imagine an implementation where by default the presentation
> DAG is the same as the raw one and having additional commands (that
> appear in the raw one as commits) to alter the presentation view.
>
> Do you think that this approach is proper and feasible ?
>

IMO it sounds both interesting and feasible (but not a small amount of
work). It's essentially a timeline view using supplemental (human-edited)
inheritance/grouping metadata. Because the timeline is the single most
complex piece of UI-centric code, though, i would recommend using a
different URI for such a feature, /timeline/alt or /alternate-reality.

It would obviously need new commands to manipulate/maintain the "adopted"
family groupings of artifacts.

One important question which would need to be answered early on is how to
store this metadata. In a new Artifact type (so that it's permanent and
immutable) or in a plain DB table (which isn't "as permanent" as an
Artifact, but it may not need to be). If it's in a new Artifact type, then
it would obviously (because of its pseudo-mutable nature) require a way to
update it for purposes of the alternate timeline (e.g. "newest update
wins").

Anyway...

There are lots of questions to pose and answer, but i think the idea has
merit.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Minor typo in last commit

[Stephan Beal]

On Thu, Oct 19, 2017 at 10:39 AM, Johan Kuuse <jo...@kuu.se> wrote:

> -  *  web\_args -- _Current weg page arguments._
> +  *  web\_args -- _Current web page arguments._
>

Fixed! Thanks for the report.

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Content-Security-Policy Was: Fossil README symlink

[Stephan Beal]

On Wed, Oct 18, 2017 at 4:27 PM, Warren Young  wrote:

> If you have any Ajax calls back to the remote fossil executable and they
> ship back 

Re: [fossil-users] Content-Security-Policy Was: Fossil README symlink

[Stephan Beal]

On Wed, Oct 18, 2017 at 3:04 PM, Richard Hipp  wrote:

> as 

Re: [fossil-users] Fossil README symlink

[Stephan Beal]

On Wed, Oct 18, 2017 at 11:44 AM, Warren Young <war...@etr-usa.com> wrote:

> A great many of the old concerns about the security problems with
> Javascript have gone away through various efforts, and atop that, the vast
> majority of web sites and web apps now require JavaScript.
>

Including *cough* github *cough*. It loads about 92k of JS on its home
page, and then sends of 2 XHR requests after that.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Merge question

[Stephan Beal]

On Mon, Sep 25, 2017 at 5:32 PM, Andy Goth <andrew.m.g...@gmail.com> wrote:

> whatever was going on.  Might want to explicitly turn on more warnings
> like -Wunused or -Wall or even -Wextra to help spot these types of issues.)
>

Sidebar: i tried -Wall with fossil years ago but it didn't like sqlite3's
use of "long long", which isn't C89 (i'm not even sure it's C99, but it's
apparently supported by all compilers).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Empty file constantly being deleted

[Stephan Beal]

On Fri, Sep 8, 2017 at 3:49 PM, Thomas <tho...@dateiliste.com> wrote:

>
> How do I mark a file as deleted?


https://www.fossil-scm.org/index.html/help/rm

-- 
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Is there a way to specify paths relative to checkout's root?

[Stephan Beal]

On Thu, Sep 7, 2017 at 7:20 PM, Tony Papadimitriou <to...@acm.org> wrote:

> OK, thanks.
>
> But, what would be wrong with using / which is closer semantically, and
> compatible to both Linux and Windows path syntax?
>

Just to avoid potential ambiguity and user confusion (because Unix users
expect / to mean something very specific, having nothing at all to do with
fossil). My concern is that using / as the prefix would eventually step on
someone's toes, either confusing them or downright breaking some semantics
(though i admittedly don't have an example which would break something).

svn uses the ^ prefix as an alias for SVNROOT, so maybe that would be a
good choice. i don't recall off hand whether ^ is a legal filename
character for Fossil. The : would be a character which cannot possibly be
used in fossil filenames names up to this point, making it safe for such
usage.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Is there a way to specify paths relative to checkout's root?

[Stephan Beal]

There's not currently, and if someone wants to implement it i would suggest
: as a prefix, since fossil does not allow : in file names (for Windows
compatibility).

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Sep 7, 2017 18:43, "Tony Papadimitriou"  wrote:

> For example, assuming a checkout tree like this:
>
> lib/file
> a/b/c/d/e/f/g/h/j/file
>
> and while inside the j subdirectory, I want to refer to lib/file by doing
> something like:
>
> fossil tim –p /lib/file
>
> instead of
>
> fossil tim –p ../../../../../../../../lib/file
>
> (and not sure if I got the number of ../ right, see the problem?)
>
> Similar to how one uses ~ to refer to home path in Linux, although I’m
> interested for this to work in Windows also.
>
> I tried both ~ and / with no success.
> (I guess / would be the obvious way to do this as it’s the checkout’s
> logical root.)
>
> Is there a way to do this?
>
> Thanks.
>
> ___
> 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] Empty file constantly being deleted

[Stephan Beal]

On Thu, Sep 7, 2017 at 12:29 AM, Thomas <tho...@dateiliste.com> wrote:

> Hello,
>
> I got an issue with an empty file that's constantly being deleted whenever
> I run the checkin script after another contributor checked in using the
> same script.
>
> The script does:
> fossil addremove --dotfiles
> fossil update --force-missing
> fossil configuration pull shun
> fossil commit --allow-empty --allow-conflict --hash
>
> There's several files with a filesize of 0. They shouldn't go in the
> repository, and actually they don't. They're used as flags each contributor
> can create to get rid of some messages within some to Fossil unrelated
> scripts.
>

i'm speculating, based on the fact that you're pulling "shun" info, that
you once shunned one of those files. ALL empty files have the same hash
code, so if you shunned one of them, you've shunned them all.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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] Initial empty checkin?

[Stephan Beal]

Fwiw: My recollection and opinion are the same.

- stephan
Sent from a mobile device, possibly from bed. Please excuse brevity, typos,
and top-posting.

On Aug 17, 2017 07:35, "Andy Bradford"  wrote:

> Thus said Andy Goth on Wed, 16 Aug 2017 10:47:56 -0500:
>
> > What of this old thread? Are  the issues it discusses still pertinent,
> > or have they been resolved?
>
> I believe  all the  relevant issues were  actually resolved,  however, I
> think it  was still unfavorable  given the  time that was  available for
> testing the changes before release.
>
> Personally,  I would  be  in  favor of  retaining  the  old behavior  by
> default,  but allowing  a command  line option  to ``fossil  init'' that
> would initialize a new repository without it.
>
> Andy
> --
> TAI64 timestamp: 400059952b4d
>
>
> ___
> 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