Hiho,
On Fri, Jan 11, 2013 at 9:04 PM, j. v. d. hoff wrote:
> e.g. for the fossil repo itself (as of today at e4ca677a6c), `fossil info'
> reports
>
> checkin-count: 4845
>
> however, I do see a total (files+wiki+ticket) of 8799 checkins and
>
> fossil time -t ci -n 1|grep ^[0-9]|wc -l
> yi
On Sun, 13 Jan 2013 11:38:17 +0100, Stephan Beal
wrote:
Hiho,
hi,
the numbers I'm going to report refer to this night's `a0dd5' being at the
top (I presume that's the same state you are looking on?):
On Fri, Jan 11, 2013 at 9:04 PM, j. v. d. hoff
wrote:
e.g. for the fossil repo i
On Sun, Jan 13, 2013 at 12:43 PM, j. v. d. hoff
wrote:
> it's banal: the `-n' flag does not at all specify the _number_ of timeline
> entries to show (which one would expect!) but rather (probably) the total
> number of lines
>
Ah, right - i had forgotten about that (the JSON timeline is the one
just my 2 cents:
1.
I agree that it should be easier (or occuring even automatically?) to
merge such random forks. the `monotone' example was given. `hg' is another
obvious one doing that painlessly.
2.
I agree that improvement of the CLI is not given enough attention in
comparison to the
On Sun, Jan 13, 2013 at 12:58 PM, Stephan Beal wrote:
> i'll get the wiki/ticket counts added to the "info" page, but want to get
> an OK from DRH before i change the commit count calculation (though my
> analysis confers with yours - that the current count is not quite correct
> or is "correct fo
On Sun, 13 Jan 2013 12:58:10 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 12:43 PM, j. v. d. hoff
wrote:
it's banal: the `-n' flag does not at all specify the _number_ of
timeline
entries to show (which one would expect!) but rather (probably) the
total
number of lines
Ah, righ
On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote:
>
>
>
> On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote:
>
>
> Curious response. Did you intend to be insulting? I'm working with a bunch
> of very smart people
>
No insult intended. It's the smart people who have the greatest tendency
t
On Sun, 13 Jan 2013 13:06:25 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 12:58 PM, Stephan Beal
wrote:
i'll get the wiki/ticket counts added to the "info" page, but want to
get
an OK from DRH before i change the commit count calculation (though my
analysis confers with yours - th
uuhps, hit the send buttom to early:
On Sun, 13 Jan 2013 13:06:25 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 12:58 PM, Stephan Beal
wrote:
i'll get the wiki/ticket counts added to the "info" page, but want to
get
an OK from DRH before i change the commit count calculation (tho
On Sun, Jan 13, 2013 at 1:20 PM, j. v. d. hoff wrote:
> why is this?
i can't say with certainty - my insight into sqlite's internals is very
limited.
> I do of course see this delay when grepping through the whole timeline
> (and my initial wish was motivated by the hope that the relevant info
On Sun, 13 Jan 2013 13:38:45 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 1:20 PM, j. v. d. hoff
wrote:
why is this?
i can't say with certainty - my insight into sqlite's internals is very
limited.
mine is zero.
I do of course see this delay when grepping through the whole
On Sun, 13 Jan, Stephan Beal wrote:
> stephan@tiny:~/cvs/fossil/fossil$ f stat
> Repository Statistics:
> Repository Size: 35969024 bytes (36.0MB)
> Number Of Artifacts: 19497 (stored as 5369 full text and 14128 delta
> blobs) Uncompressed Artifact Size: 52103 bytes average, 4993770 bytes
> max,
On Sun, Jan 13, 2013 at 2:16 PM, j. v. d. hoff wrote:
> In this case this basic information would always be "simply there".
> otherwise time required for generating this information obviously does
> scale very badly for big projects. but maybe this is too naive?
>
That's the question - whether th
On Sun, Jan 13, 2013 at 2:21 PM, Stefan Bellon wrote:
> one thing about fossil I dislike most is the inconsistent naming of
> switches (double-minus vs. single-minus vs. short)
BTW: fossil treats -x and --x equivalently. Which one you use is a matter
of personal preference.
> as well as the
On Sun, 13 Jan 2013 14:21:23 +0100, Stefan Bellon
wrote:
On Sun, 13 Jan, Stephan Beal wrote:
stephan@tiny:~/cvs/fossil/fossil$ f stat
Repository Statistics:
Repository Size: 35969024 bytes (36.0MB)
Number Of Artifacts: 19497 (stored as 5369 full text and 14128 delta
blobs) Uncompressed Art
On Sun, Jan 13, 2013 at 2:41 PM, Stephan Beal wrote:
>
>> I hope you can take that into consideration when implementing the final
>> statistics command.
>>
>
> Yes, of course :). i appreciate your feedback.
>
See attached (if the list doesn't remove it), ignoring the question of
"which commit c
On Sun, 13 Jan 2013 14:37:38 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 2:16 PM, j. v. d. hoff
wrote:
In this case this basic information would always be "simply there".
otherwise time required for generating this information obviously does
scale very badly for big projects. but m
See attached (if the list doesn't remove it), ignoring the question of
"which commit count is correct" for the moment.
I would exclude the headline (Repository Statistics:) from column width
computation (so reducing the white space amount between keys and values).
otherwise I like this colu
On Sun, 13 Jan, Stephan Beal wrote:
> See attached (if the list doesn't remove it), ignoring the question of
> "which commit count is correct" for the moment.
I'd lose the "Repository Statistics:" headline as well because it is
just a repetition of the command issued. A "timeline" command e.g. do
another minor thing: to decide whether to count the revisions starting
from 0 ("offset relative to initial checkin") or from 1.
j.
On Sun, 13 Jan 2013 14:58:09 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 2:41 PM, Stephan Beal
wrote:
I hope you can take that into considerat
On Sun, Jan 13, 2013 at 3:13 PM, j. v. d. hoff wrote:
> I would exclude the headline (Repository Statistics:) from column width
>> computation (so reducing the white space amount between keys and values).
>
>
i didn't use that column for width determination - i used hard tabs and let
the terminal
looks good
On Sun, 13 Jan 2013 15:42:22 +0100, Stephan Beal
wrote:
On Sun, Jan 13, 2013 at 3:13 PM, j. v. d. hoff
wrote:
I would exclude the headline (Repository Statistics:) from column width
computation (so reducing the white space amount between keys and
values).
i didn't use th
In my opinion, the solution is more simple. Instead of:
- sync
- stop if would fork
- commit
- sync
The procedure should be:
- commit
- sync
- rollback if would fork
Ramon Ribó
El 13/01/2013 13:11, "Richard Hipp" va escriure:
>
>
> On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote:
>
>>
>>
On Sun, Jan 13, 2013 at 5:10 AM, Richard Hipp wrote:
>
>
> On Sun, Jan 13, 2013 at 1:45 AM, Matt Welland wrote:
>
>>
>>
>>
>> On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp wrote:
>>
>>
>> Curious response. Did you intend to be insulting? I'm working with a
>> bunch of very smart people
>>
>
> N
On Sun, 13 Jan, j. v. d. hoff wrote:
> (Incidentally I did already put that one into the new wiki page
> http://www.fossil-scm.org/fossil/wiki?name=Wish+List today)
While I agree with some points on the wish list, I strongly object to
the first one. If the user insist with "force" to commit wit
On Sun, 13 Jan 2013 18:48:30 +0100, Stefan Bellon
wrote:
On Sun, 13 Jan, j. v. d. hoff wrote:
(Incidentally I did already put that one into the new wiki page
http://www.fossil-scm.org/fossil/wiki?name=Wish+List today)
While I agree with some points on the wish list, I strongly object to
t
On Sun, Jan 13, 2013 at 3:52 PM, j. v. d. hoff wrote:
> looks good
The word came down from DRH that this is the correct SQL to use for
counting commits:
SELECT COUNT(*) from event where where type='ci';
and Richard cannot off-hand explain the 40-some-odd difference between that
and the "mlin
On Sun, 13 Jan 2013 13:17:46 +0100, "j. v. d. hoff"
wrote:
> yes, fossil naming scheme is somewhat ideosyncratic `st' should be the
> canonical "name" for `timeline; anyway in order not to put off svn and hg
> users ;-)
Idiosyncratic? I think it is beautifully simple:
When you write the e
On Sun, 13 Jan 2013 16:35:11 +0100, Ramon Ribó wrote:
> In my opinion, the solution is more simple. Instead of:
>
> - sync
> - stop if would fork
> - commit
> - sync
>
> The procedure should be:
>
> - commit
> - sync
> - rollback if would fork
There is no rollback, an commit has been done. I
On Sun, 13 Jan 2013 18:48:30 +0100,
Stefan Bellon wrote:
> Just for example: In my case, fossil is used in an automated environment
> to store certain states of files. This is completely automated.
Then you are using fossil for a purpose for which it was not designed.
Lots of people use lots of
On Sun, 13 Jan 2013 07:48:59 +0200,
John Found wrote:
> On Sat, 12 Jan 2013 21:22:28 -0800
> "Michael L. Barrow" wrote:
>
> >
> > Please stop trolling
> >
>
> I am not trolling.
I am prepared to believe you but I can see how tone and content might
make people believe that.
> It is "Redu
>There is no rollback, an commit has been done. I >suppose you mean
>to reverse the commit
I know it is not there. This is exactly the reason for me to write this
email.
My proposal would of course require some kind of rollback or undo for the
commit that would be automatically executed when dete
On Sun, 13 Jan 2013 20:12:09 +0100, Eric wrote:
On Sun, 13 Jan 2013 13:17:46 +0100, "j. v. d. hoff"
wrote:
yes, fossil naming scheme is somewhat ideosyncratic `st' should be the
canonical "name" for `timeline; anyway in order not to put off svn and
hg
users ;-)
Idiosyncratic? I think
On Sun, 13 Jan 2013 20:36:50 +0100, Ramon Ribó wrote:
> >There is no rollback, an commit has been done. I >suppose you mean
> >to reverse the commit
>
> I know it is not there. This is exactly the reason for me to write this
> email.
Sorry for being less than clear - I mean that a rollback is n
On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp wrote:
>
> http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg
>
> I'll see what I can do about enhancing Fossil with an "approaching puma"
> warning (warnings that a fork has occurred) and a "shoot puma with sidearm"
> comma
On Sun, Jan 13, 2013 at 6:58 PM, Richard Hipp wrote:
>
> On Sun, Jan 13, 2013 at 7:10 AM, Richard Hipp wrote:
>
>>
>> http://chronicleoutdoors.com/wp-content/gallery/cougar-photo/mountainlion.jpg
>>
>>
>> I'll see what I can do about enhancing Fossil with an "approaching puma"
>> warning (warnin
36 matches
Mail list logo
