Hello,
The recent static linking discussion made me curious, so I looked into
linking Fossil with musl libc (http://www.musl-libc.org/).
It is pretty straight forward and the resulting binary seems to work
okay, although I did not test it extensively. (My curiosity did not
extend to playing
On 2/1/2013 3:15 PM, K. Fossil user wrote:
Hello,
1/ Thank you very much Edward Berner. You rock my world.
Of course, embedded system must use light libc...
I've seen that some software uses dietlibc.
In my point of view, static linking can be done in this area, so it
will be easier to spread F
On Tue, Feb 5, 2013 at 6:56 PM, wrote:
> Hi,
> I noticed I am getting simple case sensitive differences despite
> having [ ] case-sensitive unchecked in local and remote repos?
> Anything else I need to do?
It sounds like you're reporting that the file *contents* differ in
case as opposed to the
Hi,
I noticed I am getting simple case sensitive differences despite
having [ ] case-sensitive unchecked in local and remote repos?
Anything else I need to do?
fossil version 1.25 [80bf94e0f7] 2013-01-18 21:34:21 UTC
Thanks for fossil!
___
fossil-users m
On 05/02/13 16:51, Stephan Beal wrote:
[...]
> LOL - i know that problem all too well ;). And my boss can unfortunately
> tell the difference between C and Java code :/.
It lives!
https://cowlark.com/calculon/tktview?name=9e114e9de0
https://cowlark.com/calculon/timeline.rss?tkt=9e114e9de0
It's n
On Tue, Feb 05, 2013 at 04:47:37PM +, David Given wrote:
> (Could someone explain the relationship between rids and UUIDs?)
rids are the integer primary keys of the blob table. UUIDs are the
global persistent unique key of the same table. UUIDs stay the same
across repositories, rids depend on
On Tue, Feb 5, 2013 at 5:47 PM, David Given wrote:
> (Could someone explain the relationship between rids and UUIDs?)
>
>From what i understand (perhaps incorrectly), rids are effectively internal
values, and "shouldn't" be used in public access to the data. While they
_are_ (so far) stable, the
Martijn Coppoolse wrote:
[...]
> Not *completely*. The fields starting with `tkt_` are mandatory, and
> can’t be removed. The ticket-ID being one of them, adding it as a
> filtering parameter to the "timeline.rss" feed shouldn’t be problematic.
>
> Filtering on the non-mandatory fields would prob
On Tue, Feb 5, 2013 at 11:29 AM, David Given wrote:
The code doesn't look too complicated. I presume I'd just need to add an
extra URL parameter for the ticket id and then add another condition to
the SELECT statement. I'll have a look.
On 2013-02-05 11:37, Stephan Beal wrote:
For
On Tue, Feb 5, 2013 at 11:29 AM, David Given wrote:
> The code doesn't look too complicated. I presume I'd just need to add an
> extra URL parameter for the ticket id and then add another condition to
> the SELECT statement. I'll have a look.
>
For tickets it's (unfortunately) more complicated t
Martijn Coppoolse wrote:
[...]
> I too have added a set of auto-discovery links to my headers. That way,
> most (desktop) browsers will display a feed icon, which when clicked
> pops up a menu of the different RSS feeds available.
Gosh, I'd forgotten about that... would some more explicit RSS feed
On Tue, Feb 5, 2013 at 11:04 AM, Martijn Coppoolse <
li...@martijn.coppoolse.com> wrote:
> On 4-2-2013 18:58, David Given wrote:
>
>> Is there a similar mechanism for getting the RSS feed *for a specific
>> ticket*? I'd like to be able to point users at it so they can get
>> updates for tickets th
On 4-2-2013 18:58, David Given wrote:
I know there's an unpublicised mechanism for getting the RSS feed of a
timeline --- I'm using it to get notifications of new ticket activity
for my project.
I too have added a set of auto-discovery links to my headers. That way,
most (desktop) browsers wil
13 matches
Mail list logo
