I'd suggest: fossil is happy to run wherever it can, and strives for
portability wherever it can, whenever it makes sense.
Any OS is welcome to modify/redistribute fossil in the terms described in
the license.
It sounds to me (correct me if I'm wrong) you are asking "what (or how
many?) operating
[Meta: This message is being intentionally sent to _both of_ the
fossil-users and fossil-dev mailing lists, separately, so as to get the
maximum possible feedback and response. I am currently subscribed to both
lists and will see any response you send to either of them. You need not
cross-post yo
Replying Isaac Jurado:
>
> Index: src/info.c
> ==
> --- src/info.c
> +++ src/info.c
> @@ -1427,11 +1427,11 @@
>if( !g.perm.Read ){ login_needed(); return; }
>if( rid==0 ) fossil_redirect_home();
>if( g.perm.Admin ){
>
Hi, all,
Just in case anyone out there as lost hope (or not yet found it)...
it isn't terribly pretty, but it exists... a very rudimentary
script-implemented timeline command which is built on top of the new
prototype library code...
$ # ./th1ish -f timeline.th1ish -- -n=3
The 3 most recent time
On Tue, Jul 30, 2013 at 10:53 AM, Eric Rubin-Smith wrote:
> I was poking around at the fossil dev timeline and noticed that rebases
> appear to be direct children of the trunk stream, rather than the dev
> stream.
>
> That is, the fossil devs' work-flow seems to be:
>
> * dev says: "let's make a n
I was poking around at the fossil dev timeline and noticed that rebases
appear to be direct children of the trunk stream, rather than the dev
stream.
That is, the fossil devs' work-flow seems to be:
* dev says: "let's make a new feature against the trunk".
* fossil update trunk
*
* fossil commit
On Tue, Jul 30, 2013 at 3:47 PM, Steve Landers wrote:
> Just be careful it doesn't become a coprolith.
>
Most certainly not ;). (This thread has been more educational than
anticipated.)
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
On Tue, Jul 30, 2013 at 1:06 PM, Stephan Beal wrote:
> Hi, all,
>
> As most of you know, work has begun on a prototype of what i unfortunately
> dubbed "fossil v2." As it turns out, everything i want to do can be done on
> top of current repos, with no repo-level incompatibilities (so far, at
> l
libfossil, that's what it is.
But if you want to go down the living fossil path, Coelacanth. Just be careful
it doesn't become a coprolith.
On 30/07/2013, at 8:36 AM, Stephan Beal wrote:
> On Tue, Jul 30, 2013 at 3:33 PM, David Given wrote:
> Stephan Beal wrote:
> > - lib
>
> I really wa
On Tue, Jul 30, 2013 at 9:36 AM, Stephan Beal wrote:
>
>
>> but it's a bit of a mouthful. 'Piltdown', perhaps?
>>
>
> i don't get the reference.
>
The "Piltdown man" was a hoax - https://en.wikipedia.org/wiki/Piltdown_Man
___
fossil-users mailing list
On Tue, Jul 30, 2013 at 3:33 PM, David Given wrote:
> Stephan Beal wrote:
> > - lib
>
> I really want to suggest 'archeoraptor', being a famously fake fossil,
>
LOL! If i was working on a fork, THAT would be the name :).
> but it's a bit of a mouthful. 'Piltdown', perhaps?
>
i don't get the r
Stephan Beal wrote:
[...]
> - lib
I really want to suggest 'archeoraptor', being a famously fake fossil,
but it's a bit of a mouthful. 'Piltdown', perhaps?
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "USER'S MANUAL VERSION 1.0: The information presented in this
│ publication has
On Tue, Jul 30, 2013 at 3:10 PM, wrote:
> That seems to be the obvious choice. But if you want to get creative I
> would vote for a "living fossil".
>
As long as by "living fossil" you don't mean me ;).
- libginkgo - After 170 million years the living Ginkgo biloba looks pretty
> much identical
On 2013-07-30 06:06, Stephan Beal wrote:
The obvious choices include:
- libfossil - nothing wrong with that, IMO.
That seems to be the obvious choice. But if you want to get creative I
would vote for a "living fossil". My fossils are very much alive, thanks
to you guys :)
I'm partial to
On Tue, Jul 30, 2013 at 2:19 PM, Paolo Bolzoni <
paolo.bolzoni.br...@gmail.com> wrote:
> Or libfeather in honor to the fact we now know all dinosaurs had feathers.
> ;)
>
LOL!!
That is apparently only used in a Ruby lib and some "Fan Fiction" site.
Kidding a part I like libfossil, but maybe it
Or libfeather in honor to the fact we now know all dinosaurs had feathers. ;)
Kidding a part I like libfossil, but maybe it is a good occasion to remove the
ambiguity with that filesystem.
On Tue, Jul 30, 2013 at 12:56 PM, Gautier DI FOLCO
wrote:
> 2013/7/30 Remigiusz Modrzejewski
>>
>>
>> On J
2013/7/30 Remigiusz Modrzejewski
>
> On Jul 30, 2013, at 12:06 , Stephan Beal wrote:
>
> > Hi, all,
> >
> > As most of you know, work has begun on a prototype of what i
> unfortunately
> > dubbed "fossil v2." As it turns out, everything i want to do can be done
> on
> > top of current repos, with
On Jul 30, 2013, at 12:06 , Stephan Beal wrote:
> Hi, all,
>
> As most of you know, work has begun on a prototype of what i unfortunately
> dubbed "fossil v2." As it turns out, everything i want to do can be done on
> top of current repos, with no repo-level incompatibilities (so far, at
> least
Hi, all,
As most of you know, work has begun on a prototype of what i unfortunately
dubbed "fossil v2." As it turns out, everything i want to do can be done on
top of current repos, with no repo-level incompatibilities (so far, at
least). That means it's not "really" v2, but instead provides an al
2013/7/30 Lluís Batlle i Rossell :
> But maybe it should not run unless in 'integrate' mode?
That's not possible. This code is part of "fossil commit" while
the --integrate option is from "fossil merge". The "fossil commit"
needs to know whether a previous "fossil merge" had the
--integrate option
On Tue, Jul 30, 2013 at 10:45:31AM +0100, Jan Nijtmans wrote:
> 2013/7/30 Lluís Batlle i Rossell :
> > About the code starting at line 1693, it looks to me like it runs in any
> > case.
> > Does this change only add a new "--integrate", or it also changes the
> > behaviour
> > of usual merges?
>
2013/7/30 Lluís Batlle i Rossell :
> About the code starting at line 1693, it looks to me like it runs in any case.
> Does this change only add a new "--integrate", or it also changes the
> behaviour
> of usual merges?
That code does an additional pass over the vmerge table, in order to
determine
2013/7/30 Lluís Batlle i Rossell :
> Why INTEGR, and not INTEGRATE?
2013/7/30 Stephan Beal :
> For a moment i thought you were trying to save 1 byte from INTEGER and i was
> going to heckle you about it ;). But i see now that it's INTEGRATE. How
> about ..._BY_INTEGR8?
LOL
Well, the colums are no
On Tue, Jul 30, 2013 at 11:11 AM, Jan Nijtmans wrote:
> I made one additional change: adding states
> UPDATED_BY_INTEGR and ADDED_BY_INTEGR
>
For a moment i thought you were trying to save 1 byte from INTEGER and i
was going to heckle you about it ;). But i see now that it's INTEGRATE. How
about
On Tue, Jul 30, 2013 at 10:11:52AM +0100, Jan Nijtmans wrote:
> 2013/7/12 Stephan Beal :
> > On Fri, Jul 12, 2013 at 10:25 AM, Jan Nijtmans wrote:
> >> Well, just try out the "merge-integrate" branch. I would say
> >> the glass is full again.;-)
> >
> > Indeed it is! i like what you've done :)
2013/7/12 Stephan Beal :
> On Fri, Jul 12, 2013 at 10:25 AM, Jan Nijtmans wrote:
>> Well, just try out the "merge-integrate" branch. I would say
>> the glass is full again.;-)
>
> Indeed it is! i like what you've done :)
I made one additional change: adding states
UPDATED_BY_INTEGR and ADDED_B
26 matches
Mail list logo
