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


On 7/22/2013 4:36 AM, Stephan Beal wrote:
On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras emorr...@yahoo.es 
mailto:emorr...@yahoo.es wrote:


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.




Actually, I think something similar already exists, as shunning.  If you 
commit an artifact to your local repo that has been shunned at the 
central repo you won't be able to push it to the central repo. I didn't 
actually try that, though, so I don't know what the user interface 
behavior is -- perhaps it appears to sync and silently drops the shunned 
artifact.


If the user interface for committing a shunned artifact is or could be 
made friendly enough, then perhaps the requested behavior of user-level 
commit restrictions could be achieved by generalizing the shunning code 
path.  Instead of just deny if artifact is in shunned list, allow 
deny if username is foo and filename is bar.


(I haven't actually looked at the shunning code, though, so it is 
entirely possible that the above would not be feasible.)


--
Edward Berner

___
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


On 7/23/2013 7:22 AM, Stephan Beal wrote:
On Tue, Jul 23, 2013 at 1:54 PM, Eduardo Morras emorr...@yahoo.es 
mailto:emorr...@yahoo.es wrote:


I must insist here ;) There's a distinction, your repository is
not the official Project repository, mine, the central one, yes.


That's the problem - here is no CENTRAL in _D_VCS. As soon as i clone, 
my copy IS a master copy for all intents and purposes.


http://en.wikipedia.org/wiki/Distributed_revision_control

So as soon as i clone yours, both of us have the One True Copy (at 
least as far as Fossil is concerned).




Hmmm... actually, as I understand it, if you clone a Fossil repository 
you'll have all of the files and their history but you won't have the 
entire repository.


Specifically, a repository's local state is not cloned (see 2nd 
paragraph of section 1.0 of 
http://www.fossil-scm.org/index.html/doc/trunk/www/sync.wiki ). Most of 
the local state can be cloned with other commands but you need to go a 
bit out of your way (and have extra permissions?) to do it.


It seems fair for those servers of a project which do house the full 
repository to be referred to as the central servers or central repositories.


--
Edward Berner

___
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


On 7/22/2013 4:20 PM, Joseph R. Justice wrote:
On Mon, Jul 22, 2013 at 5:21 AM, Konstantin Khomoutov 
flatw...@users.sourceforge.net 
mailto:flatw...@users.sourceforge.net wrote:


On Sun, 21 Jul 2013 17:01:02 -0700 (PDT) Clark Christensen
cdcmi...@yahoo.com mailto: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.)




In a similar vein, I think someone once observed that C is the only 
language with an entire book dedicated to describing its traps and 
pitfalls (C Traps and Pitfalls by Andrew Koenig).  Although an Amazon 
search reveals a book titled Java Puzzlers: Traps, Pitfalls, and Corner 
Cases so this may no longer be true.


--
Edward Berner

___
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


On 7/22/2013 1:02 AM, Stephan Beal wrote:


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 cdcmi...@yahoo.com 
mailto: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.  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).




For completeness, I'll mention these:

TinyScheme -- http://tinyscheme.sourceforge.net/home.html

pForth -- http://www.softsynth.com/pforth/

ATLAST -- http://www.fourmilab.ch/atlast/

Although I don't think any of them are a good fit for Fossil.

--
Edward Berner

___
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


On 7/22/2013 1:13 AM, Gautier DI FOLCO wrote:
2013/7/22 Stephan Beal sgb...@googlemail.com 
mailto:sgb...@googlemail.com


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.


From a quick glance at that page it looks like the Io Language is 
implemented in C99, which may preclude it from use in Fossil if (as I 
hope it does) Fossil chooses to remain at C89.


--
Edward Berner

___
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

2013-07-24 Thread BohwaZ

Le Mon, 22 Jul 2013 10:02:47 +0200, Stephan Beal
sgb...@googlemail.com a écrit :

 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 heard one time of a small JS interpreter, probably from the Dillo
browser project, called SEE or Simple ECMAScript Engine. It's also
used in the hv3 web browser (TCL/Tk browser). Although it seems
unmaintained (last release in 2009), I found a new project of a compact
ECMAscript engine called duktape http://www.samivaarala.com/#duktape

 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.

There is out there other encoding algorithms to replace hexa though,
like Bubble Babble which produces pronouceable words (and includes a
checksum), but it produces long strings. So I'm not sure it would be
more practical to speak about ticket
'xesaf-lenaf-denyk-gisof-gosik-guxex' rather than ticket '07d2dd143d'.
Although it would make your weekly meetings sound interesting :)


-- 
BohwaZ|  boh...@bohwaz.net   |   http://bohwaz.net/
---
.oO[ Une citation au hasard ...
En amour, l'important c'est la rencontre et la rupture,
entre les deux, ce n'est que du remplissage.
   ... http://bohwaz.net/misc/fortune  ]Oo.
___
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


On 7/22/2013 7:30 PM, Joseph R. Justice wrote:


OS-level peculiarities: There are other multi-platform software 
projects which have to deal with these, both with peculiarities 
between similar types of platform, such as the various flavors of Unix 
and Linux, and between drastically different platforms, such as 
between the former versus the different versions of Windows, MacOS/X, 
ummm, VMS, the IBM mainframe OSen, etc etc etc.  All the major FOSS 
SQL databases have to deal with this, the Apache web server (Apache 
HTTPD) has to deal with this (they have Apache Portable Runtime IIRC), 
Gnu Emacs has to do this (tho that would certainly involve GPL 
licensed software), I'm sure there's plenty more...  Maybe there's 
stuff that can be stolen ^H^H borrowed from one or more of those to 
avoid having to roll your own.


Not particularly related to Fossil, but C-Kermit is an interesting study 
in extreme C portability.  I like the Program Logic Manual's list of 
guidelines for writing portable C ( 
http://www.kermitproject.org/ckcplm.html#x3 ).  (Note that C-Kermit also 
targets pre-ANSI C so a lot of the advice and techniques aren't relevant 
to Fossil.)




Strict C89 or commonly-supported C99 extensions: What platforms, and 
compilers on those platforms, do you want to be portable to?  If 
everything you care about is (non-buggy) C99, well...


Personally, I'd vote for Fossil to remain C89.  Specifically I'd like 
Microsoft Visual C++ 6.0 on Windows NT 4.0 to continue to be a usable 
target.


--
Edward Berner

___
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

2013-07-24 Thread Stephan Beal

On Wed, Jul 24, 2013 at 9:38 AM, Edward Berner e...@bernerfam.com wrote:

 Personally, I'd vote for Fossil to remain C89.  Specifically I'd like
 Microsoft Visual C++ 6.0 on Windows NT 4.0 to continue to be a usable
 target.


As a matter of course, i never explicitly use any C99 features except for
the 2 headers stdint.h and inttypes.h (for fixed-size integers and their
portable printf/scanf modifiers) but those work just when compiling in c89
mode, assuming your compiler has them. MSVC does not, but there are two
open source projects offering drop-in replacements for these headers for
MSVC. The current prototype code compiles with (-std=c89 -pedantic -Wall
-Werror), but does use those two C99 headers.

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

2013-07-24 Thread Jacek Cała

Hi All,

One more feature that I also miss in the current version is selective
commit. I mean something which allows you to see changes as a numbered list
and then commit selectively e.g. issuing 'fossil commit -range 1-10,15'. It
requires that 'fossil changes' is invoked before commit but that's what
users do I guess (at least me).

I find this feature very useful and it is very common in clients to SVN,
Mercurial, etc. And since fossil has embedded client, I'd really like to
see that as well.

Just to let you know, sometime ago I implemented that for myself as it
wasn't that difficult. It worked really nice, even if you changed file list
between 'fossil changes' and 'fossil commit...' calls by
removing/adding/modifying new files (then it just reported error like: 'run
fossil changes again'). One downside I remember was performance, for larger
commits it took much longer to run 'fossil commit' than 'fossil commit
-range xxx' even if a range was a subset of all changes. This was, however,
my simple, proof of concept implementation...

What do you think?
___
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

2013-07-24 Thread Stephan Beal

On Wed, Jul 24, 2013 at 1:15 PM, Jacek Cała jacek.c...@gmail.com wrote:

 I find this feature very useful and it is very common in clients to SVN,
 Mercurial, etc. And since fossil has embedded client, I'd really like to
 see that as well.


That one's come up a few times - added to the list. A list member recently
(past 2 months or so) posted a mail with a shell script based on 'dialog'
which implements this. Searching isn't turning up it up, but the next time
my netbook is on i'll try to remember to send you a copy.


 Just to let you know, sometime ago I implemented that for myself as it
 wasn't that difficult. It worked really nice, even if you changed file list
 between 'fossil changes' and 'fossil commit...' calls by
 removing/adding/modifying new files (then it just reported error like: 'run
 fossil changes again'). One downside I remember was performance, for larger
 commits it took much longer to run 'fossil commit' than 'fossil commit
 -range xxx' even if a range was a subset of all changes. This was, however,
 my simple, proof of concept implementation...

 What do you think?


i'm trying not to think of such high-level features yet ;). i'm trying to
restrict my focus to basically anything which does not require user
interaction in order to work (interaction includes CLI flags, which are
handled app-level). Nonetheless, i've added this to the list, and can
envision multiple potential implementations (depending on the UI used). (It
might be fun to someday at a simple ncurses-based UI. (Did i really just
say that? curses is called that for a reason!))

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

2013-07-24 Thread Baruch Burstein

On Wed, Jul 24, 2013 at 2:00 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Jul 24, 2013 at 9:38 AM, Edward Berner e...@bernerfam.com wrote:

 Personally, I'd vote for Fossil to remain C89.  Specifically I'd like
 Microsoft Visual C++ 6.0 on Windows NT 4.0 to continue to be a usable
 target.


 As a matter of course, i never explicitly use any C99 features except for
 the 2 headers stdint.h and inttypes.h (for fixed-size integers and their
 portable printf/scanf modifiers) but those work just when compiling in c89
 mode, assuming your compiler has them. MSVC does not, but there are two
 open source projects offering drop-in replacements for these headers for
 MSVC. The current prototype code compiles with (-std=c89 -pedantic -Wall
 -Werror), but does use those two C99 headers.

 Why not use more modern features? I mean, I would probably not shift my
whole codebase to C++11 just yet, but writing new code using C99? Don't all
modern compilers support it already? If I was into really bad puns, I would
say that Fossil is just a name, not a goal.
I really am asking this out of interest why anyone would be against C99.
Having recently graduated and on my first job, I am very interested in what
seems to me to be completely irrational. In the past year I have found that
most irrational things are really just my lack of experience showing :-)

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

2013-07-24 Thread Stephan Beal

On Wed, Jul 24, 2013 at 1:25 PM, Baruch Burstein bmburst...@gmail.comwrote:

 Why not use more modern features? I mean, I would probably not shift my
 whole codebase to C++11 just yet, but writing new code using C99?


i tried that several times over the past years and (A) C99 doesn't provide
anything new which C89 is truly lacking except for portable fixed-sized
integers. It was vararrays and variadic macros, but i can't say i've ever
needed them. (B) MSVC has only minimal support for C99. It's sometimes
annoying to have to group all var decls in one place, but it's not a
feature which we need so badly that we should risk portability limitations
for it.

Don't all modern compilers support it already?


Most support the basic 2-3 features which so many rely on, e.g. //-style
comments and the ability to mix var decls and code. MSVC's support is
reportedly spotty, but i recently read that their new round of compilers
(v2013?) has/will have full C99 support. tcc supports some parts of C99 but
not vararrays. 'long long' is available in most or all modern C89 compilers
(modern C89... :-!), though it wasn't standardized until C99.

If I was into really bad puns, I would say that Fossil is just a name,
 not a goal.


LOL! Maybe that would be a good slogan for the project (it just occurred to
me that we don't have one).


 I really am asking this out of interest why anyone would be against C99.
 Having recently graduated and on my first job, I am very interested in what
 seems to me to be completely irrational. In the past year I have found that
 most irrational things are really just my lack of experience showing :-)


i'd be interested in hearing any arguments for C99 which can't also be done
(with comparable effort) in C89? i've _tried_ to find reasons to rely on
C99 in some code, but simply cannot find anything truly compelling, and
don't want to lose portability just in order to be able to mix var decls
and code.


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

2013-07-24 Thread Michai Ramakers

Hi,

On 24 July 2013 13:25, Stephan Beal sgb...@googlemail.com wrote:

 I find this feature very useful and it is very common in clients to SVN,
 Mercurial, etc. And since fossil has embedded client, I'd really like to see
 that as well.

 That one's come up a few times - added to the list. A list member recently
 (past 2 months or so) posted a mail with a shell script based on 'dialog'
 which implements this. Searching isn't turning up it up, but the next time
 my netbook is on i'll try to remember to send you a copy.

that might have been me - don't bother searching, you type enough as
it is, recently ;) (but please continue)

Script is attached for reference, with minor changes w.r.t. last version.

Michai


fci
Description: Binary data
___
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

On Tue, Jul 23, 2013 at 4:30 AM, Joseph R. Justice jayare...@gmail.comwrote:

 ...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...):


Rabid rants are in no way excluded from participation, provided they remain
polite ;).


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


Right. My goal here is a normal library/client relationship. Static linking
is an important option for fossil (because it's popular with users) but is
not a requirement.


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


Strange. Yes, fossil embeds its own. That dependency was probably
automatically determined by a script which looks for common symbol names in
the resulting binary.



 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 suspect it's only a bookkeeping error, and that (ld fossil) on that
system will reveal that it does not link against /usr/lib/libsqlite3.so


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


They'll probably do what's easiest - if it's distributed as a package which
builds everything together (as i suspect it will be) then they'll probably
just 'make; make install'.


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


Long term that is a good point, and if you have concrete ideas on how best
to achieve this, please elaborate.


 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.


i'm hoping that (A) 95% of the people just keep using the standalone client
binary, (B) that the 5% who don't will use an amalgamation build so that
they do not have such problems :/. That is the official solution sqlite3
recommends, and i see no reason not to do the same for fossil. That said,
sqlite3 has much stricter compatibility requirements than fossil is likely
to have. (Maybe we'll be cursed with success and indeed have to cast the
API in stone at some point, but then there's always v3 to hack on...)


 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.


sqlite has functions which allow you to query the linked in library
version, and fossil would of course have the same.


 * The library should be implemented in such a way that multiple instances
 of the library, and/or multiple different clients using either the same
 instance of the library and/or multiple different instances of the library,
 will not accidentally corrupt fossil repositories.  Note that under
 Unix/Linux many types of file locking (especially network file locking) are
 less than fully secure or reliable.


Those (extremely difficult) details are 100% delegated to sqlite. There's
no reason fossil has no directly deal with them.


 * It might be worthwhile to reach out to the various major Linux and BSD
 Unix distros to see what will make their lives easier in terms of packaging
 and

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

2013-07-23 Thread Eduardo Morras

On Mon, 22 Jul 2013 13:36:37 +0200
Stephan Beal sgb...@googlemail.com wrote:

 On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras emorr...@yahoo.es 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.

And fossil is single thread single process app and can't do any other thing 
while waiting. I applaud the single thread, I dislike threads too, don't 
understand why it must be single process.
 
  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.

Yes it is. There's a big difference between Project and Repository. There's the 
fossil project, only one, but there are lots of repositories and fossil project 
forks that aren't the main 'Fossil Project'. I don't want to restrict what you 
do with your repository or your project fork, I want to restrict what you can 
do to main Project.

  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.

No, I sync with fossil main repository each week, but I don't have permission 
to push my changes. That's because my user (anonymous) don't have the role to 
do so. If I want to push my changes I must convince someone who has the correct 
role to do so. I want to restrict that a developer user, with a defined role, 
can push changes only to certains files/directories of main repository and not 
others. For example, in Fossil, sqlite3.c, sqlite3.h, copyright file, makefile, 
etc... should be changed only by user drh, at least in trunk, because he is the 
project architect. It's true that 'it shouldn't happen if everyone follow the 
manual and touch the files he owns', but there are sometimes, specially with 
newbies, that the repository becomes unusable because they touch a file they 
shouldn't.


---   ---
Eduardo Morras emorr...@yahoo.es
___
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

On Tue, Jul 23, 2013 at 1:04 PM, Eduardo Morras emorr...@yahoo.es wrote:

 Yes it is. There's a big difference between Project and Repository.
 There's the fossil project, only one, but there are lots of repositories
 and fossil project forks that aren't the main 'Fossil Project'. I don't
 want to restrict what you do with your repository or your project fork, I
 want to restrict what you can do to main Project.


That's the problem: my clone of your project is a first-class copy of your
project. There is essentially no distinction. If you copy goes up in flames
me can drop in my copy, re-add the users, and we're done. So here's what
happens with user restrictions:

- i clone your repo
- i edit some dir which you have restricted.
- i check it in locally (offline)
- Later i try to push to your repo and it fails. My repo is now in a state
where i can _never_ push my copy to yours ever again because pushing to
yours will fail as long as i have no access (on your side) for that file.


 No, I sync with fossil main repository each week, but I don't have
 permission to push my changes. That's because my user (anonymous) don't
 have the role to do so. If I want to push my changes I must convince
 someone who has the correct role to do so.


But for partial access ALL pushes from me to you will fail if i have
edited a file to which i cannot push. There is no partial push in fossil
- you can push everything or nothing. Fossil, as a piece of software, could
not possibly decide which parts of my commits are safe to push, and
Fossil _MUST_ fail if _any_ part of my push/sync fails because it has no
heuristic which can say, oh, that was just that file under /noaccess/...
which you edited 3 weeks ago and is still not writable for you (and if it
could decide that, then failing is still the proper response). The only
reasonable action Fossil can take there is to fail. How could it possibly
know which parts are okay and which not? How can i possibly ever recover
my repo to a sane state if you refuse to give me write access to changes i
have already made locally (but not cannot commit, leaving my repo in an
unclean/divergent state).


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

2013-07-23 Thread Eduardo Morras

On Tue, 23 Jul 2013 13:17:47 +0200
Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jul 23, 2013 at 1:04 PM, Eduardo Morras emorr...@yahoo.es wrote:
 
  Yes it is. There's a big difference between Project and Repository.
  There's the fossil project, only one, but there are lots of repositories
  and fossil project forks that aren't the main 'Fossil Project'. I don't
  want to restrict what you do with your repository or your project fork, I
  want to restrict what you can do to main Project.
 
 
 That's the problem: my clone of your project is a first-class copy of your
 project. There is essentially no distinction. If you copy goes up in flames
 me can drop in my copy, re-add the users, and we're done. So here's what
 happens with user restrictions:
 
 - i clone your repo
 - i edit some dir which you have restricted.
 - i check it in locally (offline)
 - Later i try to push to your repo and it fails. My repo is now in a state
 where i can _never_ push my copy to yours ever again because pushing to
 yours will fail as long as i have no access (on your side) for that file.


I must insist here ;) There's a distinction, your repository is not the 
official Project repository, mine, the central one, yes. You can fork and 
create a new project and name it as you wish and change what you want. If you 
want to merge with the Only and Real True Project, your changes must be 
approved by the person that has the permission to do that, that's me. 


  No, I sync with fossil main repository each week, but I don't have
  permission to push my changes. That's because my user (anonymous) don't
  have the role to do so. If I want to push my changes I must convince
  someone who has the correct role to do so.
 
 
 But for partial access ALL pushes from me to you will fail if i have
 edited a file to which i cannot push. There is no partial push in fossil
 - you can push everything or nothing. Fossil, as a piece of software, could
 not possibly decide which parts of my commits are safe to push, and
 Fossil _MUST_ fail if _any_ part of my push/sync fails because it has no
 heuristic which can say, oh, that was just that file under /noaccess/...
 which you edited 3 weeks ago and is still not writable for you (and if it
 could decide that, then failing is still the proper response). The only
 reasonable action Fossil can take there is to fail. How could it possibly
 know which parts are okay and which not? How can i possibly ever recover
 my repo to a sane state if you refuse to give me write access to changes i
 have already made locally (but not cannot commit, leaving my repo in an
 unclean/divergent state).
 
 
 -- 
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal


---   ---
Eduardo Morras emorr...@yahoo.es
___
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

2013-07-23 Thread Matt Welland

Here are a couple features that would make fossil a reasonable replacement
for zim wiki and might be worth considering for fossil2.0.

1. Ability to Edit/save/commit files from the UI.
2. In wiki files square brackets at beginning of line parse into check box
list (as is done in zim wiki).




On Sun, Jul 21, 2013 at 3:54 AM, Stephan Beal sgb...@googlemail.com 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:


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

 Any of you who have write access to the JSON API docs also have write
 access to that one, so feel free to expand/comment/etc. It's just a big
 scratchpad, not a formal doc, nor does it provide any indication of what
 Fossil's future has in store - it's just ideas regarding what v2 might
 look like if i were to start working on it today (which, in a way, i am ;).

 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.

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




-- 
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
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

2013-07-23 Thread Mark Janssen

Bit late to the party, but my 2 cents

1) Fossil as a library or API with the fossil executable as a single file
built on top of it. One could even consider a SCGI/FCGI type of interface
where the fossil binary serves JSON+BSON requests.
2) Ticket notifications by email (notification when merged into my main
repo would be fine). Using the ticketing system for any app with a decent
userbase is a pain right now.

Mark


On Tue, Jul 23, 2013 at 10:35 PM, Matt Welland estifo...@gmail.com wrote:

 Here are a couple features that would make fossil a reasonable replacement
 for zim wiki and might be worth considering for fossil2.0.

 1. Ability to Edit/save/commit files from the UI.
 2. In wiki files square brackets at beginning of line parse into check box
 list (as is done in zim wiki).




 On Sun, Jul 21, 2013 at 3:54 AM, Stephan Beal sgb...@googlemail.comwrote:

 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:


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

 Any of you who have write access to the JSON API docs also have write
 access to that one, so feel free to expand/comment/etc. It's just a big
 scratchpad, not a formal doc, nor does it provide any indication of what
 Fossil's future has in store - it's just ideas regarding what v2 might
 look like if i were to start working on it today (which, in a way, i am ;).

 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.

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




 --
 Matt
 -=-
 90% of the nations wealth is held by 2% of the people. Bummer to be in the
 majority...

 ___
 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

On Tue, Jul 23, 2013 at 10:35 PM, Matt Welland estifo...@gmail.com wrote:

 Here are a couple features that would make fossil a reasonable replacement
 for zim wiki and might be worth considering for fossil2.0.

 1. Ability to Edit/save/commit files from the UI.


That one's been on my TODO for a long time because the JSON API really
wants this for embedded docs (which are just files, so it would then work
for any text file).


 2. In wiki files square brackets at beginning of line parse into check box
 list (as is done in zim wiki).


That's at a much further downstream and the whole Wiki Wars are a topic i'm
gonna side-step for the time being ;). In case you've missed them in the
past... i think wiki-related threads are the only ones who approached this
one's size.



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

On Tue, Jul 23, 2013 at 10:42 PM, Mark Janssen mpc.jans...@gmail.comwrote:

 Bit late to the party, but my 2 cents


Not late at all - the ball's just getting rolling.

1) Fossil as a library or API with the fossil executable as a single file
 built on top of it. One could even consider a SCGI/FCGI type of interface
 where the fossil binary serves JSON+BSON requests.


i think the idea of the lib/app separation is starting to sink in with
people :).


 2) Ticket notifications by email (notification when merged into my main
 repo would be fine). Using the ticketing system for any app with a decent
 userbase is a pain right now.


That one would come almost automatically as a side effect of triggers
support, i suspect, which is high on many peoples' wish lists.

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

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 cdcmi...@yahoo.comwrote:

 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

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

2013/7/22 Stephan Beal sgb...@googlemail.com

 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

2013-07-22 Thread 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

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

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 cdcmi...@yahoo.comwrote:

 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

2013-07-22 Thread Konstantin Khomoutov

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

2013-07-22 Thread Richard Offer


On Jul 22, 2013, at 9:29 AM, Stephan Beal sgb...@googlemail.com 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

On Mon, Jul 22, 2013 at 11:44 AM, Richard Offer rich...@whitequeen.comwrote:

 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

2013/7/22 Richard Offer rich...@whitequeen.com

 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

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

 2013/7/22 Richard Offer rich...@whitequeen.com

 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

2013/7/22 Stephan Beal sgb...@googlemail.com

 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

2013-07-22 Thread Eduardo Morras

On Sun, 21 Jul 2013 21:15:56 +0200
Stephan Beal sgb...@googlemail.com 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 emorr...@yahoo.es
___
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

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

 2013/7/22 Stephan Beal sgb...@googlemail.com

 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

2013-07-22 Thread 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 sgb...@googlemail.comwrote:

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

 2013/7/22 Stephan Beal sgb...@googlemail.com

 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

2013-07-22 Thread 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 sgb...@googlemail.com
To: Fossil SCM user's discussion fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Random thoughts on Fossil v2
Message-ID:
cakd4nah3bxxcg0pbk5w3+nja2hynmbhfp6plgmvu8ykfsaw...@mail.gmail.com
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 cdcmi...@yahoo.comwrote:

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

Detailed explanatory text which can be long, preferably wrapped to 
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

2013-07-22 Thread 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

2013-07-22 Thread 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:
https://www.fossil-scm.org/index.html/timeline?r=tkt-change-hook
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

On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi jalespr...@gmail.comwrote:

 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

 Detailed explanatory text which can be long, preferably wrapped to around
 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

On Mon, Jul 22, 2013 at 12:28 PM, Stephan Beal sgb...@googlemail.com wrote:
 On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi jalespr...@gmail.com
 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

2013/7/22 Stephan Beal sgb...@googlemail.com

 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

On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado dipto...@gmail.com 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

2013-07-22 Thread Eduardo Morras

On Mon, 22 Jul 2013 12:20:44 +0200
Stephan Beal sgb...@googlemail.com wrote:

 On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras emorr...@yahoo.es 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 emorr...@yahoo.es
___
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

On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado dipto...@gmail.com 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 things (namely binary data) which

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

On Mon, Jul 22, 2013 at 1:06 PM, Isaac Jurado dipto...@gmail.com wrote:

 On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado dipto...@gmail.com 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

On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras emorr...@yahoo.es 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

2013/7/22 Stephan Beal sgb...@googlemail.com

 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

2013-07-22 Thread Baruch Burstein

On Mon, Jul 22, 2013 at 12:00 PM, Stephan Beal sgb...@googlemail.comwrote:

  * 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

On Mon, Jul 22, 2013 at 1:30 PM, Stephan Beal sgb...@googlemail.com 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

On Mon, Jul 22, 2013 at 2:38 PM, Isaac Jurado dipto...@gmail.com 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

2013-07-22 Thread 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

On Mon, Jul 22, 2013 at 3:16 PM, Trevor Davel (Twylite) twyl...@crypt.co.za
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/viewhttps://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.

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

2013-07-22 Thread 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

On Mon, Jul 22, 2013 at 3:28 PM, Remigiusz Modrzejewski
l...@maxnet.org.plwrote:


 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

On Mon, Jul 22, 2013 at 3:46 PM, Remigiusz Modrzejewski
l...@maxnet.org.plwrote:

 ...



 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

2013-07-22 Thread Jacek Cała

Hi all,

My 2 cents below regarding ticket numbering:

2013/7/22 Stephan Beal sgb...@googlemail.com


 * 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

On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała jacek.c...@gmail.com 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

On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała jacek.c...@gmail.com wrote:
 Hi all,

 My 2 cents below regarding ticket numbering:

 2013/7/22 Stephan Beal sgb...@googlemail.com


 * 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

2013-07-22 Thread j. van den hoff

On Mon, 22 Jul 2013 17:40:23 +0200, Stephan Beal sgb...@googlemail.com  
wrote:


On Mon, Jul 22, 2013 at 5:34 PM, Stephan Beal sgb...@googlemail.com  
wrote:


On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała jacek.c...@gmail.com  
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

2013-07-22 Thread Jacek Cała

2013/7/22 Stephan Beal sgb...@googlemail.com

 On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała jacek.c...@gmail.com 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 'seed-last_ticket_number'.

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

2013-07-22 Thread 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

2013-07-22 Thread j. van den hoff

On Mon, 22 Jul 2013 18:01:27 +0200, Stephan Beal sgb...@googlemail.com  
wrote:


On Mon, Jul 22, 2013 at 6:00 PM, Stephan Beal sgb...@googlemail.com  
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

On Mon, Jul 22, 2013 at 6:00 PM, Stephan Beal sgb...@googlemail.com 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

On Mon, Jul 22, 2013 at 5:52 PM, j. van den hoff
veedeeh...@googlemail.comwrote:

 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

On Mon, Jul 22, 2013 at 6:18 PM, j. van den hoff
veedeeh...@googlemail.comwrote:

 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

2013-07-22 Thread j. van den hoff

On Mon, 22 Jul 2013 18:12:03 +0200, Stephan Beal sgb...@googlemail.com  
wrote:



On Mon, Jul 22, 2013 at 6:09 PM, j. van den hoff
veedeeh...@googlemail.comwrote:


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

On Mon, Jul 22, 2013 at 6:09 PM, j. van den hoff
veedeeh...@googlemail.comwrote:

 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

On Mon, Jul 22, 2013 at 5:34 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała jacek.c...@gmail.com 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

2013-07-22 Thread Martin Gagnon

Le 22 juil. 2013 12:23, Stephan Beal sgb...@googlemail.com 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