Ron W ronw.m...@gmail.com writes:
Reading more about bundles, they appear, in Fossil terms, to be what would
be sent out by a push, or similar to an incremental export (yes, Fossil
supports incremental exports).
Hmm, can you tell me more about incremental exports?
Iirc, using incremental
On Thu, Jul 17, 2014 at 2:35 AM, Gour g...@atmarama.net wrote:
Ron W ronw.m...@gmail.com writes:
Reading more about bundles, they appear, in Fossil terms, to be what
would
be sent out by a push, or similar to an incremental export (yes, Fossil
supports incremental exports).
Hmm, can
On Thu, Jul 17, 2014 at 6:23 PM, Ron W ronw.m...@gmail.com wrote:
The fossil export command has the options --export-marks and
--import-marks for storing and reading RIDs of exported data in a named
file. The first time you create an export to a specific, intended receiving
repo, you use just
On Thu, Jul 17, 2014 at 12:35 PM, Stephan Beal sgb...@googlemail.com
wrote:
On Thu, Jul 17, 2014 at 6:23 PM, Ron W ronw.m...@gmail.com wrote:
The fossil export command has the options --export-marks and
--import-marks for storing and reading RIDs of exported data in a named
file. The first
Hi, all,
the past two months have seen a complete rewrite of my own personal toy
scripting engine, largely inspired by limitations uncovered in it while
binding libfossil to it. As of today, partial libfossil bindings are in
place for the new language (the db abstraction layer is done), and
I keep hoping to make time to work on a Chicken Scheme binding for
libfossil (it would be really help in several projects I'm working on) so
I'm keenly following your progress on libfossil. Anyhow in your post I
couldn't help but think of Greenspuns Tenth Rule of Programming :)
Very interesting project. Somehow, I missed that th1ish wasn't a modified
TH1 engine. While I appreciate a C-like syntax, I am a bit surprised to see
the switch away from TCL-like syntax.
Will be interesting to see how this project compares to other ;scripting
engines designed for embedding,
On Thu, Jul 17, 2014 at 10:06 PM, Ron W ronw.m...@gmail.com wrote:
Very interesting project. Somehow, I missed that th1ish wasn't a modified
TH1 engine. While I appreciate a C-like syntax, I am a bit surprised to see
the switch away from TCL-like syntax.
i kept some of it, but some of it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/17/2014 3:22 PM, Stephan Beal wrote:
in terms of memory use, it seems to be on par with lua, and lua is
the lightest-memory interpreter i've yet run through valgrind. Most
of them individually leak more memory than lua and s2 allocate
On 7/17/14, Andy Goth andrew.m.g...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/17/2014 3:22 PM, Stephan Beal wrote:
in terms of memory use, it seems to be on par with lua, and lua is
the lightest-memory interpreter i've yet run through valgrind. Most
of them
On Thu, Jul 17, 2014 at 10:37 PM, Andy Goth andrew.m.g...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/17/2014 3:22 PM, Stephan Beal wrote:
in terms of memory use, it seems to be on par with lua, and lua is
the lightest-memory interpreter i've yet run through
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
When viewing my local Tk repository clone via [fossil ui] or [fossil
server], accessing any of the attachments for this ticket:
http://core.tcl.tk/tk/info/45bc2252066b706bfea8553c34b13a92ca3bbb3d
results in a Location: header redirecting my browser
On Thu, Jul 17, 2014 at 10:37 PM, Andy Goth andrew.m.g...@gmail.com wrote:
http://wiki.tcl.tk/3840
Interestingly, when i dlclose() modules, valgrind shows dlclose() (or
lt_dlclose()) as leaking memory. It's not safe, generically speaking, to
close DLLs, anyway, because simply opening them
On Thu, Jul 17, 2014 at 10:44 PM, Andy Goth andrew.m.g...@gmail.com wrote:
http://core.tcl.tk/tk/info/45bc2252066b706bfea8553c34b13a92ca3bbb3d
results in a Location: header redirecting my browser to the home URL.
However, when viewing the same repository via the above link, the
attachments
2014-07-17 22:59 GMT+02:00 Stephan Beal sgb...@googlemail.com:
i have no hypothesis. :(
I have seen this before. Explanation follows.
The attachment has been added by a person which didn't have
moderation rights. Later the ticket was moderated and accepted,
but the moderation code doesn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 7/16/2014 11:33 PM, Andy Goth wrote:
On 7/14/2014 9:54 PM, Andy Goth wrote:
When a file has been modified, [fossil diff -brief] reports it
as CHANGED, whereas [fossil status] reports it as EDITED. Is
this inconsistent terminology intentional?
2014-07-17 23:12 GMT+02:00 Jan Nijtmans jan.nijtm...@gmail.com:
2014-07-17 22:59 GMT+02:00 Stephan Beal sgb...@googlemail.com:
i have no hypothesis. :(
I have seen this before. Explanation follows.
This was discussed in sept '13 on the fossil-dev mailing
list, title Fossil sync problem:
Thus said Jan Nijtmans on Thu, 17 Jul 2014 23:29:44 +0200:
This was discussed in sept '13 on the fossil-dev mailing list,
title Fossil sync problem: attachments to tickets. Below Richard's
explanation. Good that my memory is not that bad yet, I wouldn't be
able to find this out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[fossil commit] refuses to commit only selected files when a [fossil
merge] was done. This makes sense, except the test for partial commit
is a bit too simplistic.
Rather than requiring that every modified file be part of the commit,
[fossil commit]
19 matches
Mail list logo
