from:"j. v. d. hoff"


On Mon, 28 Jan 2013 19:46:13 +0100, Richard Hipp  wrote:


I think another point is that the Lua regexp does not do anchoring (or at
least I didn't see it - did I miss something?)


see also here (from http://www.lua.org/pil/20.4.html):

Usually, pattern matching is efficient enough for Lua programs: A Pentium  
333MHz (which is not a fast machine by today's standards) takes less than  
a tenth of a second to match all words in a text with 200K characters (30K  
words). But you can take precautions. You should always make the pattern  
as specific as possible; loose patterns are slower than specific ones. An  
extreme example is '(.-)%$', to get all text in a string up to the first  
dollar sign. If the subject string has a dollar sign, everything goes  
fine; but suppose that the string does not contain any dollar signs. The  
algorithm will first try to match the pattern starting at the first  
position of the string. It will go through all the string, looking for a  
dollar. When the string ends, the pattern fails for the first position of  
the string. Then, the algorithm will do the whole search again, starting  
at the second position of the string, only to discover that the pattern  
does not match there, too; and so on. This will take a quadratic time,  
which results in more than three hours in a Pentium 333MHz for a string  
with 200K characters. You can correct this problem simply by anchoring the  
pattern at the first position of the string, with '^(.-)%$'. The anchor  
tells the algorithm to stop the search if it cannot find a match at the  
first position. With the anchor, the pattern runs in less than a tenth of  
a second.


Beware also of empty patterns, that is, patterns that match the empty  
string. For instance, if you try to match names with a pattern like '%a*',  
you will find names everywhere:

i, j = string.find(";$%  **#$hello13", "%a*")
print(i,j)   --> 1  0
 In this example, the call to string.find has correctly found an empty  
sequence of letters at the beginning of the string.


It never makes sense to write a pattern that begins or ends with the  
modifier `-´, because it will match only the empty string. This modifier  
always needs something around it, to anchor its expansion. Similarly, a  
pattern that includes '.*' is tricky, because this construction can expand  
much more than you intended.



--
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] howto `grep' through old revisions

On Mon, 28 Jan 2013 19:40:17 +0100, Joerg Sonnenberger  
 wrote:

On Mon, Jan 28, 2013 at 07:26:32PM +0100, j. v. d. hoff wrote:

On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger
 wrote:

>On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:
>>On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
>> wrote:
>>
>>>On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
>>>>The regular expression matching in
>>>>www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also
>>>>lightweight and it
>>>>supports | and it is usually as fast or faster than grep in my tests
>>>>(though there are some cases for which grep is faster).  The
>>regexp.c in
>>>>fossil uses a NFA which gives worst case performance of O(NM)
>>where N is
>>>>the size of the input text to be matched and M is the size of
>>>>the regular
>>>>expression.  Perl regular expressions and lua-regexp.c take
>>exponential
>>>>time for some (admittedly obscure) regular expressions.  On the
>>>>other hand,
>>>>Perl regular expressions are more complete, and both Lua and
>>>>Perl allow you
>>>>to do substitutions, which the regexp.c file in Fossil does not.
>>>
>>>The Lua implementation starts to perform very badly as soon as you  
have

>>>wild cards at the beginning of the pattern. Those aren't even
>>obscure...
>>
>>just a guess: you did not "anchor" the pattern, i.e. you used
>>something like ".*foo" instead of "^.*foo"?
>
>Anchoring doesn't help if you want to explicitly match wild card chars
>at or near the beginning. With a NFA or DFA based implementation, it

I'm too slow: could you give an example where anchoring would come
in the way of what you really want to match?

You don't understand me. Anchoring helps, if you can use it to avoid

right. as I said: I'm too slow.

initial wild cards or limit the length of backtracking. It doesn't help
to avoid the exponential edge cases with .*foo patterns though.

I understand/know that ".*foo"  will take (too) much time. my  
point/question is/was:
"^.*foo" seemingly matches everything which is matched by ".*foo". (and if  
matching is greedy (is that the term?), than
".*foo" would also return exactly the same matching string as "^.*foo",  
making the two actually equivalent patterns, if I understand correctly).

but in any case if the question is simply
"match or no match?" (we are not talking about capturing subexpressions  
and doing
substitutions but "grepping" functionality for fossil, right?), the  
anchored pattern
could always serve as a dropin replacement of ".*foo", AFAICS (even if the  
reverse where not true).

this would not prevent,
that people run into the exponential run time problem when using the  
"naive" pattern instead the anchored one, but this could be explained by a  
FAQ entry making

the problem practically irrelevant. or do I still miss the relevant point?

j.

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

--
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] howto `grep' through old revisions


On Mon, 28 Jan 2013 19:46:13 +0100, Richard Hipp  wrote:

On Mon, Jan 28, 2013 at 1:40 PM, Joerg Sonnenberger  

wrote:




You don't understand me. Anchoring helps, if you can use it to avoid
initial wild cards or limit the length of backtracking. It doesn't help
to avoid the exponential edge cases with .*foo patterns though.




I think another point is that the Lua regexp does not do anchoring (or at
least I didn't see it - did I miss something?)


you mean in the pattern syntax? then
see, e.g., here: http://www.lua.org/pil/20.2.html and search for "anchor":
lua uses the same syntax as standard regexp for this, e.g.

"^.*foo" means "search for anything at beginning of line followed by foo"




FWIW, the regexp.c code already present in Fossil does not need anchoring
to avoid exponential blowup, since it uses an NFA.  However, it does use
anchoring as a performance optimization, to avoid running the NFA over
every byte of input text.  The NFA is linear in the size of input, but  
the
constant of proportionality is large relative to memcmp() so we like to  
use
memcmp()-based anchoring to avoid having the NFA look at every single  
byte

of input.




--
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] howto `grep' through old revisions

On Mon, 28 Jan 2013 18:22:42 +0100, Joerg Sonnenberger  
 wrote:



On Mon, Jan 28, 2013 at 06:09:57PM +0100, j. van den hoff wrote:

On Mon, 28 Jan 2013 17:34:44 +0100, Joerg Sonnenberger
 wrote:

>On Mon, Jan 28, 2013 at 08:50:56AM -0500, Richard Hipp wrote:
>>The regular expression matching in
>>www.fossil-scm.org/fossil/artifact/c8fb75a1615f is also
>>lightweight and it
>>supports | and it is usually as fast or faster than grep in my tests
>>(though there are some cases for which grep is faster).  The regexp.c  
in
>>fossil uses a NFA which gives worst case performance of O(NM) where N  
is

>>the size of the input text to be matched and M is the size of
>>the regular
>>expression.  Perl regular expressions and lua-regexp.c take  
exponential

>>time for some (admittedly obscure) regular expressions.  On the
>>other hand,
>>Perl regular expressions are more complete, and both Lua and
>>Perl allow you
>>to do substitutions, which the regexp.c file in Fossil does not.
>
>The Lua implementation starts to perform very badly as soon as you have
>wild cards at the beginning of the pattern. Those aren't even  
obscure...


just a guess: you did not "anchor" the pattern, i.e. you used
something like ".*foo" instead of "^.*foo"?


Anchoring doesn't help if you want to explicitly match wild card chars
at or near the beginning. With a NFA or DFA based implementation, it


I'm too slow: could you give an example where anchoring would come in the  
way of what you really want to match?


j.

will add some processing time, but the linear performance is still
guaranteed.

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



--
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] Newly introduced inconsistency

2013-01-17 Thread j. v. d. hoff

On Thu, 17 Jan 2013 13:45:36 +0100, Stephan Beal   
wrote:


however, in the fossil repo (as of today) I get these number of  
checkins:


timeline: 4905
dbstat  : 4906
info: 4860

i.e. in this single repo there is a difference of one between timeline  
and

dbstat seemingly hinting at
a specific bug either in the code or in the database I guess.

The difference is repo-specific. In the fossil repo (old/large) the diff  
is

relatively large. In my own repos (smaller/younger) the difference is


there is an additionally specific problem (not seen with other repos) that
the number of `timeline' entries is off by one relative to the `dbstat'  
opinion

of the number of checkins.

smaller (anywhere from 1 to 10 or so). The difference we see here is due  
to
using different counting queries, but whether or not this difference is  
due

to a bug or is actually as-designed is not yet clear. For the near-term
future they will differ, until i can figure out if the "mlink" table is
being mis-used somewhere (i.e. if there's a bug).



--
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] timeline bug?

2013-01-16 Thread j. v. d. hoff

for completeness sake: did not hit 'reply all' the first time (thus  
skipped replying to the list), so here it is.


On Wed, 16 Jan 2013 20:55:48 +0100, Eric  wrote:

On Wed, 16 Jan 2013 17:48:52 +0100, "j. van den hoff"  
 wrote:

hi,

incidentally (when calling fossil from with a script constructing the
suitable call) I noted that

+fossil timeline ''+

(i.e. appending an empty string '' after `timeline') shows the timeline
below (and including *CURRENT*) instead of below the most recent  
checkin.

therefore, output is different
if *CURRENT* is not identical to leave.

is this a bug or a feature? I do hope the former since it's really bad
behaviour when driving `fossil' with a script.


I don't get it. No-one would ever put that on the commandline, and if
you are writing a script to construct and run the command, why would you
ever construct that? If it's a consequence of having no other parameters
just make your script check for that and avoid putting in an empty  
string.


It makes no sense to me that you are generating something that makes no


what makes not sense to you is that you don't know the use case. the rest
(whether what I do makes sense or not) is not for you to judge, given this
information deficit, I'd say. anyway, I _know_ that I can
catch the exception, thank you very much. it's just an annoyance to have
to when the command line parser could/should do it.

so,
maybe the developers can decide whether it's worth to fix this behaviour
which
I tend to call a bug (which is not altered by the fact that one can work
around it).

there is a difference between a working CLI interface and a nice one. and
fossil's CLI
is not its strongest point I'd say. I believe quite some people have
observed
that already. the GUI seemingly has been given much more "love and
attention", since
it _is_ really nice.

some random examples:

-- fossil timeline -n11  (silently fails)
-- fossil timeline -n 11 does by no means show the last 11 checkins
-- fossil timeline -showfile (silently fails)
-- no chance to keep track of the DAG in the `timeline' output
-- sometimes revisions need a -r flag, sometimes they don't
-- fossil timeline does show a finite subset of revisions but `fossil
finfo filename' does show them all
-- `-n' of `timeline' is called (sort of) `--limit' by `finfo'
-- etc. etc. etc.

for me there are loads of individually small (but cumulative
non-negligible) annoyances which it would be nice _not_ to have. and
observing that this is so should not trigger "knee-jerk" defenses of the
status quo along the line
"what you do makes no sense therefore the current behaviour is good". and
"fix it yourself" is not _that_ helpful either ;-)

j.


sense.

Eric



--
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] `fossil info' feature request (a.k.a. wish)


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 it is beautifully simple:

When you write the entry C-function for a command, you put a comment
line like

  **   COMMAND:  cmdname

Above it. You can put more than one to give the command multiple names.
Then at build time the mkindex utility builds a constant table used to
map command names into functions.

When you type "fossil xy", that table is searched for entries beginning
with xy. If there is only one, it is run, if there is more than one
fossil tells you what they are and quits.

You are suggesting making a non-unique prefix run a totally different


no I don't -- saw the smiley?


command. How much confusion is that going to cause?

Actually you are suggesting changing fossil to make it more like some
other program, and you know _my_ opinion of that.

In any case, it doesn't work. There is no "canonical". Unless one program
is a clone of another there will not be a complete 1-1 mapping between
commands, so you can't make all the commands have the same names.

Eric



--
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] `fossil info' feature request (a.k.a. wish)

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
the first one. If the user insist with "force" to commit without a
commit message, then the tool should not try to be smart and prohibit
the commit. As long as it will not cause operational problems for the
tool itself, it is always wrong if the tool tries to be smarter than
the user. Even more so if the user explicitly stated "yes, I know, but
that's what I want".

Just for example: In my case, fossil is used in an automated environment
to store certain states of files. This is completely automated. Those
commits of course could get the date/timestamp as commit message, but
that would be redundant, so why should a commit message be forced in
such automated environments? It does not make sense. Do not assume your
workflow or setup for everybody else.

If the tool does not need the information, do not enforce its presence!


I don't claim/believe that all points on the list will qualify for a  
"majority vote". I've just collected them and put them there due to drh's  
suggestion (with some misgivings that it would cause partly too much  
"noise" afterwards on the list -- your mail explicitely _not_ rated as  
such, but let's see what else will come up...).


regarding the issue at hand, from my perspective, in _interactive_ use I  
_never_ want an empty commit message (nor should anybody _want_ this,  
right?), so interpretation of leaving the commit-message-editor directly  
without any edits as aborted commit (notifying the user to that extent  
automatically) is very sensible (I like this behaviour, e.g. in `hg'). but  
I simply don't like to answer a (for me) redundant question, whether I  
really want to abort or not when I _do_ decide to abort the commit and,  
therefore, leave the editor immediately again. for your use case a new  
`-f(orce)' flag for `ci' to enforce commit without ci message would sure  
achieve what you (and maybe others) want (and that would be the machine  
"typing" too much, not me ;-)).


making the behaviour user configurable (e.g. via `set') might be another  
idea.


anyway, I _don't_ have too strong feelings about this point.

j.



Greetings,
Stefan




--
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] `fossil info' feature request (a.k.a. wish)


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 that column for width determination - i used hard tabs and  
let

the terminal figure it out (which means it will probably break on Windows
;). Using only 1 tab isn't cutting it, though, because server-id is too
short. i'll remove that top line, though - Stefan's argument that it is
redundant sounds good to me.

@Stefan: the argument for "wikipage" instead of "wiki-page" - i'm not
convinced that that would simplify anything, but this feature is for you
guys, so i've changed that, too.

...

i've re-done the spacing to use normal spaces instead of tabs, so it now
looks like:

stephan@tiny:~/cvs/fossil/fossil$ f dbstat
repository-size:35969024 bytes (36.0MB)
artifact-count: 19497 (stored as 5369 full text and 14128 delta  
blobs)

artifact-sizes: 52103 bytes average, 4993770 bytes max, 1015763428
bytes (1.0GB) total
compression-ratio:  28:1
checkin-count:  4846
file-count: 749 (4890 changes)
wikipage-count: 23 (282 changes)
ticket-count:   990 (3137 changes)
project-age:2004 days or approximately 5.49 years.
project-id: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
server-id:  c7d762ef2a202474a9d04a38050f1c789b2fc771
fossil-version: 1.25 2013-01-13 02:01:18 [a0dd51e9af] (gcc-4.7.2)
sqlite-version: 2013-01-09 11:31:17 [5774f2175c] (3.7.16)
database-stats: 35126 pages, 1024 bytes/page, 1076 free pages, UTF-8,
delete mode

(line-wrapping is the mail client)




--
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] `fossil info' feature request (a.k.a. wish)

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 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 count is correct" for the moment.

:-?

PS: i like the name "stats" better, but don't want to break anyone's
"stat"=="status" habit :/.




--
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] `fossil info' feature request (a.k.a. wish)




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 column-adjusted output better than the
irregular "default". actually, I think several fossil commands (notably  
info and stat) could profit from the same beautification.




:-?

PS: i like the name "stats" better, but don't want to break anyone's
"stat"=="status" habit :/.


+1

(and `dbs' would be a nice acronym).






--
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] `fossil info' feature request (a.k.a. wish)

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 maybe this is too naive?



That's the question - whether that's too naive or not. My gut feeling is
that the cache could easily get out of sync, but i could be quite wrong.  
We

might also have problems with _other_ operations becoming arbitrarily
longer because of the addition of cache re-calculation.

I could even imagine

...numbers would become supported in relevant fossil commands such as
`diff', `merge', etc. this might of course be all nonsense and not in
accord with the actual design of fossil...



That's a topic i'm trying personally to stay away from because i think  
it'd

be a messy divergence from fossil's world view. That doesn't in any way


don't really know about this "world view".


mean the idea is rejected, it just means i personally don't like it.


which is fine, of course. I've simply noted that in approx 5 years of `hg'  
usage (which supports, both, hashes and rev. nums) I've never ever used  
once the hash directly. rev. nums are so much easier to type and memorize.  
if they don't come at some point in the future, it's OK (since not _that_  
important), but in terms of ease of CLI use it is a disadvantage, I'd  
maintain.






looks fine. cosmetic proposal: probably left-adjusted two column
(key/value) output would be easier to read (i.e. align everything in the
"value" column to match the space required by the longest key name
(Duration of Project in the above output, that is) and don't wrap long
lines.



The wrapping was either my console or gmail. i tried aligning but the  
wide

variation in labels and values just looked funny to me. i'll try


not a big issue anyway.


diverging
from the /stat-derived labels and move to something more  
machine-readable,
analog to how the "info" command works. i've also renamed it to dbstat,  
per
your suggestion. On the dev list i've posted the question about which  
query

is correct for the commit counts (and why), so hopefully we'll hear a
definitive answer from Richard on that.

Number Of Check-ins: 4890



Number Of Files: 749






I think the _total_ number of all checkins might also be helpful since
this would be the relevant number if chronological revision numbers  
would

occur at some point in the future.



The output currently uses both calculations:

Number Of Check-ins: 4846
Number Of Files: 749 (4890 changes)


what I actually meant is "number of file changes plus number of wiki  
changes + ...", i.e. the cumulative count of all date/time-tagged entries  
in the full timeline output. if there is a nomenclature problem lurking  
here, one might disambiguate via "tot. number of timeline entries" or  
similar but that _should_ be synonymous to
number of checkins AFAICS. anything else would at least be rather  
counter-intuitive in my view.




but i don't see how those line up, numerically speaking (more changes  
than

checkins?). Richard will be able to explain to us those two different
values and what they _really_ mean. The first one uses the calculation  
from

the /stat page and the second one uses a query against 'ci' events.

in my view, yes. or rather either use "commits" also for Wiki and Tickets

or use "changes" for `Files', too. I'd prefer "checkins" everywhere,
actually).



i'm currently using "changes" because i want to avoid any confusion with
any formal definition of commit/checkin.

Once the question regarding commit/checkin counting is clarified i'll get
this "change" "checked in."




--
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] `fossil info' feature request (a.k.a. wish)

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 Artifact Size: 52103 bytes average, 4993770 bytes
max, 1015763428 bytes (1.0GB) total
Compression Ratio: 28:1
Number Of Check-ins: 4890
Number Of Files: 749
Number Of Wiki Pages: 23 (282 changes)
Number Of Tickets: 990 (3137 changes)
Duration Of Project: 2003 days or approximately 5.48 years.
Project ID: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
Server ID: c7d762ef2a202474a9d04a38050f1c789b2fc771
Fossil Version: 1.25 2013-01-13 02:01:18 [a0dd51e9af] (gcc-4.7.2)
SQLite Version: 2013-01-09 11:31:17 [5774f2175c] (3.7.16)
Database Stats: 35126 pages, 1024 bytes/page, 1076 free pages, UTF-8,
delete mode


I like this idea a lot!

However I beg for more thinking about the names used in the output. The
one thing about fossil I dislike most is the inconsistent naming of
switches (double-minus vs. single-minus vs. short) as well as the


+1

(Incidentally I did already put that one into the new wiki page  
http://www.fossil-scm.org/fossil/wiki?name=Wish+List today)



inconsistent output of its commands. While this may not be that
annoying when using the web it is when using the command line and it
is even more when doing script automation using the command line
interface.

For example the output of "fossil info" (and "status", etc.) is in style

project-name: ...
project-code: ...

whereas after a commit you get the following response

New_Version: ...

There's a difference in casing and usage of hyphen versus underscore.
When I started using fossil I was expecting something like

checkout: ...

as response from the "commit" command to be in stylistic and
terminology sync with the other outputs (especially "status").

Regarding the new "stat" (or "stats"?) command I'd very much like to
see it matching the already existing output styles rather than invent a
new one:

repository-size: ...
artifact-count: ...
compression-ratio: ...
checkin-count: ...
file-count: ...
wiki-count: ...
ticket-count: ...
project-uptime: ...
project-id: ...
server-id: ...
fossil-version: ...
sqlite-version: ...
database-stats: ...

Or something similar to that (I'm not suggesting the final names here,
just the style to use).

I hope you can take that into consideration when implementing the final
statistics command.

Greetings,
Stefan




--
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] `fossil info' feature request (a.k.a. wish)

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 timeline
(and my initial wish was motivated by the hope that the relevant info is
"just there" in the database), but I would have thought the relevant
statistics is already in the database. and if not so: why not at a small
table containing these statistics?



As a general rule (perhaps not consciously) fossil doesn't cache what it
can calculate. There are a few instances where it builds an internal temp
table as a form of cache, but those are few and far between. We don't
(yet?) have a generic mechanism/API for caching in fossil. For this
particular calculation, it would be easy for the cache to get out of sync
if someone adds a feature which modifies the values it depends on.


I was actually thinking about the possibility of adding/augmenting a  
suitable table either in the repo itself or in .fslckout (the latter  
probably is more reasonable?), which is brought up-to-date with each new  
commit/pull/update/sync of the repo (that is maintain a few  
autoincrementing counters, basically).

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?


I could even imagine
that this (new?) table could also hold two associative array where the  
keys(values) are the SHA1 hashes and the values(keys) the chronological  
revision number if such rev. numbers cannot be fitted easily in the real  
machinery. such arrays could then be queried to get translate between rev.  
nums and SHA1 hashes if rel. rev.
numbers would become supported in relevant fossil commands such as `diff',  
`merge', etc. this might of course be all nonsense and not in accord with  
the actual design of fossil...




Here's a first draft, basically the same as the /stat page, reformatted  
for

the console, using the "other" commit count calculation, and adding
wiki/ticket change counts:

stephan@tiny:~/cvs/fossil/fossil$ f stat --brief
Repository Statistics:
Repository Size: 35969024 bytes (36.0MB)
Duration Of Project: 2003 days or approximately 5.48 years.
Project ID: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
Server ID: c7d762ef2a202474a9d04a38050f1c789b2fc771
Fossil Version: 1.25 2013-01-13 02:01:18 [a0dd51e9af] (gcc-4.7.2)
SQLite Version: 2013-01-09 11:31:17 [5774f2175c] (3.7.16)
Database Stats: 35126 pages, 1024 bytes/page, 1076 free pages, UTF-8,
delete mode


looks fine. cosmetic proposal: probably left-adjusted two column  
(key/value) output would be easier to read (i.e. align everything in the  
"value" column to match the space required by the longest key name  
(Duration of Project in the above output, that is) and don't wrap long  
lines.





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,
1015763428 bytes (1.0GB) total
Compression Ratio: 28:1
Number Of Check-ins: 4890
Number Of Files: 749
Number Of Wiki Pages: 23 (282 changes)
Number Of Tickets: 990 (3137 changes)
Duration Of Project: 2003 days or approximately 5.48 years.
Project ID: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
Server ID: c7d762ef2a202474a9d04a38050f1c789b2fc771
Fossil Version: 1.25 2013-01-13 02:01:18 [a0dd51e9af] (gcc-4.7.2)
SQLite Version: 2013-01-09 11:31:17 [5774f2175c] (3.7.16)
Database Stats: 35126 pages, 1024 bytes/page, 1076 free pages, UTF-8,
delete mode



I think the _total_ number of all checkins might also be helpful since  
this would be the relevant number if chronological revision numbers would  
occur at some point in the future.




The "brief" flag removes any calculations which tend to grow with the  
size

of the repo - basically anything which requires a non-O(1) query.

i should probably(?) change:

Number Of Check-ins: 4890
Number Of Files: 749

to:
Number Of Files: 749 (4890 commits)


in my view, yes. or rather either use "commits" also for Wiki and Tickets  
or use "changes" for `Files', too. I'd prefer "checkins" everywhere,  
actually).


j.



:-?




--
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] `fossil info' feature request (a.k.a. wish)


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 (though my
analysis confers with yours - that the current count is not quite  
correct

or is "correct for some other definition of 'commit'").



Eeek... adding them is simple but they pose another problem: the first  
run
takes about 5 seconds for that query on my netbook. The second, once the  
OS

has cached at the filesystem level, is much faster. Before i go murdering


why is this? 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 is "just there" in the database), but I would have thought the  
relevant statistics is already in the database. and if not so: why not at  
a small table containing these statistics?



the performance of the "info" command it might make sense to add a CLI
version of the "stat" page, with the caveat that that will upset users  
who

currently enter "stat" as a shortcut for "status" (when "stash" was
implemented it upset me because it broke me of my "st"=="status" habit  
;).


Let me think a bit about this, but i think moving this info into a 'stat'
command is the right thing to do.




--
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] `fossil info' feature request (a.k.a. wish)

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 - that the current count is not quite  
correct

or is "correct for some other definition of 'commit'").



Eeek... adding them is simple but they pose another problem: the first  
run
takes about 5 seconds for that query on my netbook. The second, once the  
OS

has cached at the filesystem level, is much faster. Before i go murdering
the performance of the "info" command it might make sense to add a CLI
version of the "stat" page, with the caveat that that will upset users


maybe call it 'dbstat' or whatever in order to avoid the naming collision.

who
currently enter "stat" as a shortcut for "status" (when "stash" was
implemented it upset me because it broke me of my "st"=="status" habit  
;).


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




Let me think a bit about this, but i think moving this info into a 'stat'
command is the right thing to do.




--
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] `fossil info' feature request (a.k.a. wish)

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, right - i had forgotten about that (the JSON timeline is the one i
implemented and it uses -n as the _entry_ count).

sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and

e.type='ci';
4890



I believe that is the correct one for number of file checkins (identical
to the above `wc' output and there was no new file checkin since you  
tried,

I believe).



My gut feeling is that that is the correct (or more correct) value, but
before changing that i need to verify with DRH that that's okay because  
he

(i think) added the commit count in the /stat page and i'd need to change
that one as well (or maybe just change its label).





(note that i skipped over (e.type='g'))



?? which is what if a humble user may ask...??



LOL! i skipped them because i could not remember what they are :/. i see
now, via name.c, that they are "tag change" events.


ah! bug report: `fossil help timeline' does not say anything about  
existence of a `g' type (and further?) types, although it accepts the flag  
(and reports	287

entries in the present example).



so what would be nice to have the separate checkin types reported  
separatly

(and mabye, though redundant also cumulatively (i.e. the 8802 in this
example). and, as I said, a way to enforce "show whole timeline" would  
be

nice. maybe one could use `fossil timeline -n 0' for that???



The -n 0 flag change appears (to me) to be more difficult than it sounds


well, I'm not a CS guy: I would catch the `0' immediately after parsing  
input and replace it by {some_rediculously_huge_number} just as if I had
entered the huge number in the first place. this would work for the rest  
of the lifetime of the universe, probably.



because that value is part of the calculation for ancestor depth, and
therefore has side effects on the algorithm other than simply the output
length. It appears that when two branches merge, printing "n" revisions
becomes philosophically problematic because one needs to know which
ancestor to crawl back in order to satisfy "n". i'm quite certain i  
didn't

think about that problem at all in the JSON-based timeline command :/.

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


of course.


analysis confers with yours - that the current count is not quite correct
or is "correct for some other definition of 'commit'").


which then would seemingly not be in accord with what a user is wanting to  
know (namely the number of corresponding timeline entries, right?


many thanks for addressing this issue,

j.






--
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] Unintentional fork/race condition


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 GUI and that is especially difficult (not reall  
feasible, that is) to keep track of the branch/fork/merge structure of the  
timeline when solely using the CLI. in this context: some time ago I asked  
the list whether an 'ASCII art' DAG added to the timeline could be added  
(as an option, not as default!) which looks like this in `Mercurial':


8<
@  changeset:   230:ba70fc98b524
|  user:u2
|  date:Thu Dec 02 19:33:36 2010 +0100
|  summary: inclusion of joe's changes, part 3.
|
ochangeset:   229:896e4bf421cc
|\   parent:  228:b577d53d4484
| |  parent:  227:096dd5485186
| |  user:u2
| |  date:Thu Dec 02 17:43:29 2010 +0100
| |  summary: Automated merge with ssh://somehost/somefile
| o  changeset:   228:b577d53d4484
| |  parent:  226:25a0f016d4e5
| |  user:u1
| |  date:Thu Dec 02 17:15:43 2010 +0100
| |  summary: - updated fig.13
| |
o |  changeset:   227:096dd5485186
|/   user:u2
|date:Thu Dec 02 17:43:24 2010 +0100
|summary: intermediate state
|
8<

I believe if such a thing were available, even "militant" CLI users would  
be able to keep track where they are on the graph (`hg' uses the `@' sign  
for *CURRENT*, by the way) and the reported problem would be less  
annoying/confusing. doing this is probably somewhat tedious but at least  
the logic for drawing the graph is already in place and used in the web  
GUI. so maybe it is feasible in finite time...


j.

On Sun, 13 Jan 2013 07:45:51 +0100, Matt Welland   
wrote:



On Sat, Jan 12, 2013 at 5:31 PM, Richard Hipp  wrote:




On Sat, Jan 12, 2013 at 6:41 PM, Matt Welland   
wrote:



This is with regards to the problem described here:


http://lists.fossil-scm.org:8080/pipermail/fossil-users/2008-February/60.html

We are seeing on the order of 3-5 of these a year in our heaviest hit
repos. While this may seem like no big deal the fact that it is so  
silent
is quite disruptive. The problem is that a developer working intently  
on a

problem may not notice for hours or even days that they are no longer
actually working on the main thread of development.



I contend that this points up issues with your development process, not
with Fossil.  If your developers do not notice that a fork has occurred  
for

days, then they are doing "heads down" programming.  They are not
maintaining situational awareness.  (
http://en.wikipedia.org/wiki/Situation_awareness)  They are fixating on
their own (small) problems and missing the big picture.  This can lead
dissatisfied customers and/or quality problems.

"Situational awareness" is usually studied in dynamic environments that
are safety critical, such as aviation and surgery.  Loss of situational
awareness is a leading cause of airplane crashes and medical errors.   
Loss
of situational awareness is sometimes referred to as "tunnel vision".   
The
person fixates on one tiny aspect of the problem and ignores the much  
large

crisis unfolding around him.  Eastern Airlines flight 401 (
http://en.wikipedia.org/wiki/Eastern_Air_Lines_Flight_401) is a classic
example of this: All three pilots of an L-1011 where "working intently"  
on

a malfunctioning indicator light to the point that none of them noticed
that the plane was losing altitude until seconds before it crashed in  
the

Florida Everglades.

Though usually studied in safety critical environments, situational
awareness is applicable in any complex and dynamic problem environment,
such as a developing advanced software.  When you tell me that your
developers are "intently working" on one small aspect of the problem, to
the point of not noticing for several days that the trunk as forked -  
that

tells me that there are likely other far more serious problems that they
are also not noticing.  The fork is easily fixed with a merge.  The  
other
more serious problems might not have such an easy fix.  And they might  
go

undetected until your customer stumbles over them.

So, I would use the observation that forks are going undetected as a
symptom of more serious process problems in your organization, and
encourage you to seek ways of getting your developers to spend more time
"heads up" and looking at the big picture.

(Did you notice - "situational awareness" is kind of a big issue with  
me.
Fossil is my effort at building a DVCS that does a better job of  
promoting

situational awareness that the other popular VCSes out there.  I'm
constantly looking for ways to enhance Fossil to promote better  
situational

awareness.

Re: [fossil-users] `fossil info' feature request (a.k.a. wish)

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




yields 4009.



i just tried that grep and still get the same 4009, though there have  
been

commits since then that time:

stephan@tiny:~/cvs/fossil/fossil$ f time -t ci
=== 2013-01-13 ===
02:01:18 [a0dd51e9af] *CURRENT* Allow the FOSSIL_USER environment  
variable

to
 be used as a fallback when creating a new repository. (user:
 mistachkin tags: trunk)
...

stephan@tiny:~/cvs/fossil/fossil$ f time -t ci -n 1|grep ^[0-9]|wc -l
4009

So apparently there's a flaw with that counting logic (but i don't see  
what

it is off hand).


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
displayed. and `1' simply was to small. so that number has to be  
increased 10 or a 100 times to be on the safe side. (side note: there  
_should_ be a flag/setting for timeline enforcing display of the complete  
timeline I'd say...). so:


`fossil time -t ci -n 100|grep ^[0-9]|wc -l' yields

4890

`fossil info' yields checkin-count: 4846

so there's still a discrepancy.

`fossil time -n 100|grep ^[0-9]|wc -l' yields

8802.







so what is `checkin-count' actually reporting??



i tried a second query for this and get results comparable (but not
identical) to the /stat page:

stephan@tiny:~/cvs/fossil/fossil$ sqlite3 ../fossil.fsl
...
sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='ci';
4890


I believe that is the correct one for number of file checkins (identical  
to the above `wc' output and there was no new file checkin since you  
tried, I believe).




"info" (or the /stat page) says:

stephan@tiny:~/cvs/fossil/fossil$ f info
...
checkin-count: 4846


yes, that's the same number I see.




version: This is fossil version 1.25 [0fb6c829f2] 2013-01-08 16:55:39 UTC

For ticket and wiki modifications i get these numbers:

sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='t';
3137


corresponding `grep|wc' yields the same.


sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='w';
282


corresponding `grep|wc' yields the same.



and events:
sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='e';
4


not derivable from timeline output AFAICS.



For a total number of repository "events" (not to be confused with  
"Event"

entries) of:

sqlite> select count(*) from event;
8802


which again is identical to what the respective `grep|wc' yields (see  
above).




(note that i skipped over (e.type='g'))


?? which is what if a humble user may ask...??






what I currently would find most useful is to see the total number (8799
in the example), but maybe instead a more
detailed statistics (file ci: xxx; wiki ci: , bug ci: ) is also  
of

interest.



The wiki/ticket change counts seem to [me to] be quite unambiguous, but  
i'm

still not sure which of these two queries is "more correct" for file
commits:

sqlite> select count(*) from blob b JOIN event e where b.rid=e.objid and
e.type='ci';
4890


this one.



or

sqlite> SELECT count(distinct mid) FROM mlink;
4846

While the former "seems" to me to be correct, the latter has been in use
since Ancient Times in the /stat page, so i suspect that it is the  
correct

one.


no. the first one is correct according to timeline output.

so what would be nice to have the separate checkin types reported  
separatly (and mabye, though redundant also cumulatively (i.e. the 8802 in  
this example). and, as I said, a way to enforce "show whole timeline"  
would be nice. maybe one could use `fossil timeline -n 0' for that???


j.


Thoughts?




--
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] `fossil info' feature request (a.k.a. wish)

2013-01-11 Thread j. v. d. hoff

On Thu, 10 Jan 2013 13:51:51 +0100, Stephan Beal   
wrote:


On Thu, Jan 10, 2013 at 1:35 PM, Stephan Beal   
wrote:



i'll sign up for adding that - i would be able to do this on Sunday. i
would add it to the "status" command because we have that info in the  
/stat

page already (and in "fossil json stat -full").



Don't tell my boss this, but...

http://fossil-scm.org/index.html/info/acea7010b8

i added the output to "info" instead of "status" because that seemed to  
be

the better place for it (status reports local change status).


I just tested it and I stumbled: the reported checkin count is  
_approximately_ (order of magnitude...) correct
but does _not_ match the actual number of checkins (nor the number of file  
checkins only).


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

yields 4009.

so what is `checkin-count' actually reporting??

what I currently would find most useful is to see the total number (8799  
in the example), but maybe instead a more
detailed statistics (file ci: xxx; wiki ci: , bug ci: ) is also of  
interest.


thanks
j.

ps:
in the long run I would really like to have fossil report chronological  
local revision numbers in the timeline (cumulative across files, wiki,  
tickets)
in addition to the hashes (plus abilitity to use themas "alias" in all  
commands currently requesting specification of hashes). that would be at  
least "nice to have" in order to facilitate interaction with fossil,  
notably when using commands like `diff', `cat', etc.






[stephan@host:~/cvs/fossil/fossil]$ f info
project-name: Fossil
...
checkin-count: 4840





--
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] problem with selecting timeline entries for diffing in the GUI

2013-01-11 Thread j. v. d. hoff


On Fri, 11 Jan 2013 18:57:34 +0100, Richard Hipp  wrote:

On Fri, Jan 11, 2013 at 12:45 PM, j. van den hoff  

wrote:



my question regards the (very useful!) functionality of selecting
(clicking) two timeline entries in the web GUI to the repo for diffing.
this works alright for me with a certain (remote) repository.

it does +not+ work for the local copy of that repo or any other local  
repo

(under URL http://localhost:8080/timeline**), i.e. the first click on a
timeline "square" remains ineffective (no red highlight) as does the  
second

(no diff appearing).

what am I missing?



My guess: you are running an older version of Fossil locally that does  
not

support that feature.  The feature was added recently and has not yet
appeared in a precompiled binary.


ah, yes of course. thank you for clarifying.






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








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

[fossil-users] timeline formatting issue

2012-12-22 Thread j. v. d. hoff


a small thing:

`timeline' does wrap lines even in the middle of the branch name if the  
latter does contain `-', e.g. `my-branch'. might it not be better to  
define word boundaries more restrictively (white space only) in order to  
prevent this? currently, it is, strictly speaking, not possible to decide  
from a single timeline entry whether

the branch name is `my-name' or `my- name' (with blank(s) before `name').
this becomes an issue if one wants to reformat the timeline output  
differently by using a suitable wrapper, e.g. to "unwrap" each entry.


maybe blanks in (newly generated) branch names should be disallowed in the  
future (it's ugly anway)? (no: I'm not proposing to break existing  
repos...)


j.

--
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] PLOS (II)

2012-12-20 Thread j. v. d. hoff


On Thu, 20 Dec 2012 19:37:35 +0100, Mike Meyer  wrote:


On Thu, Dec 20, 2012 at 11:56 AM, j. van den hoff
 wrote:
I would find it far more intuitive if _after_ a `clone' of the above  
sort

(password query for `myname' and all) the corresponding local user would
be created automagically and also be set to the default user so that I'm


Nothing to do with computers is "intuitive". At best, it's familiar
because it acts like something else you had to learn to use.


I don't quite agree but let's not argue.



Personally, I'd be *very* surprised if I cloned a repo and it copied
*any* password information, no matter what auth* was done during the
clone. That's just a huge security faux pas. Creating users without
passwords is even worse.

which again 99.9% of the time should be what the user wants anyway (and  
might be really surprised to not have happened autmatically).


???... in the considered scenario, after the initial (password  
protected/queried) clone I _can_ push and do anything else the respective  
user
is allowed to do "upstreams". the only thing is: all this happens using my  
local $USER name instead of the name chosen for the remote account.
I'm only proposing it would be nice to set up the clone including a local  
user of the remote name as the default user (he might very well get
a different password as far as I can see). what security holes do you see  
here?




I disagree. It might be what the user wants to happen 99% of the time
for local clones, but I'd say that the current default (current login
name) does that 99% of the time as well, without opening up the
possibility of unknowingly handing someone a clone that includes your
password.


if I _can_ push directly after issuing the respective password _once_  
during the initial clone (even if that happens with the "wrong" ID, namely  
the
local $USER ID), the password info necessary for the remote access seems  
to be in the repo anyway, no?




For remote clones - things change. I almost never want the same
password on the two ends (again, a security faux pas) and don't really
care whether or not the username is the same. Given that it takes one
command to create a user & password vs. one command to set the
password, automatically creating the same username with a new password
is at best a meh.


I'm just proposing to automate what you do manually in the considered  
situation (including chosing a different local password, why not?): create  
the user, make him the default, choose some (local) password. where'd be  
the problem?


maybe there _is_ an essential problem but I don't see it. let's stop it at  
that


thx for responding.

j.




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



--
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] Fossil vs. Git/Mercurial/etc.?


On Wed, 19 Dec 2012 01:04:19 +0100, Martin Gagnon  wrote:

On Tue, Dec 18, 2012 at 6:28 PM, j. v. d. hoff  
wrote:



On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp  wrote:

 On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer  wrote:


 I don't do that (I keep all my fossil repositories in ~/repos), so

haven't paid close attention to the issues. The big one seems to be
accidentally trying to add the repository to itself. The resulting
checkin never terminates. I also recall problems with Windows
(something else I don't use) where the solution was to move the
repository out of the work space.

Maybe the people who helped solve the problems can comment on this? Or
maybe my skimming of such problems has led me to a false conclusion.


I think all these problems are fixed and that it is safe to keep the  
repo

in the check-out directory.



relieved to here that, thanks. are there any other valid arguments  
(beyond
matter of taste things like "I want to separate the repo from the  
checkout"
and facilitating backups by putting all repos in a single place) which  
make

it unwise to keep the repo within the checkout?





Capabilities to work on multiple different checkout associated with
different branch/revision/tag using the same repo file.

Example:
-
$ mkdir checkout
$ cd checkout
 ## a checkout for the trunk
$ fossil open ~/repos/a_repo.fossil
 ...
$ cd ..
$ mkdir checkout_some_branch
$ cd checkout_some_branch
 ## a checkout for the branch "some_branch" using the same  
repo

file.
$ fossil open ~/repos/a_repo.fossil some_branch
-

That is a killer feature for me. This is impossible to do with git or hg.
Eg. with git, each checkout have to be a different clone with their own
".git" directory which contain the whole history.


OK, I see what you mean, but this wouldn't be important for me AFAICS.
actually I don't see any real advantage of this approach compared to simply
updating to the respective branches in turn in order to work on them.
so (for me) this would fall under the "matter of taste" category (which
still means it's nice that it can be done).

j.



Regards



--
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] Fossil vs. Git/Mercurial/etc.?

thanks for clarifying this. gonna check the help pages before spamming the  
list again


On Wed, 19 Dec 2012 00:33:29 +0100, Mike Meyer  wrote:


On Wed, 19 Dec 2012 00:02:11 +0100
"j. v. d. hoff"  wrote:
even for small teams I'd prefer to be able to do user management  
(easily)

 from the command line.
so I don't overlook anything if I presume that user management currently
_needs_ to be done
via the web gui?


Nope, it doesn't.


some fossil command like
fossil adduser {basic configuration options go here} user1, user2, ...


It's not quite that easy - you have to mangle one user at a time, and
user creation is it's own command.

would be nice to have. fine-tuning might be delegated to the  
webinterface

but
the basic things (adding admin users, development users etc) should be
possible otherwise.


I'd say it is. It could be better, but it's there. I generally wind up
running a shell loop:

for u in $DEVS ADMINS $READERS
do
  # create user name from company mail address, password is PW.
  fs new $u $u...@company.com PW$u -R $REPO
done

for dev in $DEVS
do
  # Set up developers
  fs cap $dev v -R $REPO
done

Setting up new users in mass doesn't make a lot of sense - you
probably want to set contact information and passwords separately
anyway. Setting permissions (capabilities) for a group would be a nice
enhancement.




--
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] Fossil vs. Git/Mercurial/etc.?


On Wed, 19 Dec 2012 00:23:09 +0100, Richard Hipp  wrote:


On Tue, Dec 18, 2012 at 5:21 PM, Mike Meyer  wrote:


I don't do that (I keep all my fossil repositories in ~/repos), so
haven't paid close attention to the issues. The big one seems to be
accidentally trying to add the repository to itself. The resulting
checkin never terminates. I also recall problems with Windows
(something else I don't use) where the solution was to move the
repository out of the work space.

Maybe the people who helped solve the problems can comment on this? Or
maybe my skimming of such problems has led me to a false conclusion.



I think all these problems are fixed and that it is safe to keep the repo
in the check-out directory.


relieved to here that, thanks. are there any other valid arguments (beyond  
matter of taste things like "I want to separate the repo from the  
checkout" and facilitating backups by putting all repos in a single place)  
which make it unwise to keep the repo within the checkout?







--
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] Fossil vs. Git/Mercurial/etc.?

On Tue, 18 Dec 2012 23:50:17 +0100, Jan Danielsson  
 wrote:



On 12/18/12 22:29, Mike Meyer wrote:
[---]

I don't know of anyone using it for a large team. I don't know of any
reason not to, except for the risk of being the first to try that.


   I don't think "large team" is a problem, apart from the manual work
required in setting up users. I did some work a while back gluing
together fossil with a security middleware which has an integrated
identity manager. It reused the identity manager to configure fossil
server instances. I did some quick'n'dirty hacks; like opening up the
repository via libsqlite and manipulated the databases directly, which
didn't feel all too excellent. (Though the whole thing was a
proof-of-concept and something to demo, more than anything else).

   My primary experience from that project was that there are some areas
where fossil could be enhanced to allow easier integration with identity
managers, which could ease user-management for very large teams.


even for small teams I'd prefer to be able to do user management (easily)  
from the command line.
so I don't overlook anything if I presume that user management currently  
_needs_ to be done

via the web gui? some fossil command like

fossil adduser {basic configuration options go here} user1, user2, ...

would be nice to have. fine-tuning might be delegated to the webinterface  
but

the basic things (adding admin users, development users etc) should be
possible otherwise.





   The biggest problem I have encountered with fossil is with regards to
scalability. Anyone who has tried to use the NetBSD fossil repository
knows it's a pretty painful experience.

   With that said, I came to fossil from bazaar which I abandoned
because it had scalability issues (which were even worse), so it's not
an exclusive fossil-problem. (git isn't affected by this though, but
it's noteworthy that the NetBSD project on github is (was?) imported
from the fossil NetBSD repository).




--
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] Fossil vs. Git/Mercurial/etc.?


On Tue, 18 Dec 2012 22:29:19 +0100, Mike Meyer  wrote:

well-balanced assessment.


On Tue, 18 Dec 2012 14:42:34 +0100
Gilles  wrote:

Out of curiosity, if someone is well-versed with Fossil and the main
DVCS systems (Mercurial, Git),


Well, since no one else has answered publicly, I'll take a stab at
it. Fossil has been my goto SCM for over a year now. I use mercurial
for things I want to share publicly via GoogleCode (yes, I know about
chiselapp, but that's a different discussion). I've used git for
client projects for months at a time over the past couple of years,
including a week-long project this month. I also have years of
experience with subversion, perforce (I am, or was, a PCP), CVS, RCS
and a proprietary precursor to perforce.


Besides the fact that Fossil includes a wiki and a bug tracker, does
it offer features that would make it a better solution than the big
names?


I'd say no. The three are different enough to notice, but whether or
not the differences make them a better solution depends more on the
organization that's using them than about their fundamental
behavior. For example, the major difference is how they handle using
rebase to rewrite history. For git, it's a feature. Mercurial provides
it as an extension, but the community generally discourages it. Fossil
doesn't have it. None of these is universally "right", but each is
right for some organization.

Aside from rebase, the major differences are in things external to
their behavior as a SCM, and those tend to be the ones that drive the
decision as to which one you want to use if you don't care about
rebase.

Fossil: it's strong points are the built-in wiki and ticket tracking
system, and that it's a single self-contained binary.  What sets it
apart as a DSCM is autosync mode and that you can have multiple work


from my recent experience , `autosync' seems to be _the_ feature making
the move to DVCS tolerable for some die-hard `svn' users.


spaces checked out of the same repository.  However, the fossil mail
list sees regular though infrequent issues with people who've stumbled
over a problem caused by them putting the fossil repo in a work space.


could you please elaborate on this? I came to fossil only very recently  
and, for now,
have decided to keep the repo in the checkout directory (just like `hg',  
say). if
I don't won't to have multiple checkouts from the same repo what's  
potentially

bad about this setup? what kind of problems do you have in mind?

j.



For a single user not having to push/pull merges between multiple work
spaces is a win, though you can do that if you want to.

For small teams, the self-contained binary means it users fewer
resources to deploy if you need a version not in the package manager
(or on a system without a package manager).

I don't know of anyone using it for a large team. I don't know of any
reason not to, except for the risk of being the first to try that.


the NetBSD example seems to indicate that fossil's has performance problems
for such projects with a massive code base. is this still the state of  
affairs?

not that this would matter for 99.9% of all projects.

j.



Mercurial: it's strong point is the plugin system. If you need it to
do something that's not in the base, there's a good chance there's a
plugin that does it. With no extensions, it's a good, vanilla DSCM
with a "you can't change history" philosophy, except for the
"rollback" command that lets you undo the last commit. I use
"rollback" to undo commits that didn't include the right set of
files. People regularly show up on the hg users mail list having
problems getting it to find the correct versions of all the parts
after doing an install or upgrade.

Git: I don't like git, because I think mutable history is anathema to
what a SCM should be. That said, it's strong point is it's
popularity. As a DSCM, what sets it apart is using rebase to rewrite
history, and the staging area. The staging area provides the kind of
"brain fart" protection you get from the hg "rollback" command. On the
other hand, I do an empty commit in git because I forgot to set up the
staging area far more often than I use the hg "rollback" command.




--
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] why does `fossil rm' not do the "real" thing?

On Sat, 15 Dec 2012 12:03:26 +0100, Joe Mistachkin   
wrote:




j. v. d. hoff wrote:


POLS comes again to mind.



The Principle of Least Surprise is not static.  Changing the current
behavior
would be a huge (and potentially unpleasant) surprise for those who are  
very

actively using Fossil now.



I can tell you that I _was_ surprised (being also a user of svn and hg)

when
I installed fossil quickly read through the help ("ah yes, ci, add,  
pull,

push, rm, mv, stat, log -- default naming scheme for default tasks"),



Of course, there are much bigger differences between Fossil and those  
other

systems than the semantics of "mv" and "rm".



and I do not buy the "it'll be really dangerous for so many people"
prophecy.



Obviously, I do buy it.  Breaking compatibility is generally bad.  It's  
even

worse when other _software_ (i.e. not humans) may depend on the current
semantics.  The surface area of Fossil is the set of command line


yes, "may" but no convincing scenarios are provided where it _does_ and in  
a way that would cause real grieve for many users. and we are still  
talking about defaults (= most sensible/suitable for most users) here, not  
about good vs. evil behaviour. I repeat that I support the recent proposal  
by richard to change the default as described.



options it
exposes, since it's a command line tool.  In this case, it would not be
unlike
changing the default behavior of the Unix "rm" command to implicitly  
include

the "-f" option.


_that_ is the default in unix (no questions asked). but it's aliased to  
`rm -i' for normal user accounts.





--
Joe Mistachkin

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



--
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] why does `fossil rm' not do the "real" thing?

On Sat, 15 Dec 2012 10:56:20 +0100, Joe Mistachkin   
wrote:




j. v. d. hoff wrote:


I find this a confounding proposal.



Would you care to explain exactly what you find confounding about it?


has all been set way too often in this way too long thread:
POLS comes again to mind. I can tell you that I _was_ surprised (being  
also a user of svn and hg) when
I installed fossil quickly read through the help ("ah yes, ci, add, pull,  
push, rm, mv, stat, log -- default naming scheme for default tasks"),
started to use it and it turned out mv/rm did _not_ behave as usual (and  
for all the reasons stated over and over again: which would be more  
sensible).
by delegating the desired behaviour to `obliterate' or whatever and  
keeping rm as it is you guarantee that this will happen over and over again
to other people. why? for no good reason at all I can see. I'd bet that in  
this arena (recent users) lurks much more trouble by failing to meet
the usual (good, mind you) behaviour than by changing current defaults  
after a transition period.




It provides the requested functionality; however, it does so in a manner
that is respectful to those who are depending on the current


changing the default (including the transition period) is no sign of  
disrespect to anybody.



functionality.


and I do not buy the "it'll be really dangerous for so many people"   
prophecy. of course, if one really tries hard one can manage to get things  
messed up on disk (change lots of things in tracked files, but don't ever  
check in (clever) and then decide to stop tracking the files and issue  
'fossil rm' assuming the files are left alone on disk and only then  
discover they were not). the transition period should guarantee that this  
will not evelove into a real-world problem I'd say.


j.



--
Joe Mistachkin

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



--
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] Obvious solution to the rm/mv problem?


On Sat, 15 Dec 2012 03:15:09 +0100, Richard Hipp  wrote:


On Fri, Dec 14, 2012 at 8:58 PM, Themba Fletcher
wrote:



Could I humbly suggest "unmanage" for the name of the
remove-from-repo-and-leave-the-disk-alone command? This would be
consistent with the status messages emitted by fossil (I think on
merge?) and it's pretty clear from its name what it would do.



I thought of that.  In fact, I typed it into my previous posting to this
list, but then deleted that paragraph before I pressed "send".  I could
support "unmanage" as an alias for "delete".

It is suggested to me (off-list) that it would be too disruptive to
abruptly change the meaning of "fossil rm" to start deleting from disk.   
So

I propose a staged implementation:

Stage 1:
(a) "fossil rm -f" deletes from disk (if it is safe to do so)
(b) "fossil rm" works as currently, but prints a warning message that it
will delete from disk in a future release.
(c) "fossil delete" works as currently
(d) "fossil unmanage" added as an alias for "fossil delete"

Stage 2 (after a stage 1 has been released for a while):
(e) "fossil rm" works just like "fossil rm -f"





This could leave us with the following commands:

1. unmanage -- remove from repo
2. delete -- unmanage and attempt to bring the disk to that state
3. rename -- change the name / path of a file in the repo
4. move -- rename as above, and bring the disk up to date

I think this could be a pretty nice middle of the road compromise. As
for what rm and mv are aliased to at that point -- I for one don't
care. It's the continued existence of known safe (repo only) commands
that keeps me smiling.



+1

and, please, implement a similar strategy for `mv' at the same time.  
everybody should be happy again, hopefully.


j.



--
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] why does `fossil rm' not do the "real" thing?

On Sat, 15 Dec 2012 05:26:33 +0100, Joe Mistachkin   
wrote:




My opinion is that backward compatibility should be retained because  
various
people, including several that may not be involved in this discussion,  
have
existing scripts and other automation that relies upon the current  
behavior.


Whether the current behavior being "ideal" or not is an entirely  
different

debate.

My ideas on this issue are as follows:

1. Retain the existing behavior for all current commands and aliases.   
It is
   far too dangerous to change the DEFAULT semantics of these commands  
now.


2. Add entirely new commands named "relocate" (for mv) and "obliterate"  
(for

   rm) that will perform actions on the repository itself as well as the
file
   system.

3. For the new "relocate" command, it should raise an error if the
destination
   file name already exists on the file system or in the repository.

4. For the new "obliterate" command, it should raise an error if the file
has
   been changed in the current checkout.

5. Optionally, add a -f/-filesystem option to the existing mv/rm  
commands if
   there is consensus on this point.  This new option will cause the  
exact

   same behavior as the new commands, including the errors as described
above.

P.S. This message is not a reply to any given message on this thread, per
se.

If you disagree with my ideas, that's fine; however, please keep the
discussion
civil.

Thanks.


I find this a confounding proposal. the backward compatibility issue  
(given the proposed precautions,warnings, and length of phase out time)  
will I'm sure turn out to

be a none-issue in the end.

so "-1"

from my side




--
Joe Mistachkin

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



--
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] why does `fossil rm' not do the "real" thing?

On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp  wrote:

On Thu, Dec 13, 2012 at 6:08 PM, Eric  wrote:

On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" 
wrote:
> In order to continue the debate:
>  In my work flow, I do rm or mv in file system as and when needed. I  
do

>  fossil rm or fossil mv only when reviewing my changes before commit.

Well, yes, that is the way I do it too. I suspect that there are some
who do not review their changes before commit, and that many of those
commit way too often, essentially treating their VCS as a backup method.
This of course leads to junk, non-functional checkins, followed by an
unhealthy interest in rebase-like functionality.

Well put.

I don't think so, actually. I've seen misuses (sort of) and misconceptions
of SCMs here (on this list) and elsewhere. that happens. considering  
serious and sane use of SCM, I'm still
perfectly sure that for the sole reason (repeated already way to often)  
that the by far most frequent use case of `fossil rm' and `fossil mv' will  
be a situation where
the file system should reflect the change, the default behaviour should  
change. your previous suggestion in this direction did make perfect sense  
to me. the present one not so much.

so I strongly opt for a default that does the "real" thing (yes!) of  
keeping repo and file system in sync (that's in my view what the SCM  
should always strive for. and to relegate different behaviour to the  
options, not the other way round.

but, indeed,  it is an interesting question why for heavens sake this  
issue does cause such a storm on this list? I don't get it. maybe it's too  
obvious to me that a default which forces me (and an estimate 99% of the  
other users) to type more than necessary -- which I don't like -- (and at  
the same time of running the risk of forgetting the additional actions and  
starting to mess things up) is no good while others have adjusted their  
mind to the current behaviour and don't want to change anything since it  
currently "just works" (tm).

I can tell you from own experience that it definitely does not help to  
convince svn users, e.g., that fossil is a interesting system (which it  
is). and yes: this alone
sure is no argument. but it _is_ an argument if essentially all of the  
"competitors" (that I know of) go for the "`scm rm/mv' act on the  
filesystem as well" strategy for a reason.

anywayt, I think everything has been said now more than once. I'll try to  
keep radio silence regarding this topic from know own (see whether I'm  
successful...).

looking forward to the upcoming releases. I'll manage to use fossil in any  
case.

j.

So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty
much convinced me at this point to keep the current behavior of "fossil  
rm"

and "fossil mv".

But, should there be an opt-in option to also make the disk changes?
Perhaps "fossil rm abc.txt" just removes abc.txt from configuration
management, but "fossil rm -f abc.txt" also removes it from disk?

And/or should there be a warning printed:  "File abc.txt removed from
management but unchanged on disk" just to give a heads-up to newcomers  
who

expect different behavior?

--
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] why does `fossil rm' not do the "real" thing?


On Fri, 14 Dec 2012 00:08:04 +0100, Eric  wrote:

On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu"   
wrote:

In order to continue the debate:
 In my work flow, I do rm or mv in file system as and when needed. I do
 fossil rm or fossil mv only when reviewing my changes before commit.


Well, yes, that is the way I do it too. I suspect that there are some
who do not review their changes before commit, and that many of those
commit way too often, essentially treating their VCS as a backup method.
This of course leads to junk, non-functional checkins, followed by an
unhealthy interest in rebase-like functionality.

On another note, people are saying things like "there is a certain
behaviour that is expected" without saying why it is expected. The main
reasons seem to be that other VCS's do it and that it saves time. The
first is irrelevant and the second, in my opinion, a case of people
knowing the price of everything and the value of nothing.

I think this thread has served to highlight the number of people here
who want Fossil to be something other that what it set out to be, and


richard might decide that one, right? and even if it were true that this  
discussion revolves about the issue of morphing fossil into something  
else, which it is not, it could - theoretically - be a development in the  
right direction presuming that the initial design (goal) was not perfect  
in the strict sense of the word (which simply never can be the case in  
this world). but all this is 100% relevant to the point at hand.



don't actually know what SCM means. It doesn't surprise me that they


sure. dummies all of them.


have caused some over-the-top reactions.


altogether I see your mail as another (logical) non sequitur.

j.



Eric



--
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] why does `fossil rm' not do the "real" thing?


On Thu, 13 Dec 2012 10:58:29 +0100, Gour  wrote:


On Thu, 13 Dec 2012 06:49:08 -0300
Richie Adler  wrote:


Can you please killfile me and leave me alone?


That's not the point 'cause your comments are not polite and
disturbing to other Fossil users as you can see...


+1




Sincerely,
Gour





--
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] why does `fossil rm' not do the "real" thing?


On Thu, 13 Dec 2012 08:16:48 +0100, Gour  wrote:


On Wed, 12 Dec 2012 23:42:29 -0300
Richie Adler 
wrote:


Sorry, I still think that the intention is to destroy what Fossil has
of unique to offer to be able to say that Git or Mercurial it's the
same and they should be preferred to Fossil.

What's next? Replacing SQLite with individual files?


Can you please change your mantra labelling every constructive attempt
to change something in Fossil as conspiracy by Git advocates.



+1


Thank you.


Sincerely,
Gour




--
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] why does `fossil rm' not do the "real" thing?

2012-12-11 Thread j. v. d. hoff

On Tue, 11 Dec 2012 22:50:06 +0100, Themba Fletcher  
 wrote:



Sorry to drag up an old thread, but I'm just checking back in after a
lengthy absence.

On Fri, Nov 30, 2012 at 9:33 AM, Nolan Darilek   
wrote:

Weighing in on this, finally:

It's interesting to me that everyone speculates that this *might* break
things for some hypothetical person, and *might* bite someone, but has
anyone here ever been bitten by it?


It's the "what if" that bothers me. I use fossil as a safety net to
manage an ungodly number of small maintenance projects, so I'm often
not the original author of the project, and am almost never really
comfortable with the code base I'm modifying.

When I sync a code base to my machine and "fossil add . --dotfiles" I
really appreciate the fact that I can trust fossil not to touch the
disk if I accidentally add something that I don't want in there and
have to remove it.

In the presence of shabby and poorly maintained deploy/sync scripts,
solo use of fossil, unknown modifications to the master since the last
checkin, etc., the consequences of removing something from my local
copy could be pretty embarrassing -- ie I could potentially blow away
the only working copy of a new cusomer's web app. Not to say that I
couldn't adjust to a new set of danger points, but that I do really
appreciate fossil's current behavior.




And is it not something that "fossil revert" could undo?



Is it? What about:

fossil add .
(whoops) -> fossil rm something
fossil commit
(take a phone call and forget it's fossil 2.0)
sync up

Now the files are gone locally, they're gone on the remote site, and
fossil revert isn't going to help. This is obviously a workflow /
deploy problem at its root, but it's a bit of sloppiness that fossil's
current behavior forgives and the proposed behavior would not.



I don't mind avoiding the change until a 2.0 release, but I worry about
making it a setting, because I prescribe to the idea that settings add
complexity both for users and developers.



I agree about minimizing the extra overhead of a setting, but I come
down personally on the side of "it's working fine, so please don't
touch it." Maybe my use case varies from the norm, but I don't do
fossil rm all that often and, when I do, the extra overhead of having
to do "Up arrow, Ctrl-A, Alt-D, Return" afterwards doesn't bother me
at all. I like explicitly taking care of this as a second deliberate
step.

My $0.10 adjusted for inflation: keep the existing behavior until 2.0,  
then

just change it. There are plenty of settings already, please don't add
another, especially for something that we're all speculating might  
affect

someone who can't just revert for whatever reason.


So, respectfully disagree. For me it's about not having to learn new
rules about when fossil will touch my files and when it will not.


for me it's about what is the most sane (or probably expected) default  
behavior for the majority of users.
this question has been answered several times by the developers/users of  
other SCMs (hg, svn, ...) to the
extent that `rm' and 'mv' should act on the files in the checkout as well.  
for me, they were right: when
executing commands via  the SCM (fossil in the present context) one can  
_expect_ that something will happen
to the checkout and that fossil's opinion of what the state of the project  
is should be in sync with the
checkout as far as possible. _usually_ `fossil mv' and `fossil rm' should  
imply that the action is applied
to the checkout as well (do the rename or deletion of the file). more  
often than not (I'd say) that's what
the user will want to happen. and that's what the default behavior should  
cover.


of course I understand that this might exactly be _not_ your use case. but  
we are talking about _default_ behavior (and possibly delegating diverging  
behavior to options). in my use case I _always_ have to mv/rm (mv is  
especially bad, if forgotten) the checkout files manually and my suspicion  
is that's exactly what the majority of users will do currently. which  
would indicate that the current behavior is  suboptimal.


best regards,
joerg




Best Regards,

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



--
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] (Another?) fossil wrapper script

2012-12-11 Thread j. v. d. hoff


On Tue, 11 Dec 2012 13:58:41 +0100, Marc Simpson  wrote:


Thanks Joerg,

I've just pushed a fix -- can you try it out and let me know whether it
resolves the issue



yes it does. thanks.

j.





Best,
Marc

On Tue, Dec 11, 2012 at 5:51 PM, j. v. d. hoff  
wrote:



thanks for this script which looks promising.
first bug report: I see interference with the `nano' editor (which is  
set
as my 'checkin editor' due to its low latency): `nano' is keyboard  
driven

and uses the command `^X' (CNTRL-X) for "save and exit". when using `fsl
ci' the editor opens all right and I can enter the commit message.  
CNTRL-X

however is not recognized as a command any more but rather is taken as
verbatim input: no way to leave the editor except killing the window.  
this

does happen only when issuing `fsl ci'
`fossil ci' behaves as expected.

regards,
joerg



On Tue, 11 Dec 2012 11:46:37 +0100, Marc Simpson   
wrote:


 Hi all,


I've recently written a simple wrapper for Fossil with the goal of
providing an improved CLI experience and thought others might find it
useful.

The script is written in Tcl/Expect and provides the following  
features:


   * Command aliasing
   * Output filtering
   * A number of preconfigured aliases, filters for colouring output

Though still inchoate, you should be able to use it as you would
`fossil' on the command line.

If you're interested, feel free to clone from
http://fossil.0branch.com/fsl/**home  
<http://fossil.0branch.com/fsl/home>or download `fsl' directly:

http://fossil.0branch.com/fsl/**artifact/**f57c7ecf8c4db2a9990b40ee21e763
**7a1374f45e<http://fossil.0branch.com/fsl/artifact/f57c7ecf8c4db2a9990b40ee21e7637a1374f45e>
.
The code is ISC licensed (likely overkill for such a simple script).

# Details

Out of the box, a number of filters and aliases are defined in
~/.fslrc (created on first run):

   * Aliases ('->' indicates the expansion)
  * '.' -> 'changes'
  * 'd' -> 'diff'
  * ',' -> 'ui'
  * 'log'   -> 'timeline'
  * 'heads' -> 'leaves'

   * Filters (all of which colour output)
  * 'diff'
 * 'fsl d'
  * 'log_entry'
 * 'fsl leaves', 'fsl timeline'
  * 'status'
 * 'fsl changes', 'fsl status', 'fsl timeline', 'fsl add',
   'fsl rm', 'fsl addremove'

You can see a summary of these definitions using the `fsl wrapper'
pseudo-command:

  $ fsl wrapper
  Aliases: . d , log heads
  Filters: changes status timeline add rm addremove leaves d

The configuration file is a Tcl script: you can define `proc's (for
helper functions) and employ them in your filters. Definitions will
end up in the `config::fslrc' namespace so you needn't worry about
clobbering predefined functions. Since the script makes heavy use of
dictionaries, it requires Tcl >= 8.5.

Alias declarations are trivial; their second argument can be a
bareword or quoted string, thereby allowing expansions to provide
switches if required, e.g.

  alias log  timeline
  alias history {timeline -n 100}

Filters are named, allowing them to be referenced elsewhere in your
configuration script. Their structure is:

  filter   

If you filter on a fossil command like `diff', aliases of this command
(by default, `d') will also be filtered. Conversely, filtering on an
alias (`d'), leaves its expansion (`diff') untouched. Also note that
more than one filter may apply to a given command: under the default
configuration, the timeline will be filtered by both `status' and
`log_entry'.

A filter body can reference the current output line via the implicitly
defined $line variable. By way of example, here's the `log_entry'
filter:

  filter log_entry {leaves timeline} {
  if {[regexp "^=== .* ===" $line]} {
  coloured blue $line
  } else {
  regsub -all {\[[A-Fa-f0-9]+\]} $line [coloured yellow &]
  }
  }

Useful functions defined by the script are:

   * `coloured' (for colouring output)
   * `alias?'
   * `filter?'
   * `empty?' and `prefix?' (simple utility functions)

Patches, criticisms, suggestions etc. are welcome.

Best,
Marc




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




--
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] (Another?) fossil wrapper script

2012-12-11 Thread j. v. d. hoff


thanks for this script which looks promising.
first bug report: I see interference with the `nano' editor (which is set  
as my 'checkin editor' due to its low latency): `nano' is keyboard driven  
and uses the command `^X' (CNTRL-X) for "save and exit". when using `fsl  
ci' the editor opens all right and I can enter the commit message. CNTRL-X  
however is not recognized as a command any more but rather is taken as  
verbatim input: no way to leave the editor except killing the window. this  
does happen only when issuing `fsl ci'

`fossil ci' behaves as expected.

regards,
joerg


On Tue, 11 Dec 2012 11:46:37 +0100, Marc Simpson  wrote:


Hi all,

I've recently written a simple wrapper for Fossil with the goal of
providing an improved CLI experience and thought others might find it
useful.

The script is written in Tcl/Expect and provides the following features:

   * Command aliasing
   * Output filtering
   * A number of preconfigured aliases, filters for colouring output

Though still inchoate, you should be able to use it as you would
`fossil' on the command line.

If you're interested, feel free to clone from
http://fossil.0branch.com/fsl/home or download `fsl' directly:
http://fossil.0branch.com/fsl/artifact/f57c7ecf8c4db2a9990b40ee21e7637a1374f45e
.
The code is ISC licensed (likely overkill for such a simple script).

# Details

Out of the box, a number of filters and aliases are defined in
~/.fslrc (created on first run):

   * Aliases ('->' indicates the expansion)
  * '.' -> 'changes'
  * 'd' -> 'diff'
  * ',' -> 'ui'
  * 'log'   -> 'timeline'
  * 'heads' -> 'leaves'

   * Filters (all of which colour output)
  * 'diff'
 * 'fsl d'
  * 'log_entry'
 * 'fsl leaves', 'fsl timeline'
  * 'status'
 * 'fsl changes', 'fsl status', 'fsl timeline', 'fsl add',
   'fsl rm', 'fsl addremove'

You can see a summary of these definitions using the `fsl wrapper'
pseudo-command:

  $ fsl wrapper
  Aliases: . d , log heads
  Filters: changes status timeline add rm addremove leaves d

The configuration file is a Tcl script: you can define `proc's (for
helper functions) and employ them in your filters. Definitions will
end up in the `config::fslrc' namespace so you needn't worry about
clobbering predefined functions. Since the script makes heavy use of
dictionaries, it requires Tcl >= 8.5.

Alias declarations are trivial; their second argument can be a
bareword or quoted string, thereby allowing expansions to provide
switches if required, e.g.

  alias log  timeline
  alias history {timeline -n 100}

Filters are named, allowing them to be referenced elsewhere in your
configuration script. Their structure is:

  filter   

If you filter on a fossil command like `diff', aliases of this command
(by default, `d') will also be filtered. Conversely, filtering on an
alias (`d'), leaves its expansion (`diff') untouched. Also note that
more than one filter may apply to a given command: under the default
configuration, the timeline will be filtered by both `status' and
`log_entry'.

A filter body can reference the current output line via the implicitly
defined $line variable. By way of example, here's the `log_entry'
filter:

  filter log_entry {leaves timeline} {
  if {[regexp "^=== .* ===" $line]} {
  coloured blue $line
  } else {
  regsub -all {\[[A-Fa-f0-9]+\]} $line [coloured yellow &]
  }
  }

Useful functions defined by the script are:

   * `coloured' (for colouring output)
   * `alias?'
   * `filter?'
   * `empty?' and `prefix?' (simple utility functions)

Patches, criticisms, suggestions etc. are welcome.

Best,
Marc



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

[fossil-users] status of automated CRLF conversion?

2012-12-09 Thread j. v. d. hoff

I wonder what the current status/future plans are regarding optional  
automated CRLF to LF conversion for heterogeneous setups (mixed  
unix/windows)?
such a feature would be helpful (also in convincing colleagues that  
`fossil' can be considered a serious alternative to git/svn/hg).


j.



--
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] storing konfiguration files, mail aliases and other files in repository

2012-12-04 Thread j. v. d. hoff


On Tue, 04 Dec 2012 16:39:06 +0100, Jiri Navratil  wrote:


Hi,

I'm considering to add some files from my $HOME like .bashrc,  
.mail_aliases, .. into fossil repository.


if I understand your question correctly I would rather propose to put all  
the configuration files you want to track in a separate "project"  
directory and generate a fossil repository for the content of that (new  
directory). from there you can either "install" the current version

of the files into your HOME directory or simply put softlinks there.

j.



I will keep most of these files identical per each machine. Few files  
shall be specific per machine. How I can store version same filenames  
per machines, please?


I'm considering to put most subdirectories and many files to GLOBPATTERN  
to keep 'fossil extra' useful. Is that proper way how to keep output  
from fossil extra "short"?


Thank you.

Best regards,
JIri

--
Jiri Navratil, http://www.navratil.cz,  +420 777 224 245

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



--
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] How to generate a ChangeLog document (FSF style)?

2012-12-03 Thread j. v. d. hoff


...
Maybe none at all. The graphic representation of the timeline in the web  
interface is really awesome, especially the explicit handling of  
branching/merging.

...

one more (cosmetic) item for the wishlist: I would find it really helpful  
if the branch/merge information could (optionally or by default)
be integrated as "ascii art" into the `timeline' output. for   
illustration, I've converted one of my `fossil' repos to `hg'. with


`hg log -g' (`g' for graphics) I get, e.g., this snippet in the log output:

8<-
ochangeset:   45:6afe8c12328f
|\   parent:  41:452701aaa7ca
| |  parent:  44:6016c35bcd87
| |  user:doe 
| |  date:Mon Nov 19 21:22:55 2012 +
| |  summary: merged revised `theory' section back to trunk.
| |
| o  changeset:   44:6016c35bcd87
| |  bookmark:sinh
| |  user:vdoe 
| |  date:Mon Nov 19 21:14:37 2012 +
| |  summary: mostly finished revision of `theory' section.
| |
| o  changeset:   43:fbabab3870b8
| |  user:doe 
| |  date:Mon Nov 19 16:47:44 2012 +
| |  summary: tentative overhaul of `theory' section.
| |
o |  changeset:   41:452701aaa7ca
|/   user:doe 
|date:Mon Nov 19 16:54:44 2012 +
|summary: just a note.
|
o  changeset:   40:314da8440e0a
|  user:doe 
|  date:Fri Nov 16 23:12:19 2012 +
|  summary: some incremental edits.
8<-

compare this to the corresponding fraction of the `fossil -timeline'  
output:

8<-
22:22:55 [217921b304] *MERGE* merged revised `theory' section back to  
trunk.

 (user: doe tags: trunk)
22:14:37 [71fc7ffa18] mostly finished revision of `theory' section. (user:  
doe

 tags: sinh)
17:54:44 [a346c75dd2] just a note. (user: doe tags: trunk)
17:47:44 [1a58c5ec33] tentative overhaul of `theory' section. (user: doe  
tags:

 sinh)
17:46:05 [c4e2b9991d] Create new branch named "sinh" (user: doe tags: sinh)
=== 2012-11-17 ===
00:12:19 [040c7f61a9] *BRANCH* some incremental edits. (user: doe tags:  
trunk)

8<-

which is more difficult to translate into the correct mental picture of  
the revision tree I'd say.


regarding the intial question: if (if...) the timeline output could  
optionally be forced to put each commit message on a single line it
would be very easy (and not that much more difficult with the current  
layout) to write a small shell (sed, awk, python, perl ...) script to  
extract the messages from the output to generate the desired

changelog, right?
___
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 does `fossil rm' not do the "real" thing?

2012-11-30 Thread j. v. d. hoff

On Fri, 30 Nov 2012 15:30:13 +0100, Chad Perrin  wrote:

On Tue, Nov 20, 2012 at 06:10:00PM +0100, j. van den hoff wrote:

On Tue, 20 Nov 2012 16:48:00 +0100, James Turner
>
>I'd suggest -f like cvs rm uses.

obviously everybody seems to have his/her own preference how to
handle this. so only a fraction of users will be happy in the end it
seems. -- I would again second the proposal
of Remigiusz Modrzejewski in this thread: after a 'grace' period
when it would behave in the way you propose (explicitly add a -f
flag to enforce deletion), finally change the default to what
_current_ VCSs (>= svn) seemingly all (?) do by default which is to
treat `svn(hg, git, bzr) rm' as meaning
"remove from repository and also remove the working copy" while
relegating different behaviour (if at all) to an option such as "bzr
rm --keep".

in my way that is the most frequently intended behaviour which
should therefore be the default.
sure a matter of taste as so many things, but at least it would
avoid surprises here for refugees from one of the other systems.

I think that makes sense, with the addition of using Matt Welland's
suggestion of scheduling the move to compatibility breaking behavior on a
2.0 release.  This is the purpose of common semantic versioning, after
all: major version numbers (the "integer" portion, essentially) are for
indicating breakage in backward compatibility for system features.

I think that doggedly sticking to current default behavior for all time
is a bad idea for a number of reasons[1], but that making changes to
expected defaults before a major version number increment is also a
rather bad idea.

[1]: . . . such as potential for error when using multiple DVCSes in
parallel and discouraging people from adopting the software.

I fully support this reasoning. the last point, especially, is not to be  
taken lightly. but of course behind that is the basically more important  
aspect that it (i.e. `rm' doing both, removal from tracking and deleting  
the checked out copy) would be a saner default, probably.

j.

--
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] howto `grep' through old revisions

On Sat, 24 Nov 2012 23:42:02 +0100, James Turner   
wrote:



What about just using regex(3)? It's included with BSD and quite
possibly Linux distributions, but I have no way of checking.

No idea how good the library is, but it might cut down on dependencies?



would intgration of the lua library

http://www.lua.org/

be a silly idea? it's under MIT licence, has very small footprint (quite  
probable smaller than a full fledged regex lib), and has a quite powerful  
pattern matching facility (somewhat different syntax than regex, but so  
what?) which can do everything that regex can (except alterations). who  
knows: it could even be useful as a configuration/scripting language of  
sorts If need be.


just an idea.


--
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] howto `grep' through old revisions

On Sat, 24 Nov 2012 20:05:55 +0100, Bernd Paysan   
wrote:



Am Samstag, 24. November 2012, 08:59:58 schrieb Richard Hipp:

So what should the output look like?  Suppose we implement a command:

   fossil grep REGEXP FILENAMEGLOB

Which searches all historical versions of files that match FILENAMEGLOB  
for

patterns that match REGEXP.  Suppose for concreteness that the regular
expression is "xyzzy" and the file is "ex1.txt".  If there are 1000
different revisions of ex1.txt, does it search them all looking for  
"xyzzy"
and show each hit?  Or did it stop going backwards in time at the first  
hit

it find?


Hm, I'd rather show first and last revision where xyzzy is in, something  
like


% fossil grep xyzzy ext1.txt
7c88a35016..cbaff03a91:ext1.txt:here we have the *xyzzy* string

If you grep through some edit war, you will have many start..stop  
start..stop

tuples.


what you propose could easily be filter out from a full recursive search
backward through all revisions (and it would require such a search), right?
I would not think this to be the best default behaviour (1000 revisions
to process etc.). I think a "stop at first hit" default is more reasonable
(and maybe more often than not the standard use case)






--
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] how to dump artifact content to stdout


On Sat, 24 Nov 2012 17:40:30 +0100, Richard Hipp  wrote:


On Sat, Nov 24, 2012 at 10:35 AM, j. v. d. hoff
wrote:


On Sat, 24 Nov 2012 16:23:05 +0100, Martin Gagnon 
wrote:

 Le 2012-11-24 10:16, j. v. d. hoff a écrit :



On Sat, 24 Nov 2012 15:43:57 +0100, Stefan Bellon 
wrote:

 On Sat, 24 Nov, j. v. d. hoff wrote:


 I would like to issue something like `fossil artifact [1234] -f

myfile.txt'



I may be misunderstanding, but isn't

   fossil finfo -p -r [1234] myfile.txt

what you want?



yes exactly, thanks a lot!

caught in the act of no reading the help pages thoroughly enough,  
damn.

;-)

an alias `fossil cat` would be more intuitive, though...



More intuitive for people that's come from hg. For people that use CVS



I would say for all unix/linux/macos people. I would never have guessed
that I should read completely through the `finfo' help page. but  
anyhow...



Your feedback is useful.  What is "obvious" to experienced Fossil users
might not be apparent at all to newbies.  And there isn't really any way
for us to know where the pitfalls are without getting this kind of
feedback.  So please keep complaining.


hope this comes not across as "complaining"...
and I'm of course aware that fossil does not intend to emulate the `svn' or
`mercurial' ui.



Yes, it would be good to improve the documentation.  Volunteers?


well that needs people who know the system. -- but here are a few notes
I took today (at least the list of typos in the help pages might be worth  
reading ;-)):

8<---
   fossil 1.24 command line user interface

 Remarks concerning the fossil 1.24 command line user interface

Quirks

1. Check in with empty commit message should not be allowed: in my view
   empty commit messages should be interpreted as intentional abort of
   the check in (and a “commit aborted” message should be issued)

2. Short options: these should not enforce a blank between option  
letter

   and argument in order to comply with the de facto (maybe not POSIX?)
   standard UNIX behavior.

3. There are (one-dash, one-character) short options and (two-dashes,
   multiple-character) long options but there are also at least two
   one-dash/multiple-character options, namely -showfiles (for  
timeline)

   and -help (as an option to command instead of using the help command
   itself).

   In my view the latter should be abolished in order to adhere to more
   standard usage (like GNU readline). This, moreover, should allow to
   parse short options (one dash/one letter) differently by not  
enforcing

   blanks between option and argument. Or would it not due to the
   presence of hyphenated options such as --date-override? In this case
   maybe underscores should replace the hyphen in these commands in  
some

   future release?

4. Command options are handled not consistently across different  
commands


  * Many commands only have long options. Some have short options  
as

alias of a long option but some short options do not correspond
to a long option. Example of the latter: fossil diff -i

  * Where there a equivalent short and long options the help pages
usually list them in the form --long | -l but sometimes the  
other
way round (e.g. for ui: -P|--port) which is inconsistent. I  
think

short options should always be listed first.

  * fsl time -showfile is a no-op (does nothing) instead of
interpreting it as meaning -showfiles or giving an error  
message


5. Error messages (or absence thereof)

  * fossil time -showfile: Error Message: none (silently ignored)

6. fossil mv/rm: These should act on the files in the checkout as well  
by

   default.

Typos in the help pages

1. fossil help configuration: “Write to FILENAME exported
   >>_configuraton_<< information for AREA.”

2. fossil help revert: “If a file is reverted >>_accidently_<<, it can  
be

   restored using”

3. fossil help ui: “that contains one or more >>_rspositories_<< with
   names ending in ".fossil".”

4. fossil help settings: “https-login Send login >>_creditials_<< using
   HTTPS instead of HTTP”

5. fossil help tag: “the tag value >>_propages_<< to all descendants of
   CHECK-IN”

6. fossil help wiki: “case→>_insentively_<< by name.”

Wish list

1. Customization via a command alias mechanism, such as

 alias cat "finfo -p"

2. Consistent command argument syntax, providing single dash/single
   character short options as well as equivalent two dashes/multiple
   character long options for all commands/options.

3. Add a fossil he

Re: [fossil-users] how to dump artifact content to stdout


On Sat, 24 Nov 2012 16:23:05 +0100, Martin Gagnon  wrote:


Le 2012-11-24 10:16, j. v. d. hoff a écrit :

On Sat, 24 Nov 2012 15:43:57 +0100, Stefan Bellon 
wrote:


On Sat, 24 Nov, j. v. d. hoff wrote:


I would like to issue something like `fossil artifact [1234] -f
myfile.txt'


I may be misunderstanding, but isn't

   fossil finfo -p -r [1234] myfile.txt

what you want?


yes exactly, thanks a lot!

caught in the act of no reading the help pages thoroughly enough, damn.  
;-)


an alias `fossil cat` would be more intuitive, though...


More intuitive for people that's come from hg. For people that use CVS


I would say for all unix/linux/macos people. I would never have guessed
that I should read completely through the `finfo' help page. but anyhow...


before, "-p" is pretty intuitive..




--
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] how to dump artifact content to stdout

On Sat, 24 Nov 2012 15:43:57 +0100, Stefan Bellon   
wrote:



On Sat, 24 Nov, j. v. d. hoff wrote:


I would like to issue something like `fossil artifact [1234] -f
myfile.txt'


I may be misunderstanding, but isn't

   fossil finfo -p -r [1234] myfile.txt

what you want?


yes exactly, thanks a lot!

caught in the act of no reading the help pages thoroughly enough, damn. ;-)

an alias `fossil cat` would be more intuitive, though...

j.



Greetings,
Stefan




--
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] howto `grep' through old revisions

On Sat, 24 Nov 2012 15:21:54 +0100, Richard Hipp  wrote:

On Sat, Nov 24, 2012 at 9:12 AM, j. v. d. hoff  
wrote:

On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp  wrote:

 On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell  

>wrote:

 On Sat, Nov 24, 2012 at 08:18:55AM -0500, Richard Hipp wrote:

> On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff <
veedeeh...@googlemail.com>**wrote:
>
> > question: is there a straightforward (or sqlite-based) way to  
`grep'

> > through a specified file recursively backward in time through all
revisions
> > (or until first hit of the search pattern)?
> >
> > j.
> >
> > ps: yes, I would know now (after having learned how to use `fossil
> > artifact' correctly...) how to write a shell script doing that.  
but

that
> > would mean to dump the full content of each revision and pipe it
through
> > the grep which will become slow if there are too many revisions.  
so

the
> > question is whether the functionality is already builtin (possibly
grepping
> > through the deltas instead).
> >
>
> This functionality is not built-in.  Nobody has ever thought of it
before
> in 6 years of use, apparently, or at least has not mentioned it to  
me.

I use this from time to time. My procedure goes through deconstructing
the
database, grepping recursive, and resolving back the hashes with  
fossil

ui.

So what should the output look like?  Suppose we implement a command:

   fossil grep REGEXP FILENAMEGLOB

Which searches all historical versions of files that match FILENAMEGLOB
for
patterns that match REGEXP.  Suppose for concreteness that the regular
expression is "xyzzy" and the file is "ex1.txt".  If there are 1000
different revisions of ex1.txt, does it search them all looking for
"xyzzy"
and show each hit?  Or did it stop going backwards in time at the first
hit
it find?

should stop at first hit by default but allow going through complete
history optionally.
I feel the `hg' people did it essentially right regarding this question:

8<**---
hg grep [OPTION]... PATTERN [FILE]...

search for a pattern in specified files and revisions

Search revisions of files for a regular expression.

This command behaves differently than Unix grep. It only accepts
Python/Perl regexps. It searches repository history, not the working
directory. It always prints the revision number in which a match
appears.

By default, grep only prints output for the first revision of a  
file in

which it finds a match. To get it to print every revision that
contains a
change in match status ("-" for a match that becomes a non-match, or
"+"
for a non-match that becomes a match), use the --all flag.

Returns 0 if a match is found, 1 otherwise.

options:

 -0 --print0  end fields with NUL
--all print all revisions that match
 -a --texttreat all files as text
 -f --follow  follow changeset history, or file history  
across

  copies and renames
 -i --ignore-case ignore case when matching
 -l --files-with-matches  print only filenames and revisions that match
 -n --line-number print matching line numbers
 -r --rev REV [+] only search files changed within revision  
range

 -u --userlist the author (long with -v)
 -d --datelist the date (short with -q)
 -I --include PATTERN [+] include names matching the given patterns
 -X --exclude PATTERN [+] exclude names matching the given patterns
--mq  operate on patch repository

[+] marked option can be specified multiple times
8<**---

this of course is already quite elaborate and thus not a proposal to do
the same...

but the default behaviour (stop at first hit) is good, the flags `l',  
`r'

important, `u', `d', `i' sensible in my view.

One big problem here is that the user will doubtless expect to have full
Perl regular expressions.  That will mean another compile-time  
dependency.

no, no, heaven forbid. I didn't mean that. I have in mind more modest  
functionality.
for me, at least, I would nearly be happy with fixed string patterns and  
glob patterns like

"something*other" (or the regex equivalent "something.*other")

And maybe also a run-time dependency if a shared library is used (as most
distribution packages managers will likely require).  Suddenly, Fossil
becomes much less stand-alone and self-contained.

definitely no good. I'm a strong believer in "small and self-contained is  
beautiful".

that is, what I find really appealing in `fossil'.

When I get around to working on this, perhaps I'll compromise a

Re: [fossil-users] howto `grep' through old revisions

On Sat, 24 Nov 2012 14:59:58 +0100, Richard Hipp  wrote:

On Sat, Nov 24, 2012 at 8:34 AM, Lluís Batlle i Rossell  
wrote:

On Sat, Nov 24, 2012 at 08:18:55AM -0500, Richard Hipp wrote:
> On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff <
veedeeh...@googlemail.com>wrote:
>
> > question: is there a straightforward (or sqlite-based) way to `grep'
> > through a specified file recursively backward in time through all
revisions
> > (or until first hit of the search pattern)?
> >
> > j.
> >
> > ps: yes, I would know now (after having learned how to use `fossil
> > artifact' correctly...) how to write a shell script doing that. but
that
> > would mean to dump the full content of each revision and pipe it
through
> > the grep which will become slow if there are too many revisions. so  
the

> > question is whether the functionality is already builtin (possibly
grepping
> > through the deltas instead).
> >
>
> This functionality is not built-in.  Nobody has ever thought of it  
before

> in 6 years of use, apparently, or at least has not mentioned it to me.

I use this from time to time. My procedure goes through deconstructing  
the
database, grepping recursive, and resolving back the hashes with fossil  
ui.

So what should the output look like?  Suppose we implement a command:

   fossil grep REGEXP FILENAMEGLOB

Which searches all historical versions of files that match FILENAMEGLOB  
for

patterns that match REGEXP.  Suppose for concreteness that the regular
expression is "xyzzy" and the file is "ex1.txt".  If there are 1000
different revisions of ex1.txt, does it search them all looking for  
"xyzzy"
and show each hit?  Or did it stop going backwards in time at the first  
hit

it find?

should stop at first hit by default but allow going through complete  
history optionally.

I feel the `hg' people did it essentially right regarding this question:

8<---
hg grep [OPTION]... PATTERN [FILE]...

search for a pattern in specified files and revisions

Search revisions of files for a regular expression.

This command behaves differently than Unix grep. It only accepts
Python/Perl regexps. It searches repository history, not the working
directory. It always prints the revision number in which a match  
appears.

By default, grep only prints output for the first revision of a file in
which it finds a match. To get it to print every revision that  
contains a
change in match status ("-" for a match that becomes a non-match, or  
"+"

for a non-match that becomes a match), use the --all flag.

Returns 0 if a match is found, 1 otherwise.

options:

 -0 --print0  end fields with NUL
--all print all revisions that match
 -a --texttreat all files as text
 -f --follow  follow changeset history, or file history across
  copies and renames
 -i --ignore-case ignore case when matching
 -l --files-with-matches  print only filenames and revisions that match
 -n --line-number print matching line numbers
 -r --rev REV [+] only search files changed within revision range
 -u --userlist the author (long with -v)
 -d --datelist the date (short with -q)
 -I --include PATTERN [+] include names matching the given patterns
 -X --exclude PATTERN [+] exclude names matching the given patterns
--mq  operate on patch repository

[+] marked option can be specified multiple times
8<---

this of course is already quite elaborate and thus not a proposal to do  
the same...

but the default behaviour (stop at first hit) is good, the flags `l', `r'  
important, `u', `d', `i' sensible in my view.

j.

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

--
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] howto `grep' through old revisions

On Sat, 24 Nov 2012 14:18:55 +0100, Richard Hipp wrote:

On Sat, Nov 24, 2012 at 7:57 AM, j. v. d. hoff
wrote:

question: is there a straightforward (or sqlite-based) way to `grep'
through a specified file recursively backward in time through all
revisions

(or until first hit of the search pattern)?

ps: yes, I would know now (after having learned how to use `fossil
artifact' correctly...) how to write a shell script doing that. but that
would mean to dump the full content of each revision and pipe it through
the grep which will become slow if there are too many revisions. so the
question is whether the functionality is already builtin (possibly
grepping

through the deltas instead).

This functionality is not built-in. Nobody has ever thought of it before

in 6 years of use, apparently, or at least has not mentioned it to me.

neither did I, but the developers of `hg' did (the `hg grep' command). and
I have found it quite useful by and then: "there used to be some
expression/phrasing/function in the document/source code some time ago and
I recall it contained the pattern XYZ but not the details. question: in
which revision(s) exactly is that stuff? when was it finally deleted?".

is that such a rare situation for other folk?

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

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

[fossil-users] howto `grep' through old revisions

question: is there a straightforward (or sqlite-based) way to `grep'  
through a specified file recursively backward in time through all  
revisions (or until first hit of the search pattern)?


j.

ps: yes, I would know now (after having learned how to use `fossil  
artifact' correctly...) how to write a shell script doing that. but that  
would mean to dump the full content of each revision and pipe it through  
the grep which will become slow if there are too many revisions. so the  
question is whether the functionality is already builtin (possibly  
grepping through the deltas instead).



--
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] how to dump artifact content to stdout


On Sat, 24 Nov 2012 13:12:38 +0100, Martin Gagnon  wrote:

On Sat, Nov 24, 2012 at 5:40 AM, j. v. d. hoff  
wrote:



hi,

I found this statement in the `technical overview' section:

8<**--**
---
When accessing the repository database using raw SQL and the fossil sql
command, the extension function "content()" with a single argument  
which is

the SHA1 hash of an artifact will return the complete undeleted and
uncompressed content of that artifact.
8<**--**
---

since I don't know anything about `sql',I don't understand, how to use
this. could someone please explain what to do, exactly, in order to dump
the content of revision [1234] to stdout (i.e. achieve the functionality
of, e.g., `hg cat -r 1234 some_file.txt')?



Probably you are looking for: "fossil artifact"...


on second thought: yes, indeed but it was not obvious: I tried it on one
of the timeline entries but than one only gets the manifest of the  
respective

checkin. I did not realize immediately that I then need to locate the SHA1
of the respective file here (or from doing `finfo' for the file) and  
reissue

`fossil artifact' with _that_ hash again.

so thanks a lot for clarifying this.--

some feedback to the developers:

from a (new) user's perspective I find the procedure a bit tedious  
(compared to `hg cat -r 1234 myfile.txt').

I would say the typical scenario is:

-- identify from the `timeline' checkin-comments at which revision I want  
to look
-- knowing the specific file contained in that checkin I'm interested in  
(usually only one file will have been
   modified, anyway), I would like to issue something like `fossil  
artifact [1234] -f myfile.txt'


having to use first `fsl finfo myfile.txt' in order to get the specific  
artifact hash of the file itself seems unnecessary overhea, especially,
since the layout of the `finfo' output is ragged/confusing: the actually  
relevant SHA1 hash of the file is inlined into the checkin comment and  
appears
at "random" positions in the output. it simply takes 1-2 seconds to long  
to find it I'd say.


would it not be a good idea (and probably easy?) to change the syntax of  
the artifact command to accomodate for such a "one line usage"? sure, not  
an important point, but still...



j.



$ fossil artifact --help
Usage: fossil artifact ARTIFACT-ID ?OUTPUT-FILENAME? ?OPTIONS?

Extract an artifact by its SHA1 hash and write the results on
standard output, or if the optional 4th argument is given, in
the named output file.

Options:
   -R|--repository FILE   Extract artifacts from repository FILE

See also: finfo






Regards,




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

[fossil-users] how to dump artifact content to stdout