-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]
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
2014-07-17 23:12 GMT+02:00 Jan Nijtmans :
> 2014-07-17 22:59 GMT+02:00 Stephan Beal :
>> 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: attachments to tickets".
Below Richard's ex
-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 intenti
2014-07-17 22:59 GMT+02:00 Stephan Beal :
> 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 change the attachment itse
On Thu, Jul 17, 2014 at 10:44 PM, Andy Goth 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 display correctly.
On Thu, Jul 17, 2014 at 10:37 PM, Andy Goth 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 might have side effects
whi
-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 t
On Thu, Jul 17, 2014 at 10:37 PM, Andy Goth 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
On 7/17/14, Andy Goth 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 individually leak mor
-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
> comb
On Thu, Jul 17, 2014 at 10:06 PM, Ron W 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 partly conflicts wi
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, like,
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 :)
http://c2.com/cgi/w
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 there'
On Thu, Jul 17, 2014 at 12:35 PM, Stephan Beal
wrote:
>
> On Thu, Jul 17, 2014 at 6:23 PM, Ron W 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 s
On Thu, Jul 17, 2014 at 6:23 PM, Ron W 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 --export-marks.
On Thu, Jul 17, 2014 at 2:35 AM, Gour wrote:
> Ron W 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 incre
18 matches
Mail list logo
