Re: [fossil-users] Trolling GitHub for ideas

[Javier Guerra Giraldez]

On 25 November 2017 at 14:17, Richard Hipp  wrote:
> Your suggestions for useful features found in GitHub but missing from
> Fossil, or for pages in GitHub that work especially well and that you
> would like to see replicated in Fossil, are greatly appreciated.

the only github think i've really missed when using fossil for
non-personal projects is the ability to comment on a diff.

I have two different usecases for that:  the first and most obvious is
to open a commit, check the diff (from the previous version) and add
comments about the changes actually done.  if it goes on the right
direction, missing stuff, etc.  depending on context, what i tend to
do is either edit the commiit's comment, or file a ticket with a link
to the commit.  the latter is the most "correct" way, but it's harder
to keep in context.  and neither allows me to reference a specific
point in the code.

the second case is when a branch is nearing completion and becomes a
candidate for merging.  then, i review the diff and should file a
ticket. but it's hard to reference the diff itself.  (yes, copy/paste
the url works but it's tedious and error prone).  again, no way to
link a comment with a specific line.

is there a way to see what a merge would do in diff style?  that alone
replaces most of the functionality of Pull Requests.

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.

-- 
Javier
___
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  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] Trolling GitHub for ideas

[Johan Kuuse]

On Mon, Nov 27, 2017 at 1:18 PM, Stephan Beal  wrote:
> On Mon, Nov 27, 2017 at 10:50 AM, Javier Guerra Giraldez
>  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

Maybe what lacks Fossil is not a feature, but an accompanying
software, such as what Gerrit is for Git?

https://www.gerritcodereview.com/

BR,
Johan

>
> --
> - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PATCH] Improve symlink following offile_wd_isdir()

[bytevolcano]

Ping.

On Sat, 25 Nov 2017 11:42:29 +
bytevolc...@safe-mail.net wrote:
Index: src/file.c
==
--- src/file.c
+++ src/file.c
@@ -327,24 +327,30 @@
 ** zFilename is a directory -OR- a symlink that points to a directory.
 ** Return 0 if zFilename does not exist.  Return 2 if zFilename exists
 ** but is something other than a directory.
 */
 int file_wd_isdir(const char *zFilename){
-  int rc;
+  int rc, nFN;
   char *zFN;


   zFN = mprintf("%s", zFilename);
-  file_simplify_name(zFN, -1, 0);
+  nFN = file_simplify_name(zFN, -1, 0);
   rc = getStat(zFN, 1);
   if( rc ){
 rc = 0; /* It does not exist at all. */
   }else if( S_ISDIR(fileStat.st_mode) ){
 rc = 1; /* It exists and is a real directory. */
   }else if( S_ISLNK(fileStat.st_mode) ){
 Blob content;
+char *zFullName;
 blob_read_link(&content, zFN); /* It exists and is a link. */
-rc = file_wd_isdir(blob_str(&content)); /* Points to directory? */
+if(*blob_str(&content) != '/') {
+  while( nFN>0 && zFN[nFN-1]!='/' ){ nFN--; }
+} else { nFN = 0; }
+zFullName = mprintf("%.*s%s", nFN, zFN, blob_str(&content));
+rc = file_wd_isdir(zFullName); /* Points to directory? */
+free(zFullName);
 blob_reset(&content);
   }else{
 rc = 2; /* It exists and is something else. */
   }
   free(zFN);

___
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] [PATCH] Improve symlink following offile_wd_isdir()

[Richard Hipp]

On 11/27/17, bytevolc...@safe-mail.net  wrote:
> Ping.

I am in receipt of your patch.  I have not evaluated it yet because
the entire symbolic-link mechanism in Fossil is confused and very
difficult to manage.  It mostly works now, but is brittle.  A
seemingly simple patch like what you sent could cause breakage.

I am very sorry that I allowed symbolic link support into Fossil in
the first place.   (Symbolic link support was neither designed nor
written by me - it is contributed code.)  I would really like to get
rid of symbolic link support.  Symbolic links seem out-of-place in a
version control system.  As implemented, symbolic links are a point of
confusion which (as far as I can see) adds no useful capabilities.

-- 
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] Unversioned files and browser caching

[Remco Schoen]

Hi,

I just recently discovered the unversioned files feature and I really like it 
for hosting compiled versions like angular 2 and javascript libraries.

I would like to put in a feature request to allow browsers to cache the static 
content instead of always downloading the full content over and over again.

In cgi.c (https://www.fossil-scm.org/index.html/artifact/f7d88d23102129bc 
) I see some 
cache controlling code, but I’m not sure if this is called when using fossil 
serve.

Kind regards,

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

[fossil-users] Repository size - Fossil v. Git

[Richard Hipp]

TL;DR:  A Git packfile for SQLite is about 52% larger than the
equivalent content in a Fossil repository.

I downloaded a copy of the Git packfile from mackyle's mirror of
SQLite on GitHub (https://github.com/mackyle/sqlite).  Git uses a
tightly coded binary implementation for packfiles, so I was expecting
that a Git packfile would be significantly smaller than the equivalent
Fossil repo.

I was wrong.

The Git packfile comes in a 86.8MB and the entire Fossil repo is only
68.8MB.  This is in spite of the fact that the Fossil repo contains a
lot of supplemental information (ex: indexes) used to make it faster
as well as additional content (wiki, tickets) that Git does not
support.

The equivalent of a Git packfile in Fossil would be the contents of
the BLOB and DELTA tables without the UNIQUE index on the BLOB.UUID
field.  Comparing the packfile against just the unindexed BLOB table
and the DELTA table, I find that the packfile is 52% larger.

  Git packfile:  86.8MB
  Fossil content tables:  57.1MB

I do not know why this is.  I have put almost no effort toward
optimizing Fossil repositories for size, whereas metrics like
performance and size seem to be driving forces behind Git.
-- 
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

Re: [fossil-users] Repository size - Fossil v. Git

[Richard Hipp]

On 11/27/17, Richard Hipp  wrote:
> TL;DR:  A Git packfile for SQLite is about 52% larger than the
> equivalent content in a Fossil repository.

It gets worse (for Git):

The Git repo I cloned only contains the master branch - 18336
check-ins out of the 19715 check-ins found in the Fossil repo.


>
> I downloaded a copy of the Git packfile from mackyle's mirror of
> SQLite on GitHub (https://github.com/mackyle/sqlite).  Git uses a
> tightly coded binary implementation for packfiles, so I was expecting
> that a Git packfile would be significantly smaller than the equivalent
> Fossil repo.
>
> I was wrong.
>
> The Git packfile comes in a 86.8MB and the entire Fossil repo is only
> 68.8MB.  This is in spite of the fact that the Fossil repo contains a
> lot of supplemental information (ex: indexes) used to make it faster
> as well as additional content (wiki, tickets) that Git does not
> support.
>
> The equivalent of a Git packfile in Fossil would be the contents of
> the BLOB and DELTA tables without the UNIQUE index on the BLOB.UUID
> field.  Comparing the packfile against just the unindexed BLOB table
> and the DELTA table, I find that the packfile is 52% larger.
>
>   Git packfile:  86.8MB
>   Fossil content tables:  57.1MB
>
> I do not know why this is.  I have put almost no effort toward
> optimizing Fossil repositories for size, whereas metrics like
> performance and size seem to be driving forces behind Git.
> --
> D. Richard Hipp
> d...@sqlite.org
>


-- 
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

Re: [fossil-users] Repository size - Fossil v. Git

[Joerg Sonnenberger]

On Mon, Nov 27, 2017 at 02:28:37PM -0500, Richard Hipp wrote:
> TL;DR:  A Git packfile for SQLite is about 52% larger than the
> equivalent content in a Fossil repository.

Did you run repack with aggresive settings? I.e. with -A -d -f and large
--depth and --window-size settings? Especially if the original migration
wasn't done well, the pack files are often quite redundant.

Your numbers really don't match my experience, i.e. what I see is about
a factor of 2 to 2.5 larger Fossil repos.

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

Re: [fossil-users] Repository size - Fossil v. Git

[Richard Hipp]

On 11/27/17, Joerg Sonnenberger  wrote:
> On Mon, Nov 27, 2017 at 02:28:37PM -0500, Richard Hipp wrote:
>> TL;DR:  A Git packfile for SQLite is about 52% larger than the
>> equivalent content in a Fossil repository.
>
> Did you run repack with aggresive settings? I.e. with -A -d -f and large
> --depth and --window-size settings? Especially if the original migration
> wasn't done well, the pack files are often quite redundant.
>
> Your numbers really don't match my experience, i.e. what I see is about
> a factor of 2 to 2.5 larger Fossil repos.
>

2x larger for Fossil is about what I would expect too.  The Git file
formats are crazy-aggressive at avoiding any wasted bytes (thus making
them hard to parse and use and especially hard to extend for things
like SHA3).

I didn't try any repacking.  I merely ran "git clone" then looked at
the packfile in .git/objects/pack.  You would think that the server
would want to do an aggressive repack before sending the packfile
across a clone, to save bandwidth.  But maybe GitHub values CPU cycles
more than bandwidth...

Your git-foo is much greater than mine, Joerg.  Can you please clone
https://github.com/mackyle/sqlite.git and see if you can get the
packfile to come out smaller?

-- 
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

Re: [fossil-users] Fossil-NG Bloat?

[Warren Young]

On Nov 23, 2017, at 5:19 AM, bytevolc...@safe-mail.net wrote:
> 
> They want maximum results for minimum effort? That may be normal, but
> it's still whiney.

If “normal” is “whiney”, it ceases to be a useful disparagement unless you 
intend to change society.  This mailing list is not a good place to start doing 
that; few take social cues from geeks. :)

> It may be easier to implement Git in an SQLite database for the sake of
> comparison.

That should be tried, too.  I suspect it will make Git faster, at least up to 
repo sizes that fit easily within a single process’s ability to grab hard-wired 
RAM, based on the benchmark I pointed you to up-thread.

Interesting point about that benchmark: if you force it to create a DB much 
larger than RAM, performance goes in the tank on the SQLite side.  And that in 
turn may well be materially interesting to this very discussion.  Maybe it’s 
why Git holds up better under load as repo size grows into the gigs.

> 
> You should ask the OpenBSD folk for advise. They have run on super
> unusual systems with compilers that support C99, including the VAX.

VAX != “super unusual.”  It was one of the most popular computers of the 1980s, 
dominating an entire market segment.  Therefore, a lot of software got ported 
to it, including recent versions of GCC.  A huge hobbyist community still 
exists for it, which also helps.

You want unusual, let’s talk about the Intel Paragon, based on the ill-fated 
i860 microprocessor:

https://en.wikipedia.org/wiki/Intel_Paragon

I suspect it’s difficult to find a GCC fully supporting C99 on that, yet they 
were powerhouses in their day, even grabbing the #1 spot in TOP500 list at one 
point:


https://www.top500.org/featured/systems/intel-xps-140-paragon-sandia-national-labs/

Now, let us say that I’m an underfunded government laboratory sharing time on a 
third-hand Paragon that is still powered on only because it’s cheaper to pay 
the power and cooling bill than buy a new massively parallel supercomputer.  Do 
I not get to run the latest SQLite now?  Do I not get to pull from public 
Fossil repos?

> Just some of the features I mentioned would make things a lot easier to
> maintain

[citation needed]

I’m quite serious.  Who says C11 is a major factor in the maintainability of C 
code, and by what measured factor?

> and provide optimisation opportunities for compilers.

Ditto.  I suspect you’re chasing microoptimizations, which might amount to 
single-digit percentage speed increases, all in.

Even at today’s far slower single-core speed increase rates, you’ll probably 
get all of that performance and more from Intel just in the time it takes to do 
the “upgrade.”  Why not spend the time elsewhere and let Intel deliver the 
goods?

>> I don’t need to do that today, but I’d prefer that you don’t preclude
>> me doing it in the future just because you want to require C11 to
>> compile SQLite and Fossil.
> 
> It won't preclude you doing it if you try hard enough. All I am
> proposing here is basic C99 functionality such as postponed variable
> declarations, inline/restrict (maybe), stdint.h/stdbool.h, etc. to make
> the code neater. If your compiler doesn't support some of that stuff,
> #define is your best friend.

You’re going to change a bunch of variables’ locality and you think I can fix 
it with a few #defines?  I don’t think so.

>> If you are developing software for a company
>> whose marketing department decides that targeting only Windows 8 and
>> 10 is the best decision, then by all means, use C11 or C++14
>> exclusively; you can afford it.
> 
> Using C99/C11 doesn't require Windows 8/10 or Linux.

I didn’t say it did.  I simply gave an example where those signing the checks 
have decided that supporting only the latest platforms is acceptable from a 
business standpoint, therefore all of my arguments about legacy architecture 
support go out the window.

Wise man say, “God created the world in only 6 days because he didn’t have a 
legacy user base to support.”

> I recall
> a presentation by Andrew Tanenbaum (of MINIX fame) mentioning that
> software is becoming slower and larger at a faster rate than hardware
> is increasing in speed and capability. He compares running a word
> processor on the PDP-11 to running MS Office on modern Windows.

That’s rather unfair, since the PDP-11 word processor probably didn’t even 
support proportional fonts, much less any appreciable fraction of Word’s 
feature set.

Still, I have been dismayed since the 1980s that it still takes 15-90 seconds 
to boot a computer to a useful application, just like it did for my Apple ][.  
It’s long past time we achieved instant-on.
___
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

[Marc Simpson]

Another issue, taking https://www.fossil-scm.org/fossil/timeline as an
example this time.

- Click `Advanced` to see commits, etc.
- Check `Files` in the toolbar to see files as well
- Page reloads with files... but back in the Basic view

So, advanced should probably be a query parameter here (when a reload
is required).

/M

On Sun, Nov 26, 2017 at 1:27 AM, j. van den hoff  wrote:
> On Sat, 25 Nov 2017 23:51:23 +0100, Marc Simpson  wrote:
>
>> One other (potential) problem: without the hash prefix, descriptions
>> run together.
>> Example: http://www.sqlite.org/src/timeline, 2017-11-24. The graph
>> nodes are flushed to the left, so descriptions appear as:
>>  Add the "^" syntax from fts3/4 to fts5. ...
>>   Enhance the configure script to detect zLib. ...
>> It's not immediately clear that these are separate commits given the
>> amount of horizontal space; adding a bit more vertical padding or
>> boxing descriptions (perhaps with alternating colours) might help?
>
>
> +1
>
> --
> Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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 size - Fossil v. Git

[Joerg Sonnenberger]

On Mon, Nov 27, 2017 at 03:28:37PM -0500, Richard Hipp wrote:
> I didn't try any repacking.  I merely ran "git clone" then looked at
> the packfile in .git/objects/pack.  You would think that the server
> would want to do an aggressive repack before sending the packfile
> across a clone, to save bandwidth.  But maybe GitHub values CPU cycles
> more than bandwidth...

git import is writing pretty dumb packs. Lots of redundancy in it,
so it's not really that surprising. It's kind of similar to the effect
of avoiding "fossil rebuild --compress" or Mercurial's generic delta.
Cloning IIRC will mostly use the deltas as recorded, it doesn't
recompute them. GitHub in generally naturally avoids CPU load as much as
possible, since it is one of the more expensive parts of running in the
cloud.

> Your git-foo is much greater than mine, Joerg.  Can you please clone
> https://github.com/mackyle/sqlite.git and see if you can get the
> packfile to come out smaller?

git repack -A -d --depth=500 --window-memory 4g -f -F
gives me around 43MB for .git.

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

Re: [fossil-users] A-B comparison of proposed timeline changes

[Warren Young]

On Nov 24, 2017, at 7:35 AM, Richard Hipp  wrote:
> 
> Which is better?
> 
>  A:  https://www.fossil-scm.org/a/timeline
>  B:  https://www.fossil-scm.org/b/timeline

I prefer A because I don’t like having to dig for details.  Hiding details 
isn’t the answer to clutter.  Drawing the eye to key details first is the right 
path.

Here is a few minutes spent with option A’s CSS:

https://imgur.com/a/w0mGF

Key changes:

1. More “air” around each comment line
2 Slight opacity drop and font size drop on details span to deemphasize it
3. Details span pushed off to the lower right to visually separate it from the 
comment
4. Extra “air” around details span; ditto
5. Borders added to separate timeline elements more clearly


Here are the CSS additions:

table.timelineTable {
  border-collapse: separate;
}
td.timelineTableCell {
  vertical-align: top;
  text-align: left;
  padding: 0.75em;
  border: 1px #ccc solid;
  border-radius: 1em;
}
span.timelineDetail {
  font-size: 80%;
  text-align: right;
  float: right;
  opacity: 0.75;
  margin-top: 0.5em;
}

More could be done, but I think that shows the idea.
___
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-B comparison of proposed timeline changes

[jungle Boogie]

On 27 November 2017 at 14:13, Warren Young  wrote:
> On Nov 24, 2017, at 7:35 AM, Richard Hipp  wrote:
>>
>> Which is better?
>>
>>  A:  https://www.fossil-scm.org/a/timeline
>>  B:  https://www.fossil-scm.org/b/timeline
>
> I prefer A because I don’t like having to dig for details.  Hiding details 
> isn’t the answer to clutter.  Drawing the eye to key details first is the 
> right path.
>
> Here is a few minutes spent with option A’s CSS:
>
> https://imgur.com/a/w0mGF
>
> Key changes:
>
> 1. More “air” around each comment line
> 2 Slight opacity drop and font size drop on details span to deemphasize it
> 3. Details span pushed off to the lower right to visually separate it from 
> the comment
> 4. Extra “air” around details span; ditto
> 5. Borders added to separate timeline elements more clearly
>


I like these changes! I definitely like the horizontal spacing around
the check-ins and the check-in details to be slightly below the single
line check-in information.

Can we see this implemented on a timeline c option?

Thanks for the work, Warren!

best,
j.b.
___
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-B comparison of proposed timeline changes

[Richard Hipp]

On 11/27/17, Warren Young  wrote:
>
> table.timelineTable {
>   border-collapse: separate;
> }
> td.timelineTableCell {
>   vertical-align: top;
>   text-align: left;
>   padding: 0.75em;
>   border: 1px #ccc solid;
>   border-radius: 1em;
> }
> span.timelineDetail {
>   font-size: 80%;
>   text-align: right;
>   float: right;
>   opacity: 0.75;
>   margin-top: 0.5em;
> }
>

Very nice!

If you also add:

   .clutter { display: inline; }
   .anticlutter { display: none; }

Then the timeline will come up in detailed mode.

I have installed the new look (temporarily at least) on
https://www.fossil-scm.org/fossil so that we can live with it for a
while to see how we like it.  The big down-side is that less
information is visible on a single screen now, so you have to scroll
more.  But that seems to be the trend with websites these days

-- 
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

Re: [fossil-users] A-B comparison of proposed timeline changes

[Warren Young]

On Nov 27, 2017, at 3:41 PM, Richard Hipp  wrote:
> 
> The big down-side is that less
> information is visible on a single screen now, so you have to scroll
> more.  But that seems to be the trend with websites these days….

The design ideas I tapped into this were old when desktop publishing was the 
new hotness.  Human factors haven’t changed in millennia.  It’s why an iPad is 
about the same size as books made before Gutenberg first sneezed.

___
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-B comparison of proposed timeline changes

[Warren Young]

On Nov 27, 2017, at 3:46 PM, Warren Young  wrote:
> 
> On Nov 27, 2017, at 3:41 PM, Richard Hipp  wrote:
>> 
>> The big down-side is that less
>> information is visible on a single screen now, so you have to scroll
>> more.  But that seems to be the trend with websites these days….
> 
> The design ideas I tapped into this were old when desktop publishing was the 
> new hotness.  Human factors haven’t changed in millennia.  It’s why an iPad 
> is about the same size as books made before Gutenberg first sneezed.

That’s an incomplete thought.

My point is, what’s changed isn’t that we’re getting sloppy in web site design 
these days, it’s that screens are finally starting to get big enough and to 
have high enough levels of contrast and resolution that we can afford to put 
some of the space in that book and magazine publishers have known is a good 
idea for centuries, and which has had solid science behind it for decades at 
least.

Wall-o-text is hard to read, in any medium.

My proposed design changes do not waste space, they buy readability.

Also, I just want to emphasize that I do not think this is the paragon of web 
site design.  I hope someone riffs on it and does something even better with it.
___
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-B comparison of proposed timeline changes

[Offray Vladimir Luna Cárdenas]

On 27/11/17 18:02, Warren Young wrote:
> On Nov 27, 2017, at 3:46 PM, Warren Young  wrote:
>> On Nov 27, 2017, at 3:41 PM, Richard Hipp  wrote:
>>> The big down-side is that less
>>> information is visible on a single screen now, so you have to scroll
>>> more.  But that seems to be the trend with websites these days….
>> The design ideas I tapped into this were old when desktop publishing was the 
>> new hotness.  Human factors haven’t changed in millennia.  It’s why an iPad 
>> is about the same size as books made before Gutenberg first sneezed.
> That’s an incomplete thought.
>
> My point is, what’s changed isn’t that we’re getting sloppy in web site 
> design these days, it’s that screens are finally starting to get big enough 
> and to have high enough levels of contrast and resolution that we can afford 
> to put some of the space in that book and magazine publishers have known is a 
> good idea for centuries, and which has had solid science behind it for 
> decades at least.
>
> Wall-o-text is hard to read, in any medium.
>
> My proposed design changes do not waste space, they buy readability.
>
> Also, I just want to emphasize that I do not think this is the paragon of web 
> site design.  I hope someone riffs on it and does something even better with 
> it.

I agree with Warren's design and improved readability by adding space.
Timeline now has more "air to breath" and is more pleasant to the eye.

Cheers,

Offray
___
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] [PATCH] Improve symlink following offile_wd_isdir()

[bytevolcano]

On Mon, 27 Nov 2017 09:52:19 -0500
Richard Hipp  wrote:

> I am in receipt of your patch.  I have not evaluated it yet because
> the entire symbolic-link mechanism in Fossil is confused and very
> difficult to manage.  It mostly works now, but is brittle.  A
> seemingly simple patch like what you sent could cause breakage.

Perhaps a separate function "make_path()" just to create any
directories that may not exist, rather than stuffing it all in
blob_write_to_file(). It can be called as follows if needed:

  make_path(zFile);
  blob_write_to_file(&content, zFile);

> 
> I am very sorry that I allowed symbolic link support into Fossil in
> the first place.   (Symbolic link support was neither designed nor
> written by me - it is contributed code.)  I would really like to get
> rid of symbolic link support.  Symbolic links seem out-of-place in a
> version control system.  As implemented, symbolic links are a point of
> confusion which (as far as I can see) adds no useful capabilities.

Are you referring to symlinks inside a working directory, or Fossil's
ability to "follow" them? If so have a survey of users, or a
disabled-by-default policy to see if any users need it.
___
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] [PATCH] Improve symlink following offile_wd_isdir()

[David Mason]

I use symlinks *very* heavily. Almost exactly 10% of the files in my main
fossil hierarchy are actually symlinks. Fossil not supporting them would be
a huge drawback for me. Good support for symlinks and nested repositories
are 2 of the details I like best about Fossil (in addition to the obvious
features).

../Dave

On 27 November 2017 at 18:20,  wrote:

> On Mon, 27 Nov 2017 09:52:19 -0500
> Richard Hipp  wrote:
>
> > I am in receipt of your patch.  I have not evaluated it yet because
> > the entire symbolic-link mechanism in Fossil is confused and very
> > difficult to manage.  It mostly works now, but is brittle.  A
> > seemingly simple patch like what you sent could cause breakage.
>
> Perhaps a separate function "make_path()" just to create any
> directories that may not exist, rather than stuffing it all in
> blob_write_to_file(). It can be called as follows if needed:
>
>   make_path(zFile);
>   blob_write_to_file(&content, zFile);
>
> >
> > I am very sorry that I allowed symbolic link support into Fossil in
> > the first place.   (Symbolic link support was neither designed nor
> > written by me - it is contributed code.)  I would really like to get
> > rid of symbolic link support.  Symbolic links seem out-of-place in a
> > version control system.  As implemented, symbolic links are a point of
> > confusion which (as far as I can see) adds no useful capabilities.
>
> Are you referring to symlinks inside a working directory, or Fossil's
> ability to "follow" them? If so have a survey of users, or a
> disabled-by-default policy to see if any users need it.
> ___
> 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-B comparison of proposed timeline changes

[Steve Landers]

Nice work.

Have you considered dropping the borders on the commits?  They do add 
definition to the commit, but at the expense of repetition and possibly “noise” 
when the branch isn’t colored

Screenshot at https://www.dropbox.com/s/o4sa29q8i0dv7r3/timeline.png?dl=0

—Steve

On 28 Nov 2017, 7:02 AM +0800, Warren Young , wrote:
> My proposed design changes do not waste space, they buy readability.
>
> Also, I just want to emphasize that I do not think this is the paragon of web 
> site design. I hope someone riffs on it and does something even better with 
> it.
___
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 size - Fossil v. Git

[David Mason]

Does it stay that size with moderate activity, or does it start growing
significantly? Does the pack format slow it down, or speed it up?

Given that the Git version only has 93% of what the Fossil repo has, I'd
say Fossil is doing quite well.

../Dave

On 27 November 2017 at 16:16, Joerg Sonnenberger  wrote:

> On Mon, Nov 27, 2017 at 03:28:37PM -0500, Richard Hipp wrote:
> > I didn't try any repacking.  I merely ran "git clone" then looked at
> > the packfile in .git/objects/pack.  You would think that the server
> > would want to do an aggressive repack before sending the packfile
> > across a clone, to save bandwidth.  But maybe GitHub values CPU cycles
> > more than bandwidth...
>
> git import is writing pretty dumb packs. Lots of redundancy in it,
> so it's not really that surprising. It's kind of similar to the effect
> of avoiding "fossil rebuild --compress" or Mercurial's generic delta.
> Cloning IIRC will mostly use the deltas as recorded, it doesn't
> recompute them. GitHub in generally naturally avoids CPU load as much as
> possible, since it is one of the more expensive parts of running in the
> cloud.
>
> > Your git-foo is much greater than mine, Joerg.  Can you please clone
> > https://github.com/mackyle/sqlite.git and see if you can get the
> > packfile to come out smaller?
>
> git repack -A -d --depth=500 --window-memory 4g -f -F
> gives me around 43MB for .git.
>
> Joerg
> ___
> 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-B comparison of proposed timeline changes

[Richard Hipp]

On 11/27/17, Steve Landers  wrote:
> Nice work.
>
> Have you considered dropping the borders on the commits?  They do add
> definition to the commit, but at the expense of repetition and possibly
> “noise” when the branch isn’t colored

Here are comparison links:

As it was yesterday:
   https://www.fossil-scm.org/fossil/timeline
   https://www.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
   https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
   https://www.fossil-scm.org/fossil/finfo?name=src/db.c

Warren Young's new approach:
   https://www2.fossil-scm.org/fossil/timeline
   https://www2.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
   https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
   https://www2.fossil-scm.org/fossil/finfo?name=src/db.c

Steve Landers' modifications to Warren's approach:
   https://www3.fossil-scm.org/site.cgi/timeline
   https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712&n=4
   https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
   https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c

Please do not restrict yourself to just the links shown.  Look at
various timelines to see what works well and what does not.

-- 
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

Re: [fossil-users] A-B comparison of proposed timeline changes

[Steve Landers]

Note that I would retain the rounded corners on Warren’s backgrounds, they make 
the visuals “softer”.

On 28 Nov 2017, 10:01 AM +0800, Richard Hipp , wrote:
> On 11/27/17, Steve Landers  wrote:
> > Nice work.
> >
> > Have you considered dropping the borders on the commits? They do add
> > definition to the commit, but at the expense of repetition and possibly
> > “noise” when the branch isn’t colored
>
> Here are comparison links:
>
> As it was yesterday:
> https://www.fossil-scm.org/fossil/timeline
> https://www.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
> https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
> https://www.fossil-scm.org/fossil/finfo?name=src/db.c
>
> Warren Young's new approach:
> https://www2.fossil-scm.org/fossil/timeline
> https://www2.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
> https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
> https://www2.fossil-scm.org/fossil/finfo?name=src/db.c
>
> Steve Landers' modifications to Warren's approach:
> https://www3.fossil-scm.org/site.cgi/timeline
> https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712&n=4
> https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
> https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c
>
> Please do not restrict yourself to just the links shown. Look at
> various timelines to see what works well and what does not.
>
> --
> 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] A-B comparison of proposed timeline changes

[David Mason]

I would like yesterdays with a bit of whitespace between commit comments.

Also someone liked the original because the checkin tag was in a
predictable place.  If you put the tag last in the extra information it
would be predictably at the right margin.

On 27 November 2017 at 21:01, Richard Hipp  wrote:

> On 11/27/17, Steve Landers  wrote:
> > Nice work.
> >
> > Have you considered dropping the borders on the commits?  They do add
> > definition to the commit, but at the expense of repetition and possibly
> > “noise” when the branch isn’t colored
>
> Here are comparison links:
>
> As it was yesterday:
>https://www.fossil-scm.org/fossil/timeline
>https://www.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
>https://www.fossil-scm.org/fossil/timeline?b=2017-09-01
>https://www.fossil-scm.org/fossil/finfo?name=src/db.c
>
> Warren Young's new approach:
>https://www2.fossil-scm.org/fossil/timeline
>https://www2.fossil-scm.org/fossil/timeline?dp=d95f712&n=4
>https://www2.fossil-scm.org/fossil/timeline?b=2017-09-01
>https://www2.fossil-scm.org/fossil/finfo?name=src/db.c
>
> Steve Landers' modifications to Warren's approach:
>https://www3.fossil-scm.org/site.cgi/timeline
>https://www3.fossil-scm.org/site.cgi/timeline?dp=d95f712&n=4
>https://www3.fossil-scm.org/site.cgi/timeline?b=2017-09-01
>https://www3.fossil-scm.org/site.cgi/finfo?name=src/db.c
>
> Please do not restrict yourself to just the links shown.  Look at
> various timelines to see what works well and what does not.
>
> --
> 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 118, Issue 47

[Ron W]

On Mon, Nov 27, 2017 at 7:00 AM, 
wrote:
>
> Date: Mon, 27 Nov 2017 09:50:29 +
> From: Javier Guerra Giraldez 
> Subject: Re: [fossil-users] Trolling GitHub for ideas
>
> the only github think i've really missed when using fossil for
> non-personal projects is the ability to comment on a diff.
>

This would be a very handy feature to have.

I think it could be implemented by adding Javascript to the existing diff
output. Maybe save the comments in a wiki page with a name derived from the
filename and commit ID, appending each comment to the page. The Javascript
code would get the line numbers of the from and to versions of the file
from the diff output.

Actually, I'd rather the comments be saved in a ticket. I think a tag on
the commit could be used to identify the ticket. All comments would go in 1
ticket, regardless of the file. I'm not sure how the Javascript could find
the filename. Maybe the diff output would need to have anchors inserted by
Fossil's diff generator.

As a bonus, Fossil's ticket artifacts are designed to support appending to
ticket fields. The diff comments will be stored without duplicating all
previous diff comments when a new one is posted.

FWIW, since my group at work was already using Review Board (reviewboard.org)
with SVN, when I introduced Fossil, our Python geek butchered RB's CVS
support to (sort of) support Fossil. (We enter review requests with
"fossil diff
| rbt post --diff-filename=-" ) Unfortunately, that person left the company
and our IT department won't let us access RB's Python files on that server,
so I can't share the changes that were made.

(Personally, I don't like Review Board. Also, since we only use RB for
commenting on diffs, adding diff comments to Fossil would allow us to keep
everything in Fossil (and to stop using RB).)
___
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

[Jungle Boogie]

On Sat 25 Nov 2017  9:17 AM, Richard Hipp wrote:
> The SQLite project is mirrored on GitHub (not by me).  This mirror
> provides a good opportunity to compare the interfaces of GitHub and
> Fossil using the same underlying data.
> 
> https://sqlite.org/srcx/timeline?basic
> https://github.com/mackyle/sqlite/commits/master
> 
> Your suggestions for useful features found in GitHub but missing from
> Fossil, or for pages in GitHub that work especially well and that you
> would like to see replicated in Fossil, are greatly appreciated.
> 

Often times I like to grab just a single file from someone's repo, i.e.
a .tmux.conf without needing to clone and/or download all their repo.
And I don't need to download the copy to the computer I'm on, but a
remote computer.

I find the file, click raw and see the contents in the browser:
https://raw.githubusercontent.com/mackyle/sqlite/master/src/shell.c.in
Then I can use fetch/ftp/wget/curl to grab the single file.

In Fossil, there is a 'Download' link, and this will actually download
the file locally, but not display in the browser.
https://sqlite.org/src/artifact/c441d7ddfbb8120c

I think there's ways to do show the file with fossil, but it's a little more
complicated, and there doesn't seem to be a button available on the
fossil link above.

tl;dr: Make it easier to show raw file contents on a webpage. Ideally,
the filename will be the suffix of the URL.:
https://sqlite.org/src/artifact/c441d7ddfbb8120c/shell.c.in

Thanks for the consideration!

Best,
j.b.





> -- 
> 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

Re: [fossil-users] Trolling GitHub for ideas

[Artur Shepilko]

> Your suggestions for useful features found in GitHub but missing from
> Fossil, or for pages in GitHub that work especially well and that you
> would like to see replicated in Fossil, are greatly appreciated.

I think the answers depend on specifics of project workflow.
GitHub is a social platform ("social coding"), so its central features
are about providing places and tools to interact.

That SQLite repo on GitHub still just has the original Fossil's repo
history, so not much of  "social" content (other than usernames).

In my workflows, the SCM part of GitHub is the least used -- Git
command line and IDE plugins give more than enough ways to present
timeline, show diffs, annotate code etc. If anything to point out
about the SCM view:
* the ease of Branch/Tag switching via drop-down box, yet Fossil's UI
timeline view better visualizes concurrency of branch development.
* timeline marks "conversations " i.e. commits that have user comments
-- it's easy to follow a conversation; again it's "social" part

Looking at the social part of GitHub -- that's where most areas are
just different vs. Fossil.
In a way, GitHub is just a giant structured message board:
 * allows conversations on commits, code lines, push, pull requests
 * the whole code-review system via pull request/merge
 * issue-tracker allows assignment to contributors
 * issue numbers are sequential  (no-go with Fossil as tickets are
also distributed)
 * convenient dashboard shows number of outstanding issues (assuming
the intended state is 0, which often is not the case :))
 * notifications, when relevant
 * nice wiki editing toolbar (for Markdown) -- helps to "non-coders"
contributors used to toolbars
 * CONSISTENCY -- this all appears to nicely "fit together" (by now);
edit text-boxes are uniform and support same input formats

Another useful feature is a link to travis-CI (continuous integration)
-- it's a service and does need a set up, but again it "fits".

This does not mean I'd like to see these features ported to Fossil.
That would change the Fossil-specific workflow which is lightweight
and distributed, as opposed to "centralized" GitHub. In fact most of
the "social" features assume a central repo.

I guess, as long as we could define and replicate CONSISTENCY, the
current Fossil UI features are sufficient already.

Maybe we could collect more real-life Fossil project use-cases (so far
the most prominent are SQLite and Fossil).
Basically, outlining the actual setup and project workflow used,
challenges too -- this could be an easier way to follow for someone
thinking to start a new project. Also it will help expose both the
useful and the missing features.
I'm currently facing a challenge to convince a non-coder contributor
to learn basic Markdown and not "freak-out" about all the other
buttons on the Fossil wiki page...Then will come a question about
inserting images in wiki...
___
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

[Thomas Levine]

The main GitHub feature that I would like is directions as to how to
download and check out the repository. I like to implement this in
fossil as a footer.
https://thomaslevine.com/scm/langrompiloj/

I believe that someone mentioned this feature in the Fossil-NG Bloat
thread, but I can't find the message at the moment.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Weird behavior on Chisel, perhaps a version mismatch?

[Jacob MacDonald]

I'm using 2.4 locally, Chisel says it's using 2.1. If I change a file in a
repository the changes go out properly but adding files to another
repository doesn't work. The push or sync seems to succeed, but the Chisel
web UI does not reflect the change and on clone I get a "manifest checksum
does not agree with disk" error and the tree does not check out at all (old
or new files).

Have I borked something by accident or is this what happens on a version
upgrade? I've tried repacking to seemingly no avail.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users