On Sun, Jul 21, 2013 at 6:54 AM, Stephan Beal wrote:
Hi, all,
>
> This topic has been tossed around before, but the amount of effort
> involved in its undertaking has always kept us from actually doing it...
>
> To help bootstrap the process of figuring out what Fossil v2 might look
> like i have
I am a relatively new Fossil user, and I have not even really stretched
fossil’s muscles yet. However, I have made extensive use of Git and Monotone. I
far preferred Monotone to Git, but the social pressures eventually made me give
up fighting for Monotone and move to Git. I hope that Fossil can
On Mon, Jul 22, 2013 at 5:21 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> On Sun, 21 Jul 2013 17:01:02 -0700 (PDT) Clark Christensen <
> cdcmi...@yahoo.com> wrote:
>
> > Scripting language: I understand the Tcl roots, and I hope you would
> > consider Javascript as a targe
On Sun, Jul 21, 2013 at 1:12 PM, Eduardo Morras wrote:
> b) Plugins and hooks c modules
>
[...]
> c) source code parser, to find where a function, macro, etc... is
> declared
>
For programs in C and C++ (and presumably eventually other programming
languages), the LLVM Compiler Infrastructure
On Mon, Jul 22, 2013 at 4:41 PM, Stephan Beal wrote:
> On Mon, Jul 22, 2013 at 3:28 PM, Remigiusz Modrzejewski <
> l...@maxnet.org.pl> wrote:
>
>>
>> On Jul 21, 2013, at 12:54 , Stephan Beal wrote:
>>
>> > To help bootstrap the process of figuring out what Fossil v2 might look
>> > like i have st
On Mon, Jul 22, 2013 at 09:21:57PM +0200, Lluís Batlle i Rossell wrote:
> Hello,
>
> today I built fossil on cygwin64, and it built but "it didn't work". Cloning,
> a
> line in os_win.c complained about not having permission to create a file (a
> tmp
> file with some kind of random string) in C:
On Mon, Jul 22, 2013 at 9:21 PM, Lluís Batlle i Rossell wrote:
> I've been using happily fossil in cygwin 32-bit since years, and only
> today I
> tried this cygwin64 (completely new for me). Has anyone tried it? Maybe I
> am
> doing something very wrong.
>
Speculation: i _suspect_ that the C mac
Hello,
today I built fossil on cygwin64, and it built but "it didn't work". Cloning, a
line in os_win.c complained about not having permission to create a file (a tmp
file with some kind of random string) in C:/windows.
I wonder... why is it running any os_win code? shouldn't cygwin look like uni
Hi, all!
Wow - the 60+-message v2 thread response has been amazing, and i encourage
you all to keep the input coming. Anyone who wants to participate in the
_completely inofficial_, _complete non-binding_ draft of ideas, just send
me your gmail address off-list and i will be glad to add you. The r
On Mon, Jul 22, 2013 at 2:45 PM, Eric Rubin-Smith wrote:
> I've seen some traffic on this list that touches on the issue, but haven't
> seen anyone offer specific scripts that will let me ingest a CVS repo *plus
> all my CVSTrac tickets* into fossil.
>
> I've successfully used cvs2git to move my
On Mon, Jul 22, 2013 at 9:04 PM, Richard Hipp wrote:
> The stumbling block is that the ticket text is Wiki, but the format for
> Fossil Wiki and CVSTrac Wiki is different, which would require a tricky
> translator.
>
But the ticket system now allows one (IIRC) to change the text type to
plain, w
I've seen some traffic on this list that touches on the issue, but haven't
seen anyone offer specific scripts that will let me ingest a CVS repo *plus
all my CVSTrac tickets* into fossil.
I've successfully used cvs2git to move my repo to a git repo, and
successfully imported the git repo into foss
On Mon, Jul 22, 2013 at 7:26 PM, Martin Gagnon wrote:
> Actually, I've always wonder why the -n option is like this on CLI, and
> why it is different from the n= parameter on the webpage counterpart?. May
> be not a lot of people use it on the CLI?
>
i think we all wonder that ;). It's "historic
Le 22 juil. 2013 12:23, "Stephan Beal" a écrit :
>
> On Mon, Jul 22, 2013 at 6:18 PM, j. van den hoff <
veedeeh...@googlemail.com> wrote:
>>
>> Options:
>> -n|--limit N Output the first N changes (default 20)
>>
>> where the "first" probably should be a "last" or "most recent" I'd say.
>
2013/7/22 Stephan Beal
> On Mon, Jul 22, 2013 at 6:15 PM, Jacek Cała wrote:
>
>>
>>> i am assuming by "each repo" you mean "each clone" (which is also "each
>>> repo"). If that is the case, i can conceive of this working strictly
>>> locally, but i still don't see how it can possibly scale if th
On Mon, Jul 22, 2013 at 5:34 PM, Stephan Beal wrote:
> On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała wrote:
>
>> - project create initializes internal repo ticket number with '1',
>> - project clone adds suffix '.1' to the repo ticket number,
>>
>
Alternate suggestion: we simply print the SHAs in
On Mon, Jul 22, 2013 at 6:31 PM, Jacek Cała wrote:
> Generally, I found not having human readable tickets numbers so difficult
> that I used to embed some sort of identifiers within the ticket name (not
> scalable at all :-(
>
i suspect that using the local db record IDs would be a usable
soluti
On Mon, Jul 22, 2013 at 6:02 PM, Jacek Cała wrote:
> Sorry for not being precise enough. You don't need to change the central
> repo. In fact you don't change any repo at all. Only during cloning you
> create a new 'seed' ticket number. Each repository has its own, ticket
> number prefix, either
On Mon, Jul 22, 2013 at 6:09 PM, j. van den hoff
wrote:
> then I would opt for `-n 0' to get the whole time line. but actually I
> would prefer a `-u(nlimited)' or `-a(ll)' flag or similar. the usefullness
> of --reverse I'm not so sure about, at least I do not miss it right now...
>
-n 0 is alre
On Mon, Jul 22, 2013 at 6:06 PM, David Given wrote:
> SHAs more readable; fortunately I never got around to implementing
> it...
> ...t to call it 'CORRECT HORSE BATTERY', or 'CASE NIGHTMARE GREEN', or
> 'LUMINOUS PANDA UKELELE', or whatever.
>
LOL! Yes, thank goodness you never implemented
2013/7/22 Stephan Beal
> On Mon, Jul 22, 2013 at 6:02 PM, Jacek Cała wrote:
>
>> Sorry for not being precise enough. You don't need to change the central
>> repo. In fact you don't change any repo at all. Only during cloning you
>> create a new 'seed' ticket number. Each repository has its own,
On Mon, 22 Jul 2013 18:12:03 +0200, Stephan Beal
wrote:
On Mon, Jul 22, 2013 at 6:09 PM, j. van den hoff
wrote:
then I would opt for `-n 0' to get the whole time line. but actually I
would prefer a `-u(nlimited)' or `-a(ll)' flag or similar. the
usefullness
of --reverse I'm not so sure ab
On Mon, Jul 22, 2013 at 6:15 PM, Jacek Cała wrote:
>
>> i am assuming by "each repo" you mean "each clone" (which is also "each
>> repo"). If that is the case, i can conceive of this working strictly
>> locally, but i still don't see how it can possibly scale if those numbers
>> propagate in any
On Mon, Jul 22, 2013 at 6:18 PM, j. van den hoff
wrote:
> Options:
> -n|--limit N Output the first N changes (default 20)
>
> where the "first" probably should be a "last" or "most recent" I'd say.
-n is a bit misleading, actually - that limits the number of _lines_ of
output, not the
On Mon, Jul 22, 2013 at 5:52 PM, j. van den hoff
wrote:
> unambiguous sequential numbering of all checkins (just like `hg' has
> always been doing it: checkins are denoted by something like
> 10:0cb3d1256b... where the `10' is the locally valid incremental index of
> the checkin which can be used
On Mon, Jul 22, 2013 at 6:00 PM, Stephan Beal wrote:
> reverse flag so that --reverse -n -1 would show only the first checkin?
>
Correction: --reverse -n 1
or: ... -n -1 | tail -1
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
_
On Mon, 22 Jul 2013 18:01:27 +0200, Stephan Beal
wrote:
On Mon, Jul 22, 2013 at 6:00 PM, Stephan Beal
wrote:
reverse flag so that --reverse -n -1 would show only the first checkin?
then I would opt for `-n 0' to get the whole time line. but actually I
would prefer a `-u(nlimited)' or
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
2013/7/22 Stephan Beal
> On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała wrote:
>
>> - project create initializes internal repo ticket number with '1',
>> - project clone adds suffix '.1' to the repo ticket number,
>>
>
> That would require that cloning change the central repo (because it has to
> a
On Mon, 22 Jul 2013 17:40:23 +0200, Stephan Beal
wrote:
On Mon, Jul 22, 2013 at 5:34 PM, Stephan Beal
wrote:
On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała
wrote:
- project create initializes internal repo ticket number with '1',
- project clone adds suffix '.1' to the repo ticket numb
On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała wrote:
> Hi all,
>
> My 2 cents below regarding ticket numbering:
>
> 2013/7/22 Stephan Beal
>>
>>
>>> * built-in persistent integer ticket numbers in addition to the SHA1
>>> ticket/artifact ID. The SHA1 hexdigest fragments are too geeky for
>>> manag
On Mon, Jul 22, 2013 at 4:47 PM, Jacek Cała wrote:
> - project create initializes internal repo ticket number with '1',
> - project clone adds suffix '.1' to the repo ticket number,
>
That would require that cloning change the central repo (because it has to
assign and store the new number for e
Hi all,
My 2 cents below regarding ticket numbering:
2013/7/22 Stephan Beal
>
> * built-in persistent integer ticket numbers in addition to the SHA1
>> ticket/artifact ID. The SHA1 hexdigest fragments are too geeky for
>> management during the weekly status meeting.
>>
>
> Stable incremental n
On Mon, Jul 22, 2013 at 3:46 PM, Remigiusz Modrzejewski
wrote:
> ...
>
> Ah, this didn't occur to me.
> In our usage GDocs is a poor man's scm.
>
And google takes over the user administration ;)
>
> I agree. I just didn't think of "watch me as I type" aspect of GDocs.
>
Once you get used to
On Jul 22, 2013, at 15:41 , Stephan Beal wrote:
>> And why not a public Fossil repo?
>
> Because GDocs allows multiple people to edit at the same time (or watch
> while someone else edits). Fossil won't ever do that (until/unless there is
> a simple 3rd-party JS API for doing so). i've been typi
On Mon, Jul 22, 2013 at 3:28 PM, Remigiusz Modrzejewski
wrote:
>
> On Jul 21, 2013, at 12:54 , Stephan Beal wrote:
>
> > To help bootstrap the process of figuring out what Fossil v2 might look
> > like i have started writing down ideas in a public Google Doc:
> >
> >
> https://docs.google.com/docu
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 publi
On Mon, Jul 22, 2013 at 3:16 PM, Trevor Davel (Twylite) wrote:
> Hi,
>
>
> On 2013/07/21 12:54 PM, Stephan Beal wrote:
>
>> To help bootstrap the process of figuring out what Fossil v2 might look
>> like i have started writing down ideas in a public Google Doc:
>>
>> https://docs.google.com/**doc
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
On Mon, Jul 22, 2013 at 2:38 PM, Isaac Jurado wrote:
> I'm sorry but I find this a bit confusing. If you want to offer a
> library where programs can link into, what difference does it make by
> assuming it will have a small and concrete set of users?
That's a fair question. My _assumption_ is
On Mon, Jul 22, 2013 at 1:30 PM, Stephan Beal wrote:
>
>> - Ensuring API/ABI compatibility is harder. And this actually
>> slows down development because new features have to be
>> implemented
>
> i don't envision us having to work about this. Fossil is not a
> library with the same us
On Mon, Jul 22, 2013 at 12:00 PM, Stephan Beal wrote:
> * built-in full text search for tickets.
>>
>
> Searching has been one of the most-requested features for fossil lately.
> The main difficulty is that it's not as simple as "select * from xyz where
> field like ..." because artifacts are sto
2013/7/22 Stephan Beal
> Then it starts looking like a message queue, and i personally have no
> intention of seeing fossil grow into such a creature.
>
Keep it simple, RPCs can be queued by an external tool.
___
fossil-users mailing list
fossil-users@
On Mon, Jul 22, 2013 at 1:30 PM, Eduardo Morras wrote:
> Xcb uses an async mechanism, it creates a cookie, sends it and data to the
> external code, keep working. External code calls xcb, sends the cookie with
> the answer. Data and cookie can be exchanged through sql table.
>
Then it starts loo
On Mon, Jul 22, 2013 at 1:06 PM, Isaac Jurado wrote:
> On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado wrote:
> >
> > - Ensuring API/ABI compatibility is harder. And this actually slows
> > down development because new features have to be implemented
>
> Sorry, incomplete sentence:
>
>
On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado wrote:
> Converting Fossil into a library has a lot of downsides:
>
> - Building a library in a platform-independent manner is non-trivial
> (unless making use of things such as libtool or CMake is alright).
>
It can't be any more problematic t
On Mon, 22 Jul 2013 12:20:44 +0200
Stephan Beal wrote:
> On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras wrote:
>
> > ...No, not as hooks, but as plugins. I think that include a scripting
> > engine is great, I'm a lua user, but force to use only one not. Allowing to
> > call external have thi
On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado wrote:
>
> - Ensuring API/ABI compatibility is harder. And this actually slows
> down development because new features have to be implemented
Sorry, incomplete sentence:
New features would have to be implemented in the library first and
2013/7/22 Stephan Beal
> So you envision fossil making RPC calls to other services, correct? The
> JSON API is a sort of RPC service. If we will add scriptable triggers then
> they could do this sort of thing.
>
Yes, it seems to be the simpliest way to do it, to make a hook system "a la
Github"
On Mon, Jul 22, 2013 at 12:28 PM, Stephan Beal wrote:
> On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi
> wrote:
>>
>> Would using something similar to Vim's mechanism (allowing Fossil to
>> be compiled with Lua/Ruby/MZScheme/Python/etc. support) be more
>> acceptable?
>
>
> If the core library h
On Mon, Jul 22, 2013 at 12:21 PM, Arnel Legaspi wrote:
> Would using something similar to Vim's mechanism (allowing Fossil to be
> compiled with Lua/Ruby/MZScheme/Python/etc. support) be more acceptable?
>
If the core library has a sane interface, there's no reason we can't have
ALL of those bind
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 :
+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
On Mon, Jul 22, 2013 at 12:09 PM, Eduardo Morras wrote:
> ...No, not as hooks, but as plugins. I think that include a scripting
> engine is great, I'm a lua user, but force to use only one not. Allowing to
> call external have this advantages:
>
> a) Not tied to one scripting language
> b) In smp
On 7/22/2013 4:29 PM, fossil-users-requ...@lists.fossil-scm.org wrote:
Date: Mon, 22 Jul 2013 10:02:47 +0200
From: Stephan Beal
To: "Fossil SCM user's discussion"
Subject: Re: [fossil-users] Random thoughts on Fossil v2
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"
Hi, Cl
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,
On Mon, Jul 22, 2013 at 12:04 PM, Gautier DI FOLCO <
gautier.difo...@gmail.com> wrote:
> 2013/7/22 Stephan Beal
>>
>> That's an interesting idea. What would you imagine doing with fossil over
>> RPC?
>>
>
> For example putting the calls in queues (ZeroMQ, RabbitMQ, etc.) to make
> asynchronous an
On Sun, 21 Jul 2013 21:15:56 +0200
Stephan Beal wrote:
> > a) when a user sync/merge to trunk in central server, it compile/test
> > the code, after receive but before merge, and if compile/test fails reject
> > sync/merge.
> > b) project management features, global gant graphs, percentage of
2013/7/22 Stephan Beal
>
> That's an interesting idea. What would you imagine doing with fossil over
> RPC?
>
For example putting the calls in queues (ZeroMQ, RabbitMQ, etc.) to make
asynchronous and distributed calls, to have a scallable architecture.
On Mon, Jul 22, 2013 at 11:52 AM, Gautier DI FOLCO <
gautier.difo...@gmail.com> wrote:
> 2013/7/22 Richard Offer
>
>> What about a web-hook type mechanism? If I want to write my hooks in
>> Python, I implement them inside a simple web-server (i.e. python -m
>> SimpleHttpServer), Likewise for any
2013/7/22 Richard Offer
> What about a web-hook type mechanism? If I want to write my hooks in
> Python, I implement them inside a simple web-server (i.e. python -m
> SimpleHttpServer), Likewise for any other interpreted langauge...
>
>
> I agree its not as nice as a real embedded scripting lang
On Mon, Jul 22, 2013 at 11:44 AM, Richard Offer wrote:
> What about a web-hook type mechanism? If I want to write my hooks in
> Python, I implement them inside a simple web-server (i.e. python -m
> SimpleHttpServer), Likewise for any other interpreted langauge...
>
Web hooks is a new topic for m
On Jul 22, 2013, at 9:29 AM, Stephan Beal wrote:
>
> Maybe the shell "should" be the script interface language. But that of course
> rules out usage on Windows, which would upset a great number of people (not
> me ;). i think a scripting language is our only realistic/portable option for
> h
On Sun, 21 Jul 2013 17:01:02 -0700 (PDT)
Clark Christensen wrote:
[...]
> Scripting language: I understand the Tcl roots, and I hope you would
> consider Javascript as a target. JS seems more universal these days.
[...]
Please, don't. JS is a wart right from the start -- supposedly the
only po
It's remarkably slow at work so far today, so here's the answer i promised
for tonight...
On Mon, Jul 22, 2013 at 2:01 AM, Clark Christensen wrote:
> Hi Stephan,
>
> What you propose sounds like the SQLite model where the core is a lib, and
> the part we SCM users interact with is the CLI (or HTT
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 explicitl
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 rea
2013/7/22 Stephan Beal
> The problem is the interpreter. i am not aware of a small embedable JS
> interpreter. SpiderMonkey/Jaegermonkey are complex and poorly documented.
> Google V8 is nice but (A) huge, (B) C++, and (C) they recently made drastic
> API changes which invalidated every single v8
Hi, Clark! A brief response from the office, and a longer one tonight when
i get home...
On Mon, Jul 22, 2013 at 2:01 AM, Clark Christensen wrote:
> Scripting language: I understand the Tcl roots, and I hope you would
> consider Javascript as a target. JS seems more universal these days.
> Maybe
69 matches
Mail list logo
