Re: [fossil-users] Random thoughts on Fossil v2

[Joseph R. Justice]

On Sun, Jul 21, 2013 at 6:54 AM, Stephan Beal  wrote:

Hi, all,
>
> This topic has been tossed around before, but the amount of effort
> involved in its undertaking has always kept us from actually doing it...
>
> To help bootstrap the process of figuring out what Fossil v2 might look
> like i have started writing down ideas in a public Google Doc:
>


> If you don't have access to that doc, either send me your gmail address
> and i'll gladly add you, or post your ideas here and i'll integrate them
> into the doc.
>

Some random thoughts on Fossil v2 as a library (call it "libfossil2") and
as a default client / server binary which makes use of the library (call it
"fossil2client" or "fossil2scm", I seem to have used both names), which I
realize you might already know about or have thought of but just in case...
(if only because I have a terminal case of Male Answer Syndrome) (and, wow,
this got longer than I expected, and I apologize in advance for telling you
in detail all about everything you Probably Already Knew and moreover Knew
Far More About Than I Do...):



* Fossil2client should *not* expect or require libfossil2 to be compiled
into it statically, or have an embedded copy of the source for libfossil2
within the source of fossil2client.

Reason why: The various Linux distributions, certainly the major FOSS ones
such as Fedora, Debian, etc, will require this; indeed, if fossil2client is
shipped with an embedded copy of the source for libfossil2, that embedded
copy will be stripped out in favor of the independent library version of
libfossil2 and fossil2client will be compiled to use that independent
library copy.  They don't want to worry about security and other bugs they
have to patch in embedded code copies, etc; they want to fix the bug in one
place, the independent library itself, and let all the users of the library
just naturally benefit from that fix.

Debian, which is the Linux distro I am most familiar with, already does
this (or appears to anyway) with fossil v1, see
http://packages.debian.org/jessie/fossil where the fossil binary depends on
libsqlite3-0 (>= 3.7.11 at this instant).  I don't know if fossil v1 ships
with an embedded code copy of sqlite (I haven't looked), but if it does
they're stripping it in favor of sqlite as an independent library object
and making their binary for fossil v1 dependent on that independent sqlite
library object.

I fully expect they would / will do the same with fossil2scm as a
dependency of libfossil2.



* The library should be implemented in such a way that multiple versions /
generations of it can be installed simultaneously.  Perhaps alternatively,
there should be a mechanism where the library can be queried as to which
API version it is supporting, and/or instructed as to which API version a
client using it understands how to use.

Reason why: Let's say libfossil2 is installed and is supporting API version
Apple.  Let's say two clients making use of libfossil2, namely fossil2scm
and IDEusingfossil2, are installed, and both know how to use libfossil2
with API version Apple.

Now, let's say a new release of libfossil2 is made with API version Berry
(Berry > Apple).  Let's say there is some reason that libfossil2 with API
version Berry is not fully compatible with clients that only know how to
use API version Apple.  Now, fossil2scm, because it comes from the fine
folks who brought you libfossil2, has a new version released in conjunction
with the new version of libfossil2 and the new version of fossil2scm is
compatible with API version Berry.  However, IDEusingfossil2 does not yet
have a new release that understands API version Berry.

A Linux distribution faced with this, which wishes to offer working
versions of libfossil2, fossil2scm, and IDEusingfossil2, needs to be able
to allow for multiple versions of libfossil2 to be installed simultaneously
if it wishes to offer the very latest available versions of libfossil2 and
fossil2scm (because until IDEusingfossil2 can catch up in terms of
development it cannot use the very latest available version of
libfossil2).  Alternatively, the Linux distribution is forced to not offer
the very latest available version of libfossil2 and fossil2scm until such
time as other things which depend on libfossil2 (e.g. IDEusingfossil2) can
be updated to use API version Barry, or else the distribution needs to make
things using API version Berry (e.g. fossil2scm) not simultaneously
installable with things using API version Apple (e.g. IDEusingfossil2).

However, note that if IDEusingfossil2 is able to tell whatever version of
libfossil2 it is linked with "I understand API version Apple, and I need
you to behave precisely as if you are API version Apple", and if libfossil2
is willing and able to obey this requirement, then it would be possible to
update libfossil2 (and other dependencies) to API version Berry even tho
IDEusingfossil2 is not yet updated to understand that API.



* The library should be implemented in suc

[fossil-users] Scripting in Fossil v2

[Aaron W . Hsu]

I am a relatively new Fossil user, and I have not even really stretched 
fossil’s muscles yet. However, I have made extensive use of Git and Monotone. I 
far preferred Monotone to Git, but the social pressures eventually made me give 
up fighting for Monotone and move to Git. I hope that Fossil can provide a 
number of the things that I really enjoyed about Monotone without the 
associated disadvantages. 


This brings me to the discussion that I have seen about Scripting languages in 
DVCS systems. I’m really not sure how I feel about scripting and all of these 
hooks in various DVCS systems, especially in comparison to the relative plug 
and play nature of Fossil. In particular, I am thinking of the very plumbing 
oriented nature of Git, and the very integrated scripting layer, in Lua, for 
Monotone. For one thing, while I enjoy the dirty convenience of the piping and 
UNIX style workflow for most work, I’m not as convinced when it comes to 
version control. 


I’ve so far managed to avoid using the feature myself, but I have been on teams 
where people tried to use this to some effect, and unfortunately, the 
interfaces always seemed to scale very poorly. That’s not to say that they 
cannot be made to scale, but it seems to be a little too fragile for my 
sensibilities. Monotone’s integrated scripting, on the other hand, had another 
problem. From an user’s perspective, I found that the strict support for a 
single scripting language made it difficult to integrate Monotone fully into 
whatever project I was using. While the Lua scripting enabled me to gain a 
level of sophistication and relative rigor in the process more than what I 
could get from normal UNIX plumbing, if my project wasn’t in Lua in the first 
place, I found it breaking my concentration a good deal more than I would have 
liked. 


I feel like there should be a balance when it comes to extensibility. Indeed, I 
think that a good DVCS ought to never require the user to start extending or 
programming their VCS in order to use it normally from day to day. The 
plug-and-play nature of Fossil is a huge advantage to me right now, as it’s so 
simple to use and get running on any given platform and workflow. It just 
works, and does not rely on any extension interface, such as a scripting or 
hook layer to get things done. On the other hand, it seems to me that scripting 
and a programmatic interface *is* very good when it comes to integrating VCS 
into a project’s workflow. It’s this last part that I think should be the 
target of any extensibility. I would argue that, to me, one should not direct 
the programmatic interface towards end-users, but rather, those who wish to 
integrate Fossil into a larger framework. In that case, I see the limitation of 
a single scripting language as a problem. I also think that the ad hoc nature 
of a “text” based interface like UNIX style plumbing to be a problem. Instead, 
perhaps there is a way of creating a public interface to Fossil that allows one 
to reliably extend its functionality without restricting yourself to a single 
language.


Here’s a simple idea of how this might work. Publish a specific interface in C 
against which people can write their code. Allow people to generate shared 
objects that export a specific set of functions for registering or extending 
functionality of the Fossil executable. Then, these executables can be placed 
inside of a specific directory, perhaps found through a set of paths in an 
environment variable. When fossil runs, it can dynamically link in any of the 
shared objects that it finds there, and these can register additional 
functionality with the Fossil system. In this way, people can use whatever 
language they want to use, as long as it has a bi-directional C FFI, which most 
languages I have seen have. The fossil executable will still be shipped as a 
single executable, and people would only need a simple C header file to use the 
extended features, which can be obtained separately. It would have the benefit 
of a rigorously defined interface with more than textual interfaces for 
increased reliability of the code, but people could still use shell scripts if 
that’s what they really wanted to do, they would just have to be dispatched 
from a shared object. 


Just a few thoughts that I have wondered about when it comes to extension 
interfaces. Most of the time I tend not to use them because they don’t work 
with my language or they are too ad hoc for me to rely on. I think the above 
would solve those issues while still keeping Fossil dirt simple for the end 
user. 



-- 
Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us___
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] Random thoughts on Fossil v2

[Joseph R. Justice]

On Mon, Jul 22, 2013 at 5:21 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Sun, 21 Jul 2013 17:01:02 -0700 (PDT) Clark Christensen <
> cdcmi...@yahoo.com> wrote:
>


> > Scripting language: I understand the Tcl roots, and I hope you would
> > consider Javascript as a target.  JS seems more universal these days.
> [...]
>
> Please, don't.  JS is a wart right from the start -- supposedly the
> only popular programming language these days for which a book titled
> "JavaScript: the good parts" has been written, which actually devoted
> to teaching the prospective developers how to *not* use the
> language.


FWIW, there appear to be at least three other "Xyzzy: The Good Parts" books
out there now, all by O'Reilly & Associates, for PHP, Java, and "HTML &
CSS".  (Of course, given the history of these particular programming
languages and technologies, the fact of this isn't necessarily doing
Javascript any favors, I admit.)

I do believe there's also a number of more recent programming languages out
there which are supposed to be nicer / better than Javascript but compile
into it, or are supposed to be safer / better subsets of full Javascript,
or whatever.  Admittedly, because these *are* more recent languages,
they're less mature and likely more unstable / likely to change and perhaps
even change non-trivially.

All this isn't to disparage your charges against Javascript.  I don't
nevessarily disagree with them.  I just think that, perhaps, things are a
little more nuanced or grey than a straight, black and white,
uncompromising stance of "Javascript BAD!"

And, remember, JSON (which I do believe people here are attempting to
incorporate into Fossil) stands for "JavaScript Object Notation" (see
http://www.json.org/ ).  Now, it's not a programming language in and of
itself, but...  *shrug*



Thanks got giving me a moment of your time by reading this.  Hope it's of
some use, interest.  Be well.



Joseph
___
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] Random thoughts on Fossil v2

[Joseph R. Justice]

On Sun, Jul 21, 2013 at 1:12 PM, Eduardo Morras  wrote:


> b) Plugins and hooks c modules
>
[...]

>   c) source code parser, to find where a function, macro, etc... is
> declared
>

For programs in C and C++ (and presumably eventually other programming
languages), the LLVM Compiler Infrastructure Project (LLVM apparently
formerly stood for "Low Level Virtual Machine" but is now not an acronym,
at http://llvm.org/ ) and its subproject Clang ("a C language family
frontend for LLVM", at http://clang.llvm.org/ ) might be of some interest.
The goal, or at least one of the goals, of LLVM is to create modular and
reuseable components which can be used to build all sorts of things,
including (for instance) source code parsers.  It does appear that
implementations (not necessarily the prime or core implementation however)
of many other popular programming languages are also using components of
the LLVM Project.



c) Repository of javascript, th1 code, css
>
>   When starting a new repository I import html, js, css, th1 addons and
> features. If a central repository of those addons exist we, the fossil
> community, could share those addons, f.ex. code to integrate fossil in
> drupal/joomla,
>

At first thought, this almost sounds like something spiritually akin to
CPAN ("Comprehensive Perl Archive Network", at http://www.cpan.org/ ) and
its myriad siblings for all sorts of programming languages and tools.



Thanks for giving me a moment of your time by reading this.  I hope it's of
some use, interest.  Be well.



Joseph
___
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] Random thoughts on Fossil v2

[Baruch Burstein]

On Mon, Jul 22, 2013 at 4:41 PM, Stephan Beal  wrote:

> On Mon, Jul 22, 2013 at 3:28 PM, Remigiusz Modrzejewski <
> l...@maxnet.org.pl> wrote:
>
>>
>> On Jul 21, 2013, at 12:54 , Stephan Beal wrote:
>>
>> > To help bootstrap the process of figuring out what Fossil v2 might look
>> > like i have started writing down ideas in a public Google Doc:
>> >
>> >
>> https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view
>>
>> And why not a public Fossil repo?
>>
>
> Because GDocs allows multiple people to edit at the same time (or watch
> while someone else edits). Fossil won't ever do that (until/unless there is
> a simple 3rd-party JS API for doing so). i've been typing on that doc the
> past 24 hours or so and the people who have it opened can see what i type
> as i type it. (Side-note: once you work with gdocs long enough, then every
> time you type an email you will start to have the feeling that whatever you
> type is visible in real time to those who you will _eventually_ send it to!
> Strange but true.)
>

I am sure I am not the only one who, when typing an email, find myself
typing the first few letters of a word I don't know how to spell or is just
long, and then pressing CTRL+SPACE (for the die-hard vim users, that is
auto-complete in many IDE's)
-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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 on cygwin64

[Martin Gagnon]

On Mon, Jul 22, 2013 at 09:21:57PM +0200, Lluís Batlle i Rossell wrote:
> Hello,
> 
> today I built fossil on cygwin64, and it built but "it didn't work". Cloning, 
> a
> line in os_win.c complained about not having permission to create a file (a 
> tmp
> file with some kind of random string) in C:/windows.
> 
> I wonder... why is it running any os_win code? shouldn't cygwin look like 
> unix, to
> fossil?
> 
> I've been using happily fossil in cygwin 32-bit since years, and only today I
> tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I am
> doing something very wrong.
> 
> I tried both the 'configure' makefile, and Makefile.classic.

I don't know if it can help you,  but I use mingw64 with bash shell from
msys and I don't have this problem. MinGW version should use a bit more
more from the os_win code since it's not emulating a fully posix
environement like cygwin.

I stop building fossil for cygwin long time ago and I found that cygwin
version of fossil was a lot slower (with big repo) and I had problem
when using the same checkout from cygwin and non-cygwin binary.

-- 
Martin G.
___
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 on cygwin64

[Stephan Beal]

On Mon, Jul 22, 2013 at 9:21 PM, Lluís Batlle i Rossell wrote:

> I've been using happily fossil in cygwin 32-bit since years, and only
> today I
> tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I
> am
> doing something very wrong.
>

Speculation: i _suspect_ that the C macros which determine "is this
cygwin/mingw" simply misfire for 64-bit environments.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fossil on cygwin64

[Lluís Batlle i Rossell]

Hello,

today I built fossil on cygwin64, and it built but "it didn't work". Cloning, a
line in os_win.c complained about not having permission to create a file (a tmp
file with some kind of random string) in C:/windows.

I wonder... why is it running any os_win code? shouldn't cygwin look like unix, 
to
fossil?

I've been using happily fossil in cygwin 32-bit since years, and only today I
tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I am
doing something very wrong.

I tried both the 'configure' makefile, and Makefile.classic.

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

[fossil-users] Wow: v2 thoughts responses

[Stephan Beal]

Hi, all!

Wow - the 60+-message v2 thread response has been amazing, and i encourage
you all to keep the input coming. Anyone who wants to participate in the
_completely inofficial_, _complete non-binding_ draft of ideas, just send
me your gmail address off-list and i will be glad to add you. The rules of
engagement are simple: edit at will. This document is in no way sacred.

The doc is here:

Read-only:
https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view

Write (requires access):
https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/edit


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Ingest CVS repo + cvstrac tickets into fossil?

[Richard Hipp]

On Mon, Jul 22, 2013 at 2:45 PM, Eric Rubin-Smith  wrote:

> I've seen some traffic on this list that touches on the issue, but haven't
> seen anyone offer specific scripts that will let me ingest a CVS repo *plus
> all my CVSTrac tickets* into fossil.
>
> I've successfully used cvs2git to move my repo to a git repo, and
> successfully imported the git repo into fossil.  But my CVSTrac tickets are
> still orphans.
>
> I don't care about wiki pages or reports.
>
> The ticket schemas look similar enough that I could possibly hack
> something on my own, but if DRH or someone else intimately familiar with
> the two schemas has already written a conversion utility, all the better.
>
> Does anyone have such a thing?  I see elsewhere in the list that DRH
> mentioned a 200-some-odd-line Tcl script that does at least part of the
> task -- is that published somewhere?
>
>
Nothing that I know of...

You'll notice that (1) Fossil was written to manage SQLite, (2) SQLite was
formerly managed using CVSTrac, (3) none of the old CVSTrac tickets were
carried forward into Fossil.

The stumbling block is that the ticket text is Wiki, but the format for
Fossil Wiki and CVSTrac Wiki is different, which would require a tricky
translator.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Ingest CVS repo + cvstrac tickets into fossil?

[Stephan Beal]

On Mon, Jul 22, 2013 at 9:04 PM, Richard Hipp  wrote:

> The stumbling block is that the ticket text is Wiki, but the format for
> Fossil Wiki and CVSTrac Wiki is different, which would require a tricky
> translator.
>

But the ticket system now allows one (IIRC) to change the text type to
plain, which could(?) be used to import them in some halfway usable form?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Ingest CVS repo + cvstrac tickets into fossil?

[Eric Rubin-Smith]

I've seen some traffic on this list that touches on the issue, but haven't
seen anyone offer specific scripts that will let me ingest a CVS repo *plus
all my CVSTrac tickets* into fossil.

I've successfully used cvs2git to move my repo to a git repo, and
successfully imported the git repo into fossil.  But my CVSTrac tickets are
still orphans.

I don't care about wiki pages or reports.

The ticket schemas look similar enough that I could possibly hack something
on my own, but if DRH or someone else intimately familiar with the two
schemas has already written a conversion utility, all the better.

Does anyone have such a thing?  I see elsewhere in the list that DRH
mentioned a 200-some-odd-line Tcl script that does at least part of the
task -- is that published somewhere?

Thanks to DRH and team for the continued beautiful work.

Eric
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 7:26 PM, Martin Gagnon  wrote:

> Actually, I've always wonder why the -n option is like this on CLI, and
> why it is different from the n= parameter on the webpage counterpart?. May
> be not a lot of people use it on the CLI?
>

i think we all wonder that ;). It's "historical in nature," and probably
best left as-is for the v1 app.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Martin Gagnon]

Le 22 juil. 2013 12:23, "Stephan Beal"  a écrit :
>
> On Mon, Jul 22, 2013 at 6:18 PM, j. van den hoff <
veedeeh...@googlemail.com> wrote:
>>
>> Options:
>>   -n|--limit N Output the first N changes (default 20)
>>
>> where the "first" probably should be a "last" or "most recent" I'd say.
>
>
> -n is a bit misleading, actually - that limits the number of _lines_ of
output, not the number of results (i had forgotten that until now). If the
limit would truncate a given commit then it finishes outputting that before
ending:
>
> stephan@tiny:~/cvs/fossil/cwal/th1ish$ f time -n 2
> === 2013-07-21 ===
> 18:26:43 [77d1757a8b] *CURRENT* Added Object.toJSONString(). Still missing
>  overridable toJSON() support. Moved th1ish_value_XXX_part() to
>  cwal_value_XXX_part(). Added String.applyFormat(). (user: stephan
>  tags: trunk)
>
> stephan@tiny:~/cvs/fossil/cwal/th1ish$ f time -n 4
> === 2013-07-21 ===
> 18:26:43 [77d1757a8b] *CURRENT* Added Object.toJSONString(). Still missing
>  overridable toJSON() support. Moved th1ish_value_XXX_part() to
>  cwal_value_XXX_part(). Added String.applyFormat(). (user: stephan
>  tags: trunk)
>
> (same thing, but if i use -n 5 i get the next entry as well)

Actually, I've always wonder why the -n option is like this on CLI, and why
it is different from the n= parameter on the webpage counterpart?. May be
not a lot of people use it on the CLI?

-- 
Martin G.
___
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] Random thoughts on Fossil v2

[Jacek Cała]

2013/7/22 Stephan Beal 

> On Mon, Jul 22, 2013 at 6:15 PM, Jacek Cała  wrote:
>
>>
>>> i am assuming by "each repo" you mean "each clone" (which is also "each
>>> repo"). If that is the case, i can conceive of this working strictly
>>> locally, but i still don't see how it can possibly scale if those numbers
>>> propagate in any way. If i clone the repo 100 times, do i end up with 1.1
>>> ... 1.100 ?
>>>
>>
>> Yes, that would only mean that your clone tickets will start with
>> '1.100-...' but it doesn't affect clone '1' much. All tickets of '1' are in
>> form of '1-n'
>>
>
> There's the rub. For that to happen, the number needs to be save in the
> repo, which requires write access to the repo for anyone who can clone (and
> guest can clone from most repos). That alone is a potential hole which more
> security-conscious people wouldn't tolerate. If some malicious  ran
> this from 10 shells:
>
> # while true; do rm -f clone.fsl; fossil clone http:// clone.fsl; done
>
> and let it run for a few days, he's just screwed up my numbering so bad
> that i probably won't want to use sequential numbering anymore. It's not
> helpful if my numbers are 8 digits long.
>

Certainly, true... but you can think about a 'superclone' that has the
mentioned feature (with access restrictions), whereas the standard clone
operation would initialize the cloned repo with some random seed not
changing the parent. And even with random seeds you would still have a nice
ticket numbering within your clone.

Generally, I found not having human readable tickets numbers so difficult
that I used to embed some sort of identifiers within the ticket name (not
scalable at all :-(

  Cheers,
  Jacek
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 5:34 PM, Stephan Beal  wrote:

> On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała  wrote:
>
>> - project create initializes internal repo ticket number with '1',
>> - project clone adds suffix '.1' to the repo ticket number,
>>
>
Alternate suggestion: we simply print the SHAs in decimal form ;). They're
not sequential but at least they're human-readable ;).

A lot of people who are _much_ brainier than i have determined that the
sequential numbering problem cannot be solved for DVCS systems, and i tend
to trust their judgement/calculations. As soon as you give up a central
authority, sequential numbering becomes impossible to properly implement.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 6:31 PM, Jacek Cała  wrote:

> Generally, I found not having human readable tickets numbers so difficult
> that I used to embed some sort of identifiers within the ticket name (not
> scalable at all :-(
>

i suspect that using the local db record IDs would be a usable
solution/workaround for this. They won't necessarily be stable across
systems/clones, but that's just a property of the nature of DVCS. i'll add
that to the list momentarily.

i've been editing that gdoc so long now, and so many people of been in and
out of it all day, that when i'm typing emails it feels like you all are
watching as i type my emails. :/

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 6:02 PM, Jacek Cała  wrote:

> Sorry for not being precise enough. You don't need to change the central
> repo. In fact you don't change any repo at all. Only during cloning you
> create a new 'seed' ticket number. Each repository has its own, ticket
> number prefix, either '1' if it is created or '...n.n.1' if it is cloned.
>

When you say "repo" do you mean each clone, or each "central" repo?

Together with this 'seed' each repo has it's last_ticket_number variable
> (initalized with 1) which is a simple integer added to the seed and
> incremented on the 'create ticket' operation. I was to quick to say about
> dots only, so the last_ticket_number is added to the seed with, let say, a
> dash. Then, a ticket number is constructed as '-'.
>

Those would need to be purely local, correct?


> Cloning creates a repository tree:
> 1
> 1.1
> 1.2
> 1.3
> 1.2.1
> etc.
>

In the clone or in the central one?


> whereas creating tickets adds an internal ticket number (independent for
> each repo) and so you can have:
> 1-1, 1-2, 1-3
> 1.1-1, 1.1-2
> 1.2.1-1, 1.2.1-2,...
>
> Is this clearer?
>

i am assuming by "each repo" you mean "each clone" (which is also "each
repo"). If that is the case, i can conceive of this working strictly
locally, but i still don't see how it can possibly scale if those numbers
propagate in any way. If i clone the repo 100 times, do i end up with 1.1
... 1.100 ? What if a malicious person clones my repo in a loop a million
times? If the numbers are local, not a problem, but if they propagate then
that is an attack vector.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 6:09 PM, j. van den hoff
wrote:

> then I would opt for `-n 0' to get the whole time line. but actually I
> would prefer a `-u(nlimited)' or `-a(ll)' flag or similar. the usefullness
> of --reverse I'm not so sure about, at least I do not miss it right now...
>

-n 0 is already interpreted as some default, so that would break anyone
depending on the current semantics. -u is used for USER (maybe not in the
CLI version). i don't think -a is used, but i recently added that to the
'search' command, so there is a precedence for it.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 6:06 PM, David Given  wrote:

> SHAs more readable; fortunately I never got around to implementing
> it...
> ...t to call it 'CORRECT HORSE BATTERY', or 'CASE NIGHTMARE GREEN', or
> 'LUMINOUS PANDA UKELELE', or whatever.
>

LOL! Yes, thank goodness you never implemented it ;). XKCD actually had a
comic on that:

http://xkcd.com/936/

he "proves" that CORRECT HORSE BATTERY is actually less secure because it's
more memorable (see, you've already memorized it ;).


> Done right this gives a lossless bidirectional mapping from hashes to
> codenames. The difficult bit, of course, is coming up with the codename
> dictionary (and being able to use the codenames with a straight face).
>

i would certainly like to see a proof of concept, but i can't imagine being
taken seriously when i post a message saying, "guys, can you please review
commit BASIC ORANGE MONKEY and tell me what you think?" ;)

But that WOULD be a funny proof-of-concept plugin for the v2 API.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Jacek Cała]

2013/7/22 Stephan Beal 

> On Mon, Jul 22, 2013 at 6:02 PM, Jacek Cała  wrote:
>
>> Sorry for not being precise enough. You don't need to change the central
>> repo. In fact you don't change any repo at all. Only during cloning you
>> create a new 'seed' ticket number. Each repository has its own, ticket
>> number prefix, either '1' if it is created or '...n.n.1' if it is cloned.
>>
>
> When you say "repo" do you mean each clone, or each "central" repo?
>

Each clone


> Together with this 'seed' each repo has it's last_ticket_number variable
>> (initalized with 1) which is a simple integer added to the seed and
>> incremented on the 'create ticket' operation. I was to quick to say about
>> dots only, so the last_ticket_number is added to the seed with, let say, a
>> dash. Then, a ticket number is constructed as '-'.
>>
>
> Those would need to be purely local, correct?
>

Indeed, both just local variables, both set on clone operation.


>
>
>> Cloning creates a repository tree:
>> 1
>> 1.1
>> 1.2
>> 1.3
>> 1.2.1
>> etc.
>>
>
> In the clone or in the central one?
>

These are the seeds of each of the clones. '1' is the primary repo created
with 'fossil init', others are clones, e.g. '1.2.1' comes from cloning
'1.2' which is the second clone of '1'.


>
>> whereas creating tickets adds an internal ticket number (independent for
>> each repo) and so you can have:
>> 1-1, 1-2, 1-3
>> 1.1-1, 1.1-2
>> 1.2.1-1, 1.2.1-2,...
>>
>> Is this clearer?
>>
>
> i am assuming by "each repo" you mean "each clone" (which is also "each
> repo"). If that is the case, i can conceive of this working strictly
> locally, but i still don't see how it can possibly scale if those numbers
> propagate in any way. If i clone the repo 100 times, do i end up with 1.1
> ... 1.100 ?
>

Yes, that would only mean that your clone tickets will start with
'1.100-...' but it doesn't affect clone '1' much. All tickets of '1' are in
form of '1-n'


> What if a malicious person clones my repo in a loop a million times? If
> the numbers are local, not a problem, but if they propagate then that is an
> attack vector.
>

The only downside I see is that if a malicious person did that (given you
have enough network bandwith) and you clone your repo next time, your
tickets will start with prefix '1.100-'.


> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Random thoughts on Fossil v2

[j. van den hoff]

On Mon, 22 Jul 2013 18:12:03 +0200, Stephan Beal   
wrote:



On Mon, Jul 22, 2013 at 6:09 PM, j. van den hoff
wrote:


then I would opt for `-n 0' to get the whole time line. but actually I
would prefer a `-u(nlimited)' or `-a(ll)' flag or similar. the  
usefullness
of --reverse I'm not so sure about, at least I do not miss it right  
now...




-n 0 is already interpreted as some default, so that would break anyone
depending on the current semantics. -u is used for USER (maybe not in the
CLI version). i don't think -a is used, but i recently added that to the
'search' command, so there is a precedence for it.



`-n 1' and `-n 0' currently seem to do the same thing: showing the last  
checkin. this does not even seem consistent ( -n 0 probably right now  
should show nothing?) and the CLI does neither use -u nor -a as `timeline'  
options, so this should work, right?


another small observation: fossil help timeline contains the statement:

Options:
  -n|--limit N Output the first N changes (default 20)

where the "first" probably should be a "last" or "most recent" I'd say.







--
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 6:15 PM, Jacek Cała  wrote:

>
>> i am assuming by "each repo" you mean "each clone" (which is also "each
>> repo"). If that is the case, i can conceive of this working strictly
>> locally, but i still don't see how it can possibly scale if those numbers
>> propagate in any way. If i clone the repo 100 times, do i end up with 1.1
>> ... 1.100 ?
>>
>
> Yes, that would only mean that your clone tickets will start with
> '1.100-...' but it doesn't affect clone '1' much. All tickets of '1' are in
> form of '1-n'
>

There's the rub. For that to happen, the number needs to be save in the
repo, which requires write access to the repo for anyone who can clone (and
guest can clone from most repos). That alone is a potential hole which more
security-conscious people wouldn't tolerate. If some malicious  ran
this from 10 shells:

# while true; do rm -f clone.fsl; fossil clone http:// clone.fsl; done

and let it run for a few days, he's just screwed up my numbering so bad
that i probably won't want to use sequential numbering anymore. It's not
helpful if my numbers are 8 digits long.

i used to think that fossil was immune to the attentions of "those sorts of
people" but i have had my own fossil wikis attacked/replaced by bots (due
to a permissions mishap, not a fossil bug), so i'm weary of anything which
gives anyone any sort of write access which i don't explicitly give them.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 6:18 PM, j. van den hoff
wrote:

> Options:
>   -n|--limit N Output the first N changes (default 20)
>
> where the "first" probably should be a "last" or "most recent" I'd say.


-n is a bit misleading, actually - that limits the number of _lines_ of
output, not the number of results (i had forgotten that until now). If the
limit would truncate a given commit then it finishes outputting that before
ending:

stephan@tiny:~/cvs/fossil/cwal/th1ish$ f time -n 2
=== 2013-07-21 ===
18:26:43 [77d1757a8b] *CURRENT* Added Object.toJSONString(). Still missing
 overridable toJSON() support. Moved th1ish_value_XXX_part() to
 cwal_value_XXX_part(). Added String.applyFormat(). (user: stephan
 tags: trunk)

stephan@tiny:~/cvs/fossil/cwal/th1ish$ f time -n 4
=== 2013-07-21 ===
18:26:43 [77d1757a8b] *CURRENT* Added Object.toJSONString(). Still missing
 overridable toJSON() support. Moved th1ish_value_XXX_part() to
 cwal_value_XXX_part(). Added String.applyFormat(). (user: stephan
 tags: trunk)

(same thing, but if i use -n 5 i get the next entry as well)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 5:52 PM, j. van den hoff
wrote:

> unambiguous sequential numbering of  all checkins (just like `hg' has
> always been doing it: checkins are denoted by something like
> 10:0cb3d1256b... where the `10' is the locally valid incremental index of
> the checkin which can be used instead of the sha1 hash in all commands).
> one obvious example being inspection of diffs between consecutive checkins.
>

We could probably use the local db record IDs for that purpose. They might
be 3-5 digits and not necessarily incremented in steps of one (because
blobs are used for various purposes), but they would be sequential in time
(at least in theory).


> as would be a facility to get the complete timeline output without having
> to guess/enter a sufficiently large number for the `-n' flag
>

The simplest change would be for it to interpret negative values as
"unlimited", and maybe add a --reverse flag so that --reverse -n -1 would
show only the first checkin?


> and of course `grep'.
>

There is some code for this but it only looks in local files, so it's just
a glorified (and platform-neutral) version of the /usr/bin/grep. In any
case, i've added a section on "search" to the doc.

i'm off of work starting Wednesday and will attempt to set up a skeleton
app where we can start prototyping/experimenting (while making no sort of
commitments). It occurred to me today that the command line arg processing
is app-level, not lib-level, and there's lots of "pre-work" i can do there
without having any concrete details about the library.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 6:00 PM, Stephan Beal  wrote:

> reverse flag so that --reverse -n -1 would show only the first checkin?
>

Correction: --reverse -n 1
or: ... -n -1 | tail -1

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[j. van den hoff]

On Mon, 22 Jul 2013 18:01:27 +0200, Stephan Beal   
wrote:


On Mon, Jul 22, 2013 at 6:00 PM, Stephan Beal   
wrote:



reverse flag so that --reverse -n -1 would show only the first checkin?


then I would opt for `-n 0' to get the whole time line. but actually I  
would prefer a `-u(nlimited)' or `-a(ll)' flag or similar. the usefullness  
of --reverse I'm not so sure about, at least I do not miss it right now...






Correction: --reverse -n 1
or: ... -n -1 | tail -1




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Random thoughts on Fossil v2

[David Given]

Stephan Beal wrote:
[...]
> Alternate suggestion: we simply print the SHAs in decimal form ;).
> They're not sequential but at least they're human-readable ;).

A while back I did come up with an astoundingly stupid idea for making
SHAs more readable; fortunately I never got around to implementing it...

The idea is: take the first few bytes of the hash, split it up into 7 or
8 bit chunks, and look each one up in a dictionary. This gives us a
codename for the hash. So, instead of referring to a bug as 639ab1, we
get to call it 'CORRECT HORSE BATTERY', or 'CASE NIGHTMARE GREEN', or
'LUMINOUS PANDA UKELELE', or whatever.

The advantage of this is that the randomly-generated names are vastly
more memorable than the hashes. I'd probably want to limit it to three
words, maybe four if you push it; depending on the size of the codename
dictionary this would probably give about  20 to 30 bits of entropy.
Tweaking the algorithm to prevent duplications would probably also be a
good idea.

Done right this gives a lossless bidirectional mapping from hashes to
codenames. The difficult bit, of course, is coming up with the codename
dictionary (and being able to use the codenames with a straight face).

(I should point out that what3words.com is doing something very similar
for locations, although their codenames seem to be database keys
generated on demand rather than encoding the location directly.)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "USER'S MANUAL VERSION 1.0:  The information presented in this
│ publication has been carefully for reliability." --- anonymous
│ computer hardware manual



signature.asc
Description: OpenPGP digital signature
___
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] Random thoughts on Fossil v2

[Jacek Cała]

2013/7/22 Stephan Beal 

> On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała  wrote:
>
>> - project create initializes internal repo ticket number with '1',
>> - project clone adds suffix '.1' to the repo ticket number,
>>
>
> That would require that cloning change the central repo (because it has to
> assign and store the new number for each clone) and would be open to attack
> by simply cloning the repo in a loop. If i clone it 10 times (and i've
> _certainly_ cloned the main fossil repo at least that many times) then i
> end up with 10 different numbers after the dot.
>
> Hundreds, if no thousands, of clones of the core fossil repo and tcl repos
> exists. i don't see this approach working for those two trees.
>
> Or am i missing/misunderstanding some detail?
>

Sorry for not being precise enough. You don't need to change the central
repo. In fact you don't change any repo at all. Only during cloning you
create a new 'seed' ticket number. Each repository has its own, ticket
number prefix, either '1' if it is created or '...n.n.1' if it is cloned.

Together with this 'seed' each repo has it's last_ticket_number variable
(initalized with 1) which is a simple integer added to the seed and
incremented on the 'create ticket' operation. I was to quick to say about
dots only, so the last_ticket_number is added to the seed with, let say, a
dash. Then, a ticket number is constructed as '-'.

Cloning creates a repository tree:
1
1.1
1.2
1.3
1.2.1
etc.

whereas creating tickets adds an internal ticket number (independent for
each repo) and so you can have:
1-1, 1-2, 1-3
1.1-1, 1.1-2
1.2.1-1, 1.2.1-2,...

Is this clearer?

  Cheers,
  Jacek
___
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] Random thoughts on Fossil v2

[j. van den hoff]

On Mon, 22 Jul 2013 17:40:23 +0200, Stephan Beal   
wrote:


On Mon, Jul 22, 2013 at 5:34 PM, Stephan Beal   
wrote:


On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała   
wrote:



- project create initializes internal repo ticket number with '1',
- project clone adds suffix '.1' to the repo ticket number,



Alternate suggestion: we simply print the SHAs in decimal form ;).  
They're

not sequential but at least they're human-readable ;).

A lot of people who are _much_ brainier than i have determined that the
sequential numbering problem cannot be solved for DVCS systems, and i  
tend

to trust their judgement/calculations. As soon as you give up a central
authority, sequential numbering becomes impossible to properly implement.



that issue has come up before and I believe you are right w.r.t. a  
globally valid sequential numbering being impossible (and translating the  
'topology' of checkins and repos/clones by something like 1.2.3 does not  
seem to help much, either, although it sure is possible in principle).


still, I would _much_ prefer to be able to perform all local actions on a  
repo using _locally_ unambiguous sequential numbering of  all checkins  
(just like `hg' has always been doing it: checkins are denoted by  
something like 10:0cb3d1256b... where the `10' is the locally valid  
incremental index of the checkin which can be used instead of the sha1  
hash in all commands). one obvious example being inspection of diffs  
between consecutive checkins.


I also have never heard that use of such sequential numbering has caused  
confusion for hg users (as long as it is understood not to talk about  
"checkin number 10" across different clones of the project repo).


for the wishlist: this would be 'nice to have'.
as would be a facility to get the complete timeline output without having  
to guess/enter a sufficiently large number for the `-n' flag

and of course `grep'.


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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała  wrote:
> Hi all,
>
> My 2 cents below regarding ticket numbering:
>
> 2013/7/22 Stephan Beal 
>>
>>
>>> * built-in persistent integer ticket numbers in addition to the SHA1
>>> ticket/artifact ID.  The SHA1 hexdigest fragments are too geeky for
>>> management during the weekly status meeting.
>>
>>
>> Stable incremental numbers are literally not possible to solve for
>> DCVS systems, which is why the SHA's (geeky/unwieldy as they are) are
>> used.
>
> I wrote some time ago about this as I think you can have a simple,
> relatively easy to grasp ticket numbering in DCVS (not integer
> though). It involves three simple steps:
>
> - project create initializes internal repo ticket number with '1',
> - project clone adds suffix '.1' to the repo ticket number,

Like this?

Origin: 1
Clone Origin to A: 1.1
Clone Origin to B: 1.2
Clone A to C: 1.1.1
Clone A to D: 1.1.2
Clone B to E: 1.2.1
Clone B to F: 1.2.2

A creates ticket: 1.1.1
B creates ticket: 1.2.1

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała  wrote:

> - project create initializes internal repo ticket number with '1',
> - project clone adds suffix '.1' to the repo ticket number,
>

That would require that cloning change the central repo (because it has to
assign and store the new number for each clone) and would be open to attack
by simply cloning the repo in a loop. If i clone it 10 times (and i've
_certainly_ cloned the main fossil repo at least that many times) then i
end up with 10 different numbers after the dot.

Hundreds, if no thousands, of clones of the core fossil repo and tcl repos
exists. i don't see this approach working for those two trees.

Or am i missing/misunderstanding some detail?

:-?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Jacek Cała]

Hi all,

My 2 cents below regarding ticket numbering:

2013/7/22 Stephan Beal 

>
> * built-in persistent integer ticket numbers in addition to the SHA1
>> ticket/artifact ID.  The SHA1 hexdigest fragments are too geeky for
>> management during the weekly status meeting.
>>
>
> Stable incremental numbers are literally not possible to solve for DCVS
> systems, which is why the SHA's (geeky/unwieldy as they are) are used.
>

I wrote some time ago about this as I think you can have a simple,
relatively easy to grasp ticket numbering in DCVS (not integer though). It
involves three simple steps:
- project create initializes internal repo ticket number with '1',
- project clone adds suffix '.1' to the repo ticket number,
- creating a ticket increases the last number after the last dot or the
only number if it is the primary project repository.

Having this you would end up with a tree of ticket numbers like:
'1', '2',...
'1.1', '1.2', ...
'2.1', '2.2', ...

and it would reflect the tree structure of all repositories of a project.

  Cheers,
  Jacek
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 3:46 PM, Remigiusz Modrzejewski
wrote:

> ...
>


> Ah, this didn't occur to me.
> In our usage GDocs is a poor man's scm.
>

And google takes over the user administration ;)


>
> I agree. I just didn't think of "watch me as I type" aspect of GDocs.
>

Once you get used to it, it ALWAYS feels like someone is watching what you
type. :/ Kinda creepy.

If it got implemented in Fossil, that would be a huge red blinking warning
> sign that it went astray.
>

Amen!

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Remigiusz Modrzejewski]

On Jul 22, 2013, at 15:41 , Stephan Beal wrote:

>> And why not a public Fossil repo?
> 
> Because GDocs allows multiple people to edit at the same time (or watch
> while someone else edits). Fossil won't ever do that (until/unless there is
> a simple 3rd-party JS API for doing so). i've been typing on that doc the
> past 24 hours or so and the people who have it opened can see what i type
> as i type it.

Ah, this didn't occur to me.
In our usage GDocs is a poor man's scm.

>> The answer to this question may give some insight into what's not perfect
>> with Fossil...
>> 
> 
> We could also argue that fossil is not "perfect" because it does not
> support real-time collaborative editing, but i think that would be
> overstating the problem. There are lots of things fossil neither does nor
> should do.

I agree. I just didn't think of "watch me as I type" aspect of GDocs.
If it got implemented in Fossil, that would be a huge red blinking warning sign 
that it went astray.


Kind regards,
Remigiusz Modrzejewski



___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 3:28 PM, Remigiusz Modrzejewski
wrote:

>
> On Jul 21, 2013, at 12:54 , Stephan Beal wrote:
>
> > To help bootstrap the process of figuring out what Fossil v2 might look
> > like i have started writing down ideas in a public Google Doc:
> >
> >
> https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view
>
> And why not a public Fossil repo?
>

Because GDocs allows multiple people to edit at the same time (or watch
while someone else edits). Fossil won't ever do that (until/unless there is
a simple 3rd-party JS API for doing so). i've been typing on that doc the
past 24 hours or so and the people who have it opened can see what i type
as i type it. (Side-note: once you work with gdocs long enough, then every
time you type an email you will start to have the feeling that whatever you
type is visible in real time to those who you will _eventually_ send it to!
Strange but true.)


> The answer to this question may give some insight into what's not perfect
> with Fossil...
>

We could also argue that fossil is not "perfect" because it does not
support real-time collaborative editing, but i think that would be
overstating the problem. There are lots of things fossil neither does nor
should do.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Remigiusz Modrzejewski]

On Jul 21, 2013, at 12:54 , Stephan Beal wrote:

> To help bootstrap the process of figuring out what Fossil v2 might look
> like i have started writing down ideas in a public Google Doc:
> 
> https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view

And why not a public Fossil repo?

The answer to this question may give some insight into what's not perfect with 
Fossil...


Kind regards,
Remigiusz Modrzejewski



___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 3:16 PM, Trevor Davel (Twylite)  wrote:

> Hi,
>
>
> On 2013/07/21 12:54 PM, Stephan Beal wrote:
>
>> To help bootstrap the process of figuring out what Fossil v2 might look
>> like i have started writing down ideas in a public Google Doc:
>>
>> https://docs.google.com/**document/d/12g0s5A2TPX7-**
>> y47Nsw235rvsjcuh49TnHfMDB4ASvl**o/view
>>
>
> One feature I would love to see in Fossil v2 (or v1) is support for
> tracking code reviews.  This would cover finding commits that require
> review, flagging the commit once the review has been completed, and
> reporting on what has been reviewed (and by whom).
>
> One approach would be to have non-propagating review tags on commits,
> specifically including the ability to search for unreviewed commits by
> branch.
>

Speaking of: being able to tag non-branches (e.g. tagging individual wiki
pages or files) is something i'd like to add/see added to v2.


> An alternative realisation would be to automatically create "Review"
> tickets for any commit on a branch that has a specific propagating tag
> indicating that review is required.
>

That sounds like a fairly straightforward implementation which could fit in
the current architecture.

All added to the list...

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Trevor Davel (Twylite)]

Hi,

On 2013/07/21 12:54 PM, Stephan Beal wrote:
To help bootstrap the process of figuring out what Fossil v2 might 
look like i have started writing down ideas in a public Google Doc:


https://docs.google.com/document/d/12g0s5A2TPX7-y47Nsw235rvsjcuh49TnHfMDB4ASvlo/view


One feature I would love to see in Fossil v2 (or v1) is support for 
tracking code reviews.  This would cover finding commits that require 
review, flagging the commit once the review has been completed, and 
reporting on what has been reviewed (and by whom).


One approach would be to have non-propagating review tags on commits, 
specifically including the ability to search for unreviewed commits by 
branch.


An alternative realisation would be to automatically create "Review" 
tickets for any commit on a branch that has a specific propagating tag 
indicating that review is required.


Example interaction sequence:
1) Find commits on branch "release" that have not been reviewed.
2) Perform review.  Flag commit as "reviewed-ok" or "reviewed-rework" or 
"noreview (part of [abcdef])".

3) Repeat until all commits have been reviewed.
4) Show timeline for "release", highlights unreviewed commits; includes 
detail of which user marked each commit as reviewed.


Regards,
Twylite

___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 2:38 PM, Isaac Jurado  wrote:

> I'm sorry but I find this a bit confusing.  If you want to offer a
> library where programs can link into, what difference does it make by
> assuming it will have a small and concrete set of users?


That's a fair question. My _assumption_ is that fossil's user base would
not be one who is affected by binary incompatibility problems, for a couple
reasons:

a) the vast majority won't be directly using the library, but will be using
the binary
b) the number of users is small compared to, e.g., git.
c) the preferred embedding approach (IMO) should be an "amalgamation build"
(like sqlite does), which basically gets rid of binary compatibility
problems.
d) after this restructuring/rewrite, i expect more services to be more
readily available over network interfaces (which don't have binary
compatibility problems, just data format compatibility).



@All: i really appreciate the continued feedback. The Google Doc has had
1-5 users viewing it almost full-time since yesterday. (i cannot see who
they are with the exception of those who have explicit write access - all
others show up as anonymous.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 1:30 PM, Stephan Beal  wrote:
>
>>   - Ensuring API/ABI compatibility is harder.  And this actually
>> slows down development because new features have to be
>> implemented
>
> i don't envision us having to work about this.  Fossil is not a
> library with the same uses as, say, sqlite3. If we have to concern
> ourselves with this level of compatibility then fossil has probably
> gotten more popular than i expected.  In any case, i do not envision
> most people using the library - they will have a single binary (built
> on top of the library).  The library would be there so that fossil can
> finally be integrated into places like IDEs.

I'm sorry but I find this a bit confusing.  If you want to offer a
library where programs can link into, what difference does it make by
assuming it will have a small and concrete set of users?  That code will
need maintenance too, and a compatibility compromise if often necessary
for practical reasons.

Regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Baruch Burstein]

On Mon, Jul 22, 2013 at 12:00 PM, Stephan Beal wrote:

>  * built-in full text search for tickets.
>>
>
> Searching has been one of the most-requested features for fossil lately.
> The main difficulty is that it's not as simple as "select * from xyz where
> field like ..." because artifacts are stored as deltas (which are useless
> for searching purposes). So to search an artifact its body has to be
> recreated from its baseline and deltas. To find out what version of a file
> a given search term was in we have to rebuild _every_ version of that file
> and then remember them long enough to be able to report the search results
> to the user. Take a large file, llke sqlite3.c, try to search through its
> whole history for the word "sqlite" and you'll probably spend the rest of
> the day waiting on fossil to calculate the results. It "might"(???) make
> more sense to provide searching as an extra tool which effectively builds a
> cache of a "deconstructed" repo, containing "expanded" copies of all
> artifacts, and performs searches against them.
>
>  The full-text index can also be kept in deltas, just not the same format
as the artifact deltas. For each artifact, you just keep a list of terms
that were added and terms that were removed relative to it's parent
artifact. Or it might make sense to keep these deltas (and artifact deltas
too) in reverse order (delta from child), since later versions are wanted
at a higher frequency than older versions.

>
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
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] Random thoughts on Fossil v2

[Gautier DI FOLCO]

2013/7/22 Stephan Beal 

> Then it starts looking like a message queue, and i personally have no
> intention of seeing fossil grow into such a creature.
>

Keep it simple, RPCs can be queued by an external tool.
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras  wrote:

> Xcb uses an async mechanism, it creates a cookie, sends it and data to the
> external code, keep working. External code calls xcb, sends the cookie with
> the answer. Data and cookie can be exchanged through sql table.
>

Then it starts looking like a message queue, and i personally have no
intention of seeing fossil grow into such a creature.


> > To be clear, i often use the words hook/plugin/trigger interchangeably.
>
> They are different. A hook is capability we add to a function, as a
> anonymous function pointer. This way we can "hook" the any function to
> program flow, changing it. A plugin is a module that adds capabilities to
> program. For example Sqlite3 has plugin mechanism to add external
> aggreagate calculations. A trigger is code that executes other code when
> some conditions met.
>

Yes - didn't mean to imply that my (mis)use of the terms was correct ;).



> So the difference is that a hook allows a plugin work when the trigger
> wants.
>

Agreed.


> That's why I said I confused user with role. The role owns the files, not
> the user. Currently, a user without wiki role capabilities can't modify the
> wiki files.
>

Yes he can - he simply needs to clone it. At that point any access rights
fly out the window.



> Similar, a C developer role can modify /src dir but not /documentation or
> /sql, the DBA role can change /sql but not /src and similar. Role info is
> already exchanged in pull/push/sync, user info not. So in your scenary, a
> user can get the role capabilities and access them.
>

So what happens when i (as a wiki editor) make a change to src/foo.c,
commit it to  my local copy (because locally i have admin access) and then
try to push? i can't, and my repo then gets (permanently) out of sync. i
don't think this model is possible in a DVCS.


> The problem is that a user is admin of his own repository file and can set
> whatever s/he wants and access everything. A global dvcs role and user data
> can solve this, not allowing this user make changes in public branches or
> trunk directories of central repo (or other users repos) if s/he has no
> privileges to do so.
>

Once i clone it, the central repository has NO say-so in what i can and
cannot check out. It can only control what i check IN, or (more correctly),
what i try to push to the central server. If it will not let me push the
changes i have already committed to my local repo then i have a serious
problem.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 1:06 PM, Isaac Jurado  wrote:

> On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado  wrote:
> >
> >   - Ensuring API/ABI compatibility is harder.  And this actually slows
> > down development because new features have to be implemented
>
> Sorry, incomplete sentence:
>
> New features would have to be implemented in the library first and
> then exposed.  That's 150% development overhead.


That may be the case, but isn't necessarily always so. But once we invest
the 150% then the next 3 guys who want to re-use that functionality spend
nearly 0% of the time they would have had to without a library.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado  wrote:

> Converting Fossil into a library has a lot of downsides:
>
>   - Building a library in a platform-independent manner is non-trivial
> (unless making use of things such as libtool or CMake is alright).
>

It can't be any more problematic than making a portable binary. The
majority of fossil's portability-related problems have been in app-level
code on Windows (e.g. converting paths from UTF8 to whatever Windows uses).


>   - A lot of additional code has to be added to avoid being tricked by
> users passing incorrect parameters.
>

That's just part of - a library has to be more careful with its parameters
AND must also report problems instead of just dying immediately.



>
>   - Testing is more tedious; test code needs to be developed in C to
> ensure the calls work.


Not if we script it. sqlite3 runs all its tests in TCL, and it is arguably
the single best-tested open source library in the world.



>  Unless the test code can be generated
> automatically through a scripting language, which is not simple
> either.
>

Once a library interface is in place, adding a script binding is, as a
general rule, very simple. i've bound literally dozens of 3rd-party APIs to
3 different JS interpreters, and the process is more or less always the
same.


>   - Ensuring API/ABI compatibility is harder.  And this actually slows
> down development because new features have to be implemented
>

i don't envision us having to work about this. Fossil is not a library with
the same uses as, say, sqlite3. If we have to concern ourselves with this
level of compatibility then fossil has probably gotten more popular than i
expected. In any case, i do not envision most people using the library -
they will have a single binary (built on top of the library). The library
would be there so that fossil can finally be integrated into places like
IDEs.



>   - Sooner or later, a useful library has to match the following
> requirements:
>
>   * Re-entrant
>   * Thread-safe
>   * Support both synchronous and asynchronous remote operations
>   * Friendly to bindings
>

Thread-safety is not a factor here, i think. Any given instance of a Fossil
context only need be single-threaded (all of the multi-threaded use cases
go out of the project's scope, i think, e.g. parallel threads for
searching). The is, IMO, no reason why fossil would need to support
multiple threads. Reentrace is, in my experience, not a problem so long as
one uses a Context parameter. Asynchronous operations are another place
which i consider to be out of scope for fossil. Being friendly to bindings
 will be a focus of mine - i've got a considerable amount of experience in
this area.


> To match the previous requirements, designs can be come very
> baroque, and therefore, harder to read and maintain.
>

True, but fossil's current code is monolithic and relatively inflexible in
the face of change.



>   - A thorough documentation would be necessary.
>

Not a problem -  both Richard and i are documentation maniacs. My one-man
open source projects are regularly rated in the top 10% most-documented
projects by ohloh.net :). Writing technical docs is a hobby/paste-time of
mine:

https://docs.google.com/presentation/d/1plJbtQZXKBymEiw9sYy9xqnzMleWuYO461R3VrocOWQ/view



>
> But, the worst of all


You say that as if writing docs is a bad thing ;)



> , is that even if the library is greande-proof, you
> would be indirectly hit by bugs in external software using it.
>

That's just part of it. Right now we're in the situation that fossil cannot
fit in places it should be able to fit (e.g. SCM support in IDEs) because
it is monolithic.


> Even Git, with its humongous manpower, has struggled a couple of years
> to make an incomplete library.
>

Git has a level of popularity/penetration which (i hope!) never plagues
fossil. As long as fossil stays niche-market, the dev team will have a lot
more freedom in the form of a _lack_ of pressure to conform to requirements
of popular plugins/add-ons.



>
> I'd suggest the Mercurial approach: focus on the JSON API and offer it
> over multiple transports (HTTP, SSH, UNIX sockets, pipes).


Actually, that's kind of how the JSON API was started. Richard asked, "what
does Fossil need?" to which i answered, "a library." After agreeing that
the effort would be huge, i settled for JSON (which is, in effect, a
network-linked DLL). However, some of fossil's primary features cannot fit
into JSON without significant shoe-horning. e.g. commits may require binary
data, for which there is no JSON equivalent.



> Then let
> anybody interested on integrating develop a client in their language of
> choice.  Because JSON has first-class support in almost any computer
> language, bindings would not be necessary and the current process model
> could be kept.
>

the JSON API can, in principal, proxy most of fossil's operations. There
are a handful of th

Re: [fossil-users] Random thoughts on Fossil v2

[Eduardo Morras]

On Mon, 22 Jul 2013 12:20:44 +0200
Stephan Beal  wrote:

> On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras  wrote:
> 
> > ...No, not as hooks, but as plugins. I think that include a scripting
> > engine is great, I'm a lua user, but force to use only one not. Allowing to
> > call external have this advantages:
> >
> > a) Not tied to one scripting language
> > b) In smp environments, the script will run on other processor (or even
> > remotely)
> > c) It can work asyncronous, fossil may not wait the script ends
> >
> 
> For some checks Fossil _must_ wait on the script to end. How can it do a
> commit confirmation check if it doesn't wait on the results?

Xcb uses an async mechanism, it creates a cookie, sends it and data to the 
external code, keep working. External code calls xcb, sends the cookie with the 
answer. Data and cookie can be exchanged through sql table.

> To be clear, i often use the words hook/plugin/trigger interchangeably.

They are different. A hook is capability we add to a function, as a anonymous 
function pointer. This way we can "hook" the any function to program flow, 
changing it. A plugin is a module that adds capabilities to program. For 
example Sqlite3 has plugin mechanism to add external aggreagate calculations. A 
trigger is code that executes other code when some conditions met. 

So the difference is that a hook allows a plugin work when the trigger wants.

> > Perhaps I mixed the concept of user and role. I thought more about the
> > concept of file owner. By default all users owns all files, but some roles,
> > like superuser or project architect, own some files or dirs and only
> > him/her/it can modify them.
> >
> 
> i think that would be impossible to implement properly in a DVCS (it would
> be possible in a centralized SCM). When i clone your repo, i need access to
> ALL of the files i cloned. If i cannot check out or modify certain files
> just because you "own" them, the repo is useless to me. It means that if a
> developer dies (as they occasionally do) then all of his locks are there
> forever. This doesn't sound realistic to me. One of the things fossil
> promises which other SCMs do not is "forever" - it's data format is
> designed to outlive the software, which means that in 200 years someone
> could read the fossil data format, import an ancient sqlite3 fossil DB into
> his sqlite27 db, and get back to work. Except that now he can't make
> changes because the files in the repo belong to another user ;).

That's why I said I confused user with role. The role owns the files, not the 
user. Currently, a user without wiki role capabilities can't modify the wiki 
files. Similar, a C developer role can modify /src dir but not /documentation 
or /sql, the DBA role can change /sql but not /src and similar. Role info is 
already exchanged in pull/push/sync, user info not. So in your scenary, a user 
can get the role capabilities and access them. 

The problem is that a user is admin of his own repository file and can set 
whatever s/he wants and access everything. A global dvcs role and user data can 
solve this, not allowing this user make changes in public branches or trunk 
directories of central repo (or other users repos) if s/he has no privileges to 
do so.


---   ---
Eduardo Morras 
___
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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado  wrote:
>
>   - Ensuring API/ABI compatibility is harder.  And this actually slows
> down development because new features have to be implemented

Sorry, incomplete sentence:

New features would have to be implemented in the library first and
then exposed.  That's 150% development overhead.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Gautier DI FOLCO]

2013/7/22 Stephan Beal 

> So you envision fossil making RPC calls to other services, correct? The
> JSON API is a sort of RPC service. If we will add scriptable triggers then
> they could do this sort of thing.
>

Yes, it seems to be the simpliest way to do it, to make a hook system "a la
Github" as said Laurens Van Houtven.
___
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] Random thoughts on Fossil v2

[Isaac Jurado]

On Mon, Jul 22, 2013 at 12:28 PM, Stephan Beal  wrote:
> On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi 
> wrote:
>>
>> Would using something similar to Vim's mechanism (allowing Fossil to
>> be compiled with Lua/Ruby/MZScheme/Python/etc. support) be more
>> acceptable?
>
>
> If the core library has a sane interface, there's no reason we can't
> have ALL of those bindings - they just need to be implemented by
> someone. For example, as soon as fossil has a library API, i will
> certainly write a binding for it for my own personal scripting
> language (not because the world needs it, but because that's the type
> of thing i do in my free time), and being able to implement such
> bindings will be a point i focus on when designing any fossil library
> interface.

Converting Fossil into a library has a lot of downsides:

  - Building a library in a platform-independent manner is non-trivial
(unless making use of things such as libtool or CMake is alright).

  - A lot of additional code has to be added to avoid being tricked by
users passing incorrect parameters.

  - Testing is more tedious; test code needs to be developed in C to
ensure the calls work.  Unless the test code can be generated
automatically through a scripting language, which is not simple
either.

  - Ensuring API/ABI compatibility is harder.  And this actually slows
down development because new features have to be implemented

  - Sooner or later, a useful library has to match the following
requirements:

  * Re-entrant
  * Thread-safe
  * Support both synchronous and asynchronous remote operations
  * Friendly to bindings

To match the previous requirements, designs can be come very
baroque, and therefore, harder to read and maintain.

  - A thorough documentation would be necessary.

But, the worst of all, is that even if the library is greande-proof, you
would be indirectly hit by bugs in external software using it.

Even Git, with its humongous manpower, has struggled a couple of years
to make an incomplete library.

I'd suggest the Mercurial approach: focus on the JSON API and offer it
over multiple transports (HTTP, SSH, UNIX sockets, pipes).  Then let
anybody interested on integrating develop a client in their language of
choice.  Because JSON has first-class support in almost any computer
language, bindings would not be necessary and the current process model
could be kept.

Best regards.

-- 
Isaac Jurado

"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi wrote:

> Would using something similar to Vim's mechanism (allowing Fossil to be
> compiled with Lua/Ruby/MZScheme/Python/etc. support) be more acceptable?
>

If the core library has a sane interface, there's no reason we can't have
ALL of those bindings - they just need to be implemented by someone. For
example, as soon as fossil has a library API, i will certainly write a
binding for it for my own personal scripting language (not because the
world needs it, but because that's the type of thing i do in my free time),
and being able to implement such bindings will be a point i focus on when
designing any fossil library interface.


> - use of Markdown formatting in tickets (unless, this is already possible?)
>

It might make sense long-term to combine the wiki/ticket editing features,
or replace the wiki with the embedded docs system. There is no reason why
we need separate editing systems (wiki vs tickets). Being able to attach a
Content Type to a wiki page is on the todo list, so that people can flag
their pages as being for a specific parser.


> - +1 for full text search in tickets...and maybe embedded wiki files if
> possible
>

It's more difficult than it sounds, unfortunately. My current thinking is
that this would be best done via an add-on tool which normalizes the db
structure into something we can search.


> - support for kernel-style commit messages:
> For example, you have a commit message like this:
>
> Capitalized, short summary line
>
>  72 characters or less>
>

IMO fossil must not force arbitrary conventions like this onto the users.
(To be clear: my opinion is not the one which ultimately counts!)

(I tried altering the Timeline view CSS for this from a few threads back,
> but it made the Timeline page graph ugly.)
>

Yes, it's difficult to modify the timeline view - it has grown into a truly
complex beast over the years. When working on the JSON bits, the timeline
part was certainly the most painful one to port. One of the goals of a new
API would be to replace such monoliths with smaller parts.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Jan Nijtmans]

2013/7/22 Laurens Van Houtven <_...@lvh.io>:
> Just my 2c: a JSON hook API a la Github would be fantastic.
>
> Documentation: https://help.github.com/articles/post-receive-hooks
>
> It would also hopefully make it easy to re-use existing services with
> fossil, if the spec were sufficiently close :)

A similar think is already in development now, See:

It is meant for "Ticket" and "Commit" hooks, but more hooks
could be added the same way.

Regards,
 Jan Nijtmans
___
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] Random thoughts on Fossil v2

[Laurens Van Houtven]

+1 for a more common markup language (e.g. markdown) :)
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras  wrote:

> ...No, not as hooks, but as plugins. I think that include a scripting
> engine is great, I'm a lua user, but force to use only one not. Allowing to
> call external have this advantages:
>
> a) Not tied to one scripting language
> b) In smp environments, the script will run on other processor (or even
> remotely)
> c) It can work asyncronous, fossil may not wait the script ends
>

For some checks Fossil _must_ wait on the script to end. How can it do a
commit confirmation check if it doesn't wait on the results?



> Of course, with security at first.
>

One of my weak points - i'm very much relying on others to spot any
potential security problems.


> About hooks, thinking more about it, perhaps something more like a
> trigger. For example, in our c projects, we have this on the central
> repositories:
>

To be clear, i often use the words hook/plugin/trigger interchangeably.


> 1) a user syncs to central
> 2) after sync, we must run a script manually that
> 3) checkout last trunk version
> 4) compare trunk with trunk

5) if some change is detected, compile with clang static analyzer, it has
> an option to make an html report
> 6) add the report directory to reports branch
> 7) copy the new trunk to old trunk dir and rm everything else
> 8) close the checkout
>
> It will be great if fossil shoots the script each time trunk is modified,
>

Ideally we'll be able to do that type of thing. We need to define (A) when
various hook points will be triggered, (B) what parameters/data they
receive from fossil, (C) how fossil should deal with various exit/result
codes. e.g. do we just have success/failure, or are there varying degrees
of success/failure? This topic will certainly keep us busy for a while (but
will be very interesting). Once we are far enough along to have a script
binding of some kind we can experiment with this freely before deciding on
concrete semantics.

> i was thinking about that as well, but IMO the current system works
> > remarkably well. It effectively offers up to 26 (or 52) roles, which is
> far
> > more than projects of fossil's scale need. We could perhaps add a
> mechanism
> > to allow clients to add letters to the permissions alphabet. Or toss out
> > the mechanism and do something new. i think a full-fledged role
> management
> > system would be way overkill, but if we're starting from scratch
> anyway...
>
> Perhaps I mixed the concept of user and role. I thought more about the
> concept of file owner. By default all users owns all files, but some roles,
> like superuser or project architect, own some files or dirs and only
> him/her/it can modify them.
>

i think that would be impossible to implement properly in a DVCS (it would
be possible in a centralized SCM). When i clone your repo, i need access to
ALL of the files i cloned. If i cannot check out or modify certain files
just because you "own" them, the repo is useless to me. It means that if a
developer dies (as they occasionally do) then all of his locks are there
forever. This doesn't sound realistic to me. One of the things fossil
promises which other SCMs do not is "forever" - it's data format is
designed to outlive the software, which means that in 200 years someone
could read the fossil data format, import an ancient sqlite3 fossil DB into
his sqlite27 db, and get back to work. Except that now he can't make
changes because the files in the repo belong to another user ;).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Arnel Legaspi]

On 7/22/2013 4:29 PM, fossil-users-requ...@lists.fossil-scm.org wrote:

Date: Mon, 22 Jul 2013 10:02:47 +0200
From: Stephan Beal 
To: "Fossil SCM user's discussion" 
Subject: Re: [fossil-users] Random thoughts on Fossil v2
Message-ID:

Content-Type: text/plain; charset="iso-8859-1"

Hi, Clark! A brief response from the office, and a longer one tonight when
i get home...

On Mon, Jul 22, 2013 at 2:01 AM, Clark Christensen wrote:

Scripting language: I understand the Tcl roots, and I hope you would
consider Javascript as a target.  JS seems more universal these days.
Maybe the Tcl guys would disagree.  I have no idea what that means from an
implementation standpoint.

The problem is the interpreter. i am not aware of a small embedable JS
interpreter. SpiderMonkey/Jaegermonkey are complex and poorly documented.
Google V8 is nice but (A) huge, (B) C++, and (C) they recently made drastic
API changes which invalidated every single v8-using client out there
(breaking 4-5 years of accumulated code of mine, and i'll never have the
time to fix it), which means that very few people outside of Google can
actually use v8 at the moment. JS _would_ also be my first choice, if we
only had a small, well-maintained interpreter.i don't know TCL, but the TCL
and Fossil communities seem to be cosmically bound to one another. There
are relatively few well-established small/embeddable interpreters. Lua,
TCL, ... none others come to mind (which are small).


Would using something similar to Vim's mechanism (allowing Fossil to be 
compiled with Lua/Ruby/MZScheme/Python/etc. support) be more acceptable?


Of course, Vim does have its own scripting language (Vimscript) but this 
"language support" is available to users via the Makefiles.


My own humble requests for Fossil v2 include:

- use of Markdown formatting in tickets (unless, this is already possible?)

- +1 for full text search in tickets...and maybe embedded wiki files if 
possible


- support for kernel-style commit messages:
For example, you have a commit message like this:

Capitalized, short summary line

around 72 characters or less>


Fossil would then show the summary line in the Timeline view, both in 
the web GUI and commandline. Clicking the specific commit would then 
display both the summary line and the explanatory text.


(I tried altering the Timeline view CSS for this from a few threads 
back, but it made the Timeline page graph ugly.)


Thanks, Stephan!

--Arnel
___
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] Random thoughts on Fossil v2

[Laurens Van Houtven]

Hi,


Just my 2c: a JSON hook API a la Github would be fantastic.

Documentation: https://help.github.com/articles/post-receive-hooks

It would also hopefully make it easy to re-use existing services with
fossil, if the spec were sufficiently close :)

cheers
lvh


On Mon, Jul 22, 2013 at 12:10 PM, Stephan Beal wrote:

> On Mon, Jul 22, 2013 at 12:04 PM, Gautier DI FOLCO <
> gautier.difo...@gmail.com> wrote:
>
>> 2013/7/22 Stephan Beal 
>>>
>>> That's an interesting idea. What would you imagine doing with fossil
>>> over RPC?
>>>
>>
>> For example putting the calls in queues (ZeroMQ, RabbitMQ, etc.) to make
>> asynchronous and distributed calls, to have a scallable architecture.
>>
>
> So you envision fossil making RPC calls to other services, correct? The
> JSON API is a sort of RPC service. If we will add scriptable triggers then
> they could do this sort of thing.
> --
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 12:04 PM, Gautier DI FOLCO <
gautier.difo...@gmail.com> wrote:

> 2013/7/22 Stephan Beal 
>>
>> That's an interesting idea. What would you imagine doing with fossil over
>> RPC?
>>
>
> For example putting the calls in queues (ZeroMQ, RabbitMQ, etc.) to make
> asynchronous and distributed calls, to have a scallable architecture.
>

So you envision fossil making RPC calls to other services, correct? The
JSON API is a sort of RPC service. If we will add scriptable triggers then
they could do this sort of thing.
-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Eduardo Morras]

On Sun, 21 Jul 2013 21:15:56 +0200
Stephan Beal  wrote:
> >   a) when a user sync/merge to trunk in central server, it compile/test
> > the code, after receive but before merge, and if compile/test fails reject
> > sync/merge.
> >   b) project management features, global gant graphs, percentage of work
> > done,
> >   c) source code parser, to find where a function, macro, etc... is
> > declared
> >   d) fts of documentation
> >
> 
> If we don't want to write such hooks in C (which might not be practical)
> then a a scripting engine is implied. IMO the right choice, given fossil's
> history, would be TCL, but any option we choose brings with it long-term
> dependencies or maintenance (if we embed a small interpreter like jimtcl or
> lua). To me jimtcl would be the obvious candidate, but i was told at some
> point that it has too many incompatibilities with standard TCL to be of
> interest to the harder-code TCLers.

No, not as hooks, but as plugins. I think that include a scripting engine is 
great, I'm a lua user, but force to use only one not. Allowing to call external 
have this advantages:

a) Not tied to one scripting language
b) In smp environments, the script will run on other processor (or even 
remotely)
c) It can work asyncronous, fossil may not wait the script ends
d) If script fails, fossil will not hang or crash or silently quit
e) Fossil size keeps tiny
f) Scripts can be persistent
g) Update/Bug fix script engine without recompile fossil or wait for a new 
fossil release

Of course, with security at first.

About hooks, thinking more about it, perhaps something more like a trigger. For 
example, in our c projects, we have this on the central repositories:

1) a user syncs to central
2) after sync, we must run a script manually that
3) checkout last trunk version
4) compare trunk with trunk
5) if some change is detected, compile with clang static analyzer, it has an 
option to make an html report
6) add the report directory to reports branch
7) copy the new trunk to old trunk dir and rm everything else
8) close the checkout

It will be great if fossil shoots the script each time trunk is modified, 

> > d) extend user capabilities
> >
> >   Some superuser can own/lock some files in central repository or at
> > least, in trunk. For example makefiles, binary files, project
> > configuration, etc...
> >
> 
> i was thinking about that as well, but IMO the current system works
> remarkably well. It effectively offers up to 26 (or 52) roles, which is far
> more than projects of fossil's scale need. We could perhaps add a mechanism
> to allow clients to add letters to the permissions alphabet. Or toss out
> the mechanism and do something new. i think a full-fledged role management
> system would be way overkill, but if we're starting from scratch anyway...

Perhaps I mixed the concept of user and role. I thought more about the concept 
of file owner. By default all users owns all files, but some roles, like 
superuser or project architect, own some files or dirs and only him/her/it can 
modify them.


---   ---
Eduardo Morras 
___
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] Random thoughts on Fossil v2

[Gautier DI FOLCO]

2013/7/22 Stephan Beal 
>
> That's an interesting idea. What would you imagine doing with fossil over
> RPC?
>

For example putting the calls in queues (ZeroMQ, RabbitMQ, etc.) to make
asynchronous and distributed calls, to have a scallable architecture.
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 11:52 AM, Gautier DI FOLCO <
gautier.difo...@gmail.com> wrote:

> 2013/7/22 Richard Offer 
>
>> What about a web-hook type mechanism?  If I want to write my hooks in
>> Python, I implement them inside a simple web-server (i.e. python -m
>> SimpleHttpServer), Likewise for any other interpreted langauge...
>>
>>
>> I agree its not as nice as a real embedded scripting language - buts its
>> better than picking a scipting langauge that I don't want/like/know :-)
>>
>>
> An RPC mecanism would be cool.
>

That's an interesting idea. What would you imagine doing with fossil over
RPC?

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Gautier DI FOLCO]

2013/7/22 Richard Offer 

> What about a web-hook type mechanism?  If I want to write my hooks in
> Python, I implement them inside a simple web-server (i.e. python -m
> SimpleHttpServer), Likewise for any other interpreted langauge...
>
>
> I agree its not as nice as a real embedded scripting language - buts its
> better than picking a scipting langauge that I don't want/like/know :-)
>
>
An RPC mecanism would be cool.
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 11:44 AM, Richard Offer wrote:

> What about a web-hook type mechanism?  If I want to write my hooks in
> Python, I implement them inside a simple web-server (i.e. python -m
> SimpleHttpServer), Likewise for any other interpreted langauge...
>

Web hooks is a new topic for me - i'll read up on that.


> I agree its not as nice as a real embedded scripting language - buts its
> better than picking a scipting langauge that I don't want/like/know :-)
>

Rest assured, your preferences for a scripting language will play a
significant role in any decision process ;). But if we can avoid tying
ourselves to a single language (and i think we can), then so much the
better.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Richard Offer]

On Jul 22, 2013, at 9:29 AM, Stephan Beal  wrote:

> 
> Maybe the shell "should" be the script interface language. But that of course 
> rules out usage on Windows, which would upset a great number of people (not 
> me ;). i think a scripting language is our only realistic/portable option for 
> hooks.


What about a web-hook type mechanism?  If I want to write my hooks in Python, I 
implement them inside a simple web-server (i.e. python -m SimpleHttpServer), 
Likewise for any other interpreted langauge...


I agree its not as nice as a real embedded scripting language - buts its better 
than picking a scipting langauge that I don't want/like/know :-)


richard.

> 
> -- 
> - stephan beal
> http://wanderinghorse.net/home/stephan/
> http://gplus.to/sgbeal

___
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] Random thoughts on Fossil v2

[Konstantin Khomoutov]

On Sun, 21 Jul 2013 17:01:02 -0700 (PDT)
Clark Christensen  wrote:

[...]
> Scripting language: I understand the Tcl roots, and I hope you would
> consider Javascript as a target.  JS seems more universal these days.
[...]

Please, don't.  JS is a wart right from the start -- supposedly the
only popular programming language these days for which a book titled
"JavaScript: the good parts" has been written, which actually devoted
to teaching the prospective developers how to *not* use the
language.  Yes, there are hordes of (usually underskilled) web
developers who know JS by necessity, but IMO this is not a *technical*
consideration.  All this current hype for JS (node.js included) is a
good display of herd behaviour in human society, something not to be
proud of.
___
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] Random thoughts on Fossil v2

[Stephan Beal]

It's remarkably slow at work so far today, so here's the answer i promised
for tonight...

On Mon, Jul 22, 2013 at 2:01 AM, Clark Christensen wrote:

> Hi Stephan,
>
> What you propose sounds like the SQLite model where the core is a lib, and
> the part we SCM users interact with is the CLI (or HTTP).  From a user's
> standpoint, I'd like to assume the project would provide the "default"
> executable, equivalent to today's fossil executable.
>

Yes, of course - a "default binary" would be an absolute must (even if only
for testing purposes!). i envision the v2 binary being more or less on
parity with v1 in terms of features (eventually).


Overall, I have fear that doing it as a lib would take away the
> "fossilness" of what I'm used to.  Maybe that's to say I have some fear of
> change.
> But I like Fossil's small size and smallish community.  Our community
> remains receptive and polite.
>

i suspect that the "fossilness" of it is what endears many of us to it, and
the intention is certainly not to take that away. This is not about
replacing fossil, per se, but about changing its basis so that other things
can be more easily built around it. e.g. integration of IDE support is a
huge PITA right now because there is no clean basis off of which that
support can be added.

It seems to me that when you publish/maintain an open-source lib, the
> entire dynamic of your user base changes from people interested in using
> your app, and how to make best use of it, to hard-core developers
> trying to build their own product around your lib.  Over the past few
> years, I've noticed the SQLite users mailing list contains a LOT of
> threads about implementing the lib in bigger projects by people who
> don't acknowledge there's any documentation.


Not only that, but they start their posts with, "we've integrated sqlite
into a 120-node cluster, with each one housing 25 GB shards of data in
sqlite3, and we've hit what appears to be a limitation..." i have no
sympathy for them ;)



> Or the conversations dig
> deep into C topics like pointers, memory management, and the like.
> Anyway, I guess my point is, there's a lot less interesting for me there
> than there once was.  And I'd hate for Fossil to go that way.  Probably
> selfish of me.
>

Ideally we can keep the pointer discussions to the fossil-dev list ;)


> OTOH, from a technical standpoint, it does seem like the right approach.
>

Agreed.



> * ticket event notifications, or a table where they're queued for some
> other process to retrieve/send them.
>

Maybe this is a special case of moderation (or maybe moderation is a
special case of this)?


> * built-in full text search for tickets.
>

Searching has been one of the most-requested features for fossil lately.
The main difficulty is that it's not as simple as "select * from xyz where
field like ..." because artifacts are stored as deltas (which are useless
for searching purposes). So to search an artifact its body has to be
recreated from its baseline and deltas. To find out what version of a file
a given search term was in we have to rebuild _every_ version of that file
and then remember them long enough to be able to report the search results
to the user. Take a large file, llke sqlite3.c, try to search through its
whole history for the word "sqlite" and you'll probably spend the rest of
the day waiting on fossil to calculate the results. It "might"(???) make
more sense to provide searching as an extra tool which effectively builds a
cache of a "deconstructed" repo, containing "expanded" copies of all
artifacts, and performs searches against them.


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Stephan Beal]

On Mon, Jul 22, 2013 at 10:20 AM, Laurens Van Houtven <_...@lvh.io> wrote:

> Hi,
>
> While, ceteris paribus, I'd certainly prefer Python, I definitely
> understand that embedding CPython may be more trouble than it's worth. If
> you are going to embed *something*, I'd vote for a langauge explicitly
> designed with that purpose in mind, say, Lua.
>

Python is a very popular choice, but AFAIK none of the fossil devs use it
;). There _is_ a choice of intepreters (i've also got my own i'd like to
use) but TCL "would seem to be" the best fit, given fossil's history. LUA
is small, well-established, and portable but also total alien to most
people (myself included). All that said: if the core library is designed
properly then any number of script bindings can be attached to it. (e.g.
sqlite has at least 10 or 12 script bindings out there.)

However, if this is to happen, I really do think that Fossil shouldn't have
> more than one embedded dynamic language. So, either we do everything with
> TH1, or we have something that replaces TH1...
>

i spent lots of time last summer trying to get th1 to do more than it
currently does. The main problem with it is that it cannot report error
location information, so if you have a 20-line script and a typo on line
18, then you get to search through the first 18 lines to try to find the
mistake. th1 quickly becomes unmanageable for larger scripts.

Definitely a huge +1 for hooks, though; I'd be perfectly happy with
> something that gets passed to system(3)...
>

Maybe the shell "should" be the script interface language. But that of
course rules out usage on Windows, which would upset a great number of
people (not me ;). i think a scripting language is our only
realistic/portable option for hooks.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
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] Random thoughts on Fossil v2

[Laurens Van Houtven]

Hi,

While, ceteris paribus, I'd certainly prefer Python, I definitely
understand that embedding CPython may be more trouble than it's worth. If
you are going to embed *something*, I'd vote for a langauge explicitly
designed with that purpose in mind, say, Lua.

However, if this is to happen, I really do think that Fossil shouldn't have
more than one embedded dynamic language. So, either we do everything with
TH1, or we have something that replaces TH1...

Definitely a huge +1 for hooks, though; I'd be perfectly happy with
something that gets passed to system(3)...

lvh
___
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] Random thoughts on Fossil v2

[Gautier DI FOLCO]

2013/7/22 Stephan Beal 

> The problem is the interpreter. i am not aware of a small embedable JS
> interpreter. SpiderMonkey/Jaegermonkey are complex and poorly documented.
> Google V8 is nice but (A) huge, (B) C++, and (C) they recently made drastic
> API changes which invalidated every single v8-using client out there
> (breaking 4-5 years of accumulated code of mine, and i'll never have the
> time to fix it), which means that very few people outside of Google can
> actually use v8 at the moment. JS _would_ also be my first choice, if we
> only had a small, well-maintained interpreter.i don't know TCL, but the TCL
> and Fossil communities seem to be cosmically bound to one another. There
> are relatively few well-established small/embeddable interpreters. Lua,
> TCL, ... none others come to mind (which are small).
>

I think you can have a look at lo (http://iolanguage.org/) which is a very
tiny programming language.
If I can make a request : clean the code would be great, especially for
those (like me) which have university C skills.

PS : I know, this phrase is not english, sorry for that.
___
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] Random thoughts on Fossil v2

[Stephan Beal]

Hi, Clark! A brief response from the office, and a longer one tonight when
i get home...

On Mon, Jul 22, 2013 at 2:01 AM, Clark Christensen wrote:

> Scripting language: I understand the Tcl roots, and I hope you would
> consider Javascript as a target.  JS seems more universal these days.
> Maybe the Tcl guys would disagree.  I have no idea what that means from an
> implementation standpoint.
>

The problem is the interpreter. i am not aware of a small embedable JS
interpreter. SpiderMonkey/Jaegermonkey are complex and poorly documented.
Google V8 is nice but (A) huge, (B) C++, and (C) they recently made drastic
API changes which invalidated every single v8-using client out there
(breaking 4-5 years of accumulated code of mine, and i'll never have the
time to fix it), which means that very few people outside of Google can
actually use v8 at the moment. JS _would_ also be my first choice, if we
only had a small, well-maintained interpreter.i don't know TCL, but the TCL
and Fossil communities seem to be cosmically bound to one another. There
are relatively few well-established small/embeddable interpreters. Lua,
TCL, ... none others come to mind (which are small).


I use Fossil as much as a straight ticketing system almost as much as I do
> as SCM.  OK, maybe that's an exaggeration :-)  In my company, doing
> anything through channels takes an act of god.  So being able to throw
> together an ad-hoc issue tracker for a project in a matter of an hour is
> valuable.  So, in the ticketing subsystem, I'd like to see, in no
> particular order:
> * built-in persistent integer ticket numbers in addition to the SHA1
> ticket/artifact ID.  The SHA1 hexdigest fragments are too geeky for
> management during the weekly status meeting.
>

Stable incremental numbers are literally not possible to solve for DCVS
systems, which is why the SHA's (geeky/unwieldy as they are) are used.


> * persistent ticket create time built-into the ticket record.  It's tough
> to write aging reports without a create time.  I know I can add it after
> the fact.  I just don't want to have to.
>

Certainly this data is there? (Maybe not as a concrete, field, though?)


> * ticket event notifications, or a table where they're queued for some
> other process to retrieve/send them.
>

This implies hooks, which basically implies scripting, so it's a few levels
of abstraction away from being possible (but is certainly something to be
looked at closely - this has been a long-requested feature).


> Otherwise, Fossil as-is fulfills my needs pretty well.  Though,
> admittedly, my needs are relatively small at about 20 active project
> repos.  The projects themselves are relatively small Perl/JS/HTML/CSS apps
> and the shared code to support them.
>
> Thanks for listening to me ramble :-))
>

Please keep it coming - in my experience users provide far better ideas for
new features than developers tend to.

i'll answer in more detail tonight...

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users