Hi all,
in case someone has time to fix this, let me write up the most annoying
performance issue for larger repositories. When running fossil update,
it will rewrite vfile table in .fslckout from scratch, even though most
entries should not change on merges. If the working copy contains a few
On Tue, Jul 16, 2013 at 8:37 AM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Hi all,
in case someone has time to fix this, let me write up the most annoying
performance issue for larger repositories. When running fossil update,
it will rewrite vfile table in .fslckout from scratch,
On Tue, Jul 16, 2013 at 08:46:06AM -0400, Richard Hipp wrote:
On Tue, Jul 16, 2013 at 8:37 AM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Hi all,
in case someone has time to fix this, let me write up the most annoying
performance issue for larger repositories. When running fossil
On Tue, Jul 16, 2013 at 2:51 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Just a matter of scale :) Essentially, the problem is that t(fossil
update) = O(files in the working copy), when it should be O(files
changed).
Just out of curiosity - is this with the mtime-changes setting
On Tue, Jul 16, 2013 at 03:17:10PM +0200, Stephan Beal wrote:
On Tue, Jul 16, 2013 at 2:51 PM, Joerg Sonnenberger jo...@britannica.bec.de
wrote:
Just a matter of scale :) Essentially, the problem is that t(fossil
update) = O(files in the working copy), when it should be O(files
Hi, all,
i've just added week-of-year (a.k.a. calendar week[1]) support to
/stats_report and /timeline:
http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report?view=byyear
and i'm looking for input on the following:
a) When showing by-week links for the combined year/month view it's
On Tue, Jul 16, 2013 at 5:57 PM, Stephan Beal sgb...@googlemail.com wrote:
b) If someone with a better eye for design (that'd be just about anyone!)
can suggest a less ugly/cramped presentation for how the week numbers are
listed (see the first link above), i'd likewise be much obliged.
This looks cool. Will this data be available via the json interface? Being
able to aggregate the stats over a lot of different fossils would be useful
to some of us.
On Tue, Jul 16, 2013 at 9:10 AM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jul 16, 2013 at 5:57 PM, Stephan Beal
On Tue, Jul 16, 2013 at 6:49 PM, Matt Welland estifo...@gmail.com wrote:
This looks cool. Will this data be available via the json interface? Being
able to aggregate the stats over a lot of different fossils would be useful
to some of us.
The thought has crossed my mind, but i haven't
On Tue, Jul 16, 2013 at 6:49 PM, Matt Welland estifo...@gmail.com wrote:
This looks cool. Will this data be available via the json interface? Being
able to aggregate the stats over a lot of different fossils would be useful
to some of us.
New version:
Very cool, Stephan!
On Jul 16, 2013 1:30 PM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Jul 16, 2013 at 6:49 PM, Matt Welland estifo...@gmail.com wrote:
This looks cool. Will this data be available via the json interface?
Being able to aggregate the stats over a lot of different
On Tue, Jul 16, 2013 at 5:57 PM, Stephan Beal sgb...@googlemail.com wrote:
b) If someone with a better eye for design (that'd be just about anyone!)
can suggest a less ugly/cramped presentation for how the week numbers are
listed (see the first link above), i'd likewise be much obliged.
Of top of head, reflexive position is that week numbers are running in
wrong order, but if it's reversed, latest would be at bottom of page. That
made me wonder though, what of vertical bars vs. horizontal?
Just tossing ideas...
On Jul 16, 2013 1:50 PM, Stephan Beal sgb...@googlemail.com wrote:
Hello,
After giving a little though to handling shared SSH accounts, it might
be as simple as the following change:
https://www.fossil-scm.org/index.html/info/7a10b79a2c
Basically, if the specified SSH command already has an '@' in it, don't
use the username@host found in the URL, but use
14 matches
Mail list logo
