Re: [fossil-users] collaboration with Fossil (was Re: purge/shun single branch(es))
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 import from Git was mentioned by some as not 100% reliable which would make 2-way sync with Git pretty simple. I think your definition of creating conflicts is too narrow. If the both the sending and receiving repos contain a commit to the same parent, there will be a fork. Merging the fork could require resolving conflicts, no different from resolving conflicts from applying a patch. You're right. Maybe I'm still spoiled by Darcs which was shining in this regard. While applying a bundle seems to be a little easier than applying a patch, bundles still need to be created, applied and reviewed. Correct. So, if I were to receive a bundle from a non-core contributor, I would treat it the same as pulling it directly from her/his repo: Clone my repo, apply the bundle to the clone, then review and import changes by diffing between the clone's workspace and my main repo's workspace. Maybe the possible difference is in the last step. With Git one can do the same, but import step is fairly easy if the pull request was rebased on master. Maybe hg/git/bzr/other have mechanisms to automate what I just described. I have not had a need to use such mechanisms so have not researched them.* I am expressing a high level strategy for how I would approach the problem. OK. Fair-enough. Maybe I should just learn to live with Fossil's design decisions in order to enjoy its simplicity. ;) However, I still believe that providing more 'sugar' in the workflow, it could become more attractive to many projects not really neeeding Git(hub). Sincerely, Gour -- Many, many births both you and I have passed. I can remember all of them, but you cannot, O subduer of the enemy! ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] collaboration with Fossil (was Re: purge/shun single branch(es))
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 you tell me more about incremental exports? 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. After that, use bothso that only the new RIDs (since the previous export) will be exported. The fossil import command has an --incremental option. This is used to process export archives created with the --export-marks option. Iirc, using incremental import from Git was mentioned by some as not 100% reliable which would make 2-way sync with Git pretty simple. Some experimentation would be needed to work out a procedure for 2-way sync via export/import, but I'm sure it could be done. Of course, I would hope that the issues with incremental import/export in Git have been resolved. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] collaboration with Fossil (was Re: purge/shun single branch(es))
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 --export-marks. After that, use bothso that only the new RIDs (since the previous export) will be exported. Achtung: RIDs are local to a given copy/clone of a repo, and are not eternal in nature. In theory, a rebuild can change the RIDs (though i don't think it currently does so). It is very possible that two given clones of a repo have different RIDs for the same blobs, in particular if not all work is synced (e.g. local private branches). Some experimentation would be needed to work out a procedure for 2-way sync via export/import, but I'm sure it could be done. Not based on RIDs, at least not reliably. Only the UUIDs are guaranteed to be stable. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] collaboration with Fossil (was Re: purge/shun single branch(es))
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 time you create an export to a specific, intended receiving repo, you use just --export-marks. After that, use bothso that only the new RIDs (since the previous export) will be exported. Achtung: RIDs are local to a given copy/clone of a repo, and are not eternal in nature. In theory, a rebuild can change the RIDs (though i don't think it currently does so). It is very possible that two given clones of a repo have different RIDs for the same blobs, in particular if not all work is synced (e.g. local private branches). Some experimentation would be needed to work out a procedure for 2-way sync via export/import, but I'm sure it could be done. Not based on RIDs, at least not reliably. Only the UUIDs are guaranteed to be stable. I only said RIDs because that's what fossil help export said. The RID file created by the --export-marks and read by the --import-marks would be for the repo the export command is running on. So, barring a rebuild, those RIDs should be valid. A rough cut at a 2-way sync via export/import: 1. Master: fossil export --export-marks RIDs_S1 ForS1.fex 2. S1: fossil import ForS1.fex 3. S1: fossil export --export-marks MyRIDs /dev/null 4. Both sides commit changes 5. Master: fossil export --export-marks RIDs_S1 --export-marks RIDs_S1.new ForS1.fex 6. Master: rm RIDs_S1; mv RIDs_S1.new RIDs_S1 7. S1: fossil export --import-marks MyRIDs --export-marks MyRIDs.new ForMaster.fex 8. S1: rm MyRIDs; mv MyRIDs.new MyRIDs 9. S1: fossil import --incremental ForS1.fex A. S1: fossil export --import-marks MyRIDs --export-marks MyRIDs.new /dev/null B. S1: rm MyRIDs; mv MyRIDs.new MyRIDs C. Master: fossil import --incremental ForMaster.fex D. Master: fossil export --export-marks RIDs_S1 --export-marks RIDs_S1.new /dev/null E. Master: rm RIDs_S1; mv RIDs_S1.new RIDs_S1 F. Repeat steps 4 through E I think I got that right. Definitely requires automating. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] libfossil: new script binding
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's
a demo script here:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/finfo?name=s2/unit2/000-100-db.s2
Unless i get called off of vacation back to work next week, i should have
the remaining bits ported from the older binding by this time next week.
The older binding and this one use the same underlying scripting engine
(just different languages on top of it), so porting has been a
straightforward matter so far. The new scripting language is documented in
inordinate detail (60 pages) here:
https://docs.google.com/document/d/1hvMoHSIz94dob6fCU6SLxle_s7YL6CrA_4aU12OWwWY/view
This one (called, rather uncreatively, s2) is much cleaner than the first
one (th1ish), with a more robust core, proper operator precedence (with
over 30 overloadable operators), and its got (if i may say so)
bordering-on-outstanding memory usage:
https://docs.google.com/document/d/1hvMoHSIz94dob6fCU6SLxle_s7YL6CrA_4aU12OWwWY/view#heading=h.ucmv4mn8r0rw
Ad it's got an interactive shell mode:
[odroid@host:~/fossil/libfossil/s2]$ ./s2sh -v
s2 interactive shell. All commands run in the current scope. Use your
platform's EOF sequence on an empty line to exit. (Ctrl-D on Unix,
Ctrl-Z(?) on Windows.) Ctrl-C might work, too.
The 'g' object is at your service as a place to store things.
s2 var db = Fossil.Db.open(':memory:')
result: Db@0x85778[scope=#1@0xbeecc0d0 ref#=1] == Db@0x85778
s2 db.execMulti(create table t(a); insert into t(a) values(1),(2),(3););
result: Db@0x85778[scope=#1@0xbeecc0d0 ref#=1] == Db@0x85778
s2 db.each({sql:'select * from t', callback:proc(){print(this)}, mode:0});
{a: 1}
{a: 2}
{a: 3}
result: undefined@0x6f4c4[scope=#0@(nil) ref#=0] == undefined
s2 db.close()
result: undefined@0x6f4c4[scope=#0@(nil) ref#=0] == undefined
s2 db.close()
rc=105 (CWAL_RC_EXCEPTION)
EXCEPTION: exception@0x75370[scope=#1@0xbeecc0d0 ref#=0] == {
code: 118,
column: 8,
line: 1,
message: 'this' is not (or is no longer) a Db instance.,
script: shell input,
stackTrace: [{
column: 8,
line: 1,
script: shell input
}]
}
s2
Happy Fossiling!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] libfossil: new script binding
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/wiki?GreenspunsTenthRuleOfProgramming
On Thu, Jul 17, 2014 at 11:38 AM, Stephan Beal sgb...@googlemail.com
wrote:
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's
a demo script here:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/finfo?name=s2/unit2/000-100-db.s2
Unless i get called off of vacation back to work next week, i should
have the remaining bits ported from the older binding by this time next
week. The older binding and this one use the same underlying scripting
engine (just different languages on top of it), so porting has been a
straightforward matter so far. The new scripting language is documented in
inordinate detail (60 pages) here:
https://docs.google.com/document/d/1hvMoHSIz94dob6fCU6SLxle_s7YL6CrA_4aU12OWwWY/view
This one (called, rather uncreatively, s2) is much cleaner than the
first one (th1ish), with a more robust core, proper operator precedence
(with over 30 overloadable operators), and its got (if i may say so)
bordering-on-outstanding memory usage:
https://docs.google.com/document/d/1hvMoHSIz94dob6fCU6SLxle_s7YL6CrA_4aU12OWwWY/view#heading=h.ucmv4mn8r0rw
Ad it's got an interactive shell mode:
[odroid@host:~/fossil/libfossil/s2]$ ./s2sh -v
s2 interactive shell. All commands run in the current scope. Use your
platform's EOF sequence on an empty line to exit. (Ctrl-D on Unix,
Ctrl-Z(?) on Windows.) Ctrl-C might work, too.
The 'g' object is at your service as a place to store things.
s2 var db = Fossil.Db.open(':memory:')
result: Db@0x85778[scope=#1@0xbeecc0d0 ref#=1] == Db@0x85778
s2 db.execMulti(create table t(a); insert into t(a) values(1),(2),(3););
result: Db@0x85778[scope=#1@0xbeecc0d0 ref#=1] == Db@0x85778
s2 db.each({sql:'select * from t', callback:proc(){print(this)}, mode:0});
{a: 1}
{a: 2}
{a: 3}
result: undefined@0x6f4c4[scope=#0@(nil) ref#=0] == undefined
s2 db.close()
result: undefined@0x6f4c4[scope=#0@(nil) ref#=0] == undefined
s2 db.close()
rc=105 (CWAL_RC_EXCEPTION)
EXCEPTION: exception@0x75370[scope=#1@0xbeecc0d0 ref#=0] == {
code: 118,
column: 8,
line: 1,
message: 'this' is not (or is no longer) a Db instance.,
script: shell input,
stackTrace: [{
column: 8,
line: 1,
script: shell input
}]
}
s2
Happy Fossiling!
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] libfossil: new script binding
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, for example, Lua. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] libfossil: new script binding
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 partly conflicts with th1ish being
expression-oriented, whereas TCL is command-oriented (a distinction i
didn't understand clearly at the time). e.g. the [funcCall syntax] is there
only because it was easy to implement early on, before i had decided
whether th1ish was ever going to grow to any useful size. s2 was built from
the ground up to avoid some of th1ish's cruft, and i had the benefit of
having a clear path set out in advance (unlike th1ish, which initially
wasn't intended to grow anywhere near to where it did). i initially kept
TCL-style {strings} in s2, but eventually dropped them in favor of the more
general heredoc. i think the only remaining bits of TCL/TH1 heritage are
the 'catch' keyword and 'proc' as an alias for 'function' (b/c proc is just
easier to type).
Fellow list-member Andy Goth has spent no small amount of time explaining
the subtleties of TCL to me in various off-list discussions about script
engines, but i'm just a TCL'ler at heart. i prefer expression-oriented
syntax with a clear definition of 'identifier' vs 'string', though i will
admit that command-oriented is arguably better/easier for writing unit test
script bindings (initially th1ish's only goal, which it outgrew at some
point).
@Matt: i do it only because it's fun, not because the world needs another
script engine :). It's also my escape mechanism when the real world
bombards me with other problems i should be solving ;).
Will be interesting to see how this project compares to other ;scripting
engines designed for embedding, like, for example, Lua.
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 combined.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] libfossil: new script binding
-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 combined. Sorry to drag this away from Fossil and TH1 and S2, but I suggest running Tcl in Valgrind sometime. It's very, very good about memory usage. Aside from interim development versions, the only leak I've found is a performance optimization in which it doesn't bother free()ing everything on exit, much the same way Fossil doesn't clean up because it knows the operating system will do it faster and better. There's a compile-time option set via preprocessor to make it go back to the old behavior of tidying up all allocations at the end. This is very important to me because I frequently use Tcl for testing other code written in C and Fortran and such, and I need Valgrind to spot my errors without being mired in the test harness. http://wiki.tcl.tk/3840 - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyDQYAAoJELtYwrrr47Y4iBkH/j3cBBloLwFAxigrX8xhTydy I1c++agxS/veY0kdWoXqbnRYTluHXGlLy4JetWEOk3PmkgNa3EBZRsVtuUSRiqdl gpD1R0kP+7izLDlZuPKXWBjQNtdeAslSTcyuIFQVWTfHa1gFKT12GQ5oKuwo98yi Zl2uxhq6vgZK4cX3zg/S2SH2QA4avdMFJRxmBUXeBil6wqpr/oYKznD4kxtmTsEy zSysbC6Jz0l6dIbh+whAgNxhhf6QroItCwqCHtfeWBHkx05KCzUddXKizX72ggrz 0aIu1loCz+Kb5v7JHnG8n8lzySTtKIBb0idUW5t1WCTmgJHyPrdLDvgmYrzOgBY= =XwRk -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] libfossil: new script binding
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 individually leak more memory than lua and s2 allocate combined. Sorry to drag this away from Fossil and TH1 and S2, but I suggest running Tcl in Valgrind sometime. It's very, very good about memory usage. +1 I'd be _very_ interested if some contrary conclusion was reached (as would the Tcl core team). Aside from interim development versions, the only leak I've found is a performance optimization in which it doesn't bother free()ing everything on exit, much the same way Fossil doesn't clean up because it knows the operating system will do it faster and better. There's a compile-time option set via preprocessor to make it go back to the old behavior of tidying up all allocations at the end. This is very important to me because I frequently use Tcl for testing other code written in C and Fortran and such, and I need Valgrind to spot my errors without being mired in the test harness. http://wiki.tcl.tk/3840 - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyDQYAAoJELtYwrrr47Y4iBkH/j3cBBloLwFAxigrX8xhTydy I1c++agxS/veY0kdWoXqbnRYTluHXGlLy4JetWEOk3PmkgNa3EBZRsVtuUSRiqdl gpD1R0kP+7izLDlZuPKXWBjQNtdeAslSTcyuIFQVWTfHa1gFKT12GQ5oKuwo98yi Zl2uxhq6vgZK4cX3zg/S2SH2QA4avdMFJRxmBUXeBil6wqpr/oYKznD4kxtmTsEy zSysbC6Jz0l6dIbh+whAgNxhhf6QroItCwqCHtfeWBHkx05KCzUddXKizX72ggrz 0aIu1loCz+Kb5v7JHnG8n8lzySTtKIBb0idUW5t1WCTmgJHyPrdLDvgmYrzOgBY= =XwRk -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] libfossil: new script binding
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 valgrind. Most of them individually leak more memory than lua and s2 allocate combined. Sorry to drag this away from Fossil and TH1 and S2, but I suggest running Tcl in Valgrind sometime. It's very, very good about memory usage. The parts it doesn't leak ;). i have not run any large-script tests on any interps except s2, but here are some valgrind numbers for _empty_ scripts on various interps on this ODroid box (copy/pasted from gdocs... format might get mangled): - lua allocates 299 times for 22093 bytes for an empty script. Fewer allocs than s2, but slightly more memory. i seem to remember (possibly incorrectly) that lua uses a memory region allocator, which would explain both lower allocation counts and larger memory usage. - JimTCL allocates 1665 times for 83444 bytes on an empty script. - tclsh: 143 allocs for 306KB, but it leaks 14 allocs and 216KB! It leaks more than s2, lua, and JimTCL allocate combined ;). Python 3.3.2: 23486 allocations (646 of which are leaked) totaling 3.8MB of RAM (344KB of which is leaked) for an empty script. The devs most definitely need to run it through valgrind - it reports over 580 different leaks and invalid memory accesses. (Granted, sometimes valgrind falsy identifies non-errors as errors, but i'm quite certain those are not all false positives.) Yup. Mangled. And note that empty-script costs (just measuring startup overhead) also tells a very incomplete picture, as startup memory costs don't necessarily have anything useful to imply about runtime costs. Aside from interim development versions, the only leak I've found is a performance optimization in which it doesn't bother free()ing everything on exit, much the same way Fossil doesn't clean up because it knows the operating system will do it faster and better. There's a That is most likely what is leaking, and pedantically speaking that's not a leak, but i like to see libraries clean up. They shouldn't be using global state, IMO. This is very important to me because I frequently use Tcl for testing other code written in C and Fortran and such, and I need Valgrind to spot my errors without being mired in the test harness. http://wiki.tcl.tk/3840 Aha. Thanks for that. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Ticket attachments sometimes redirect to home
-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 to the home URL. However, when viewing the same repository via the above link, the attachments display correctly. It's not my browser, since I have tabs accessing both the local and core.tcl.tk repositories, and I logged out of both to keep things the same as possible. Yet there is still a difference in behavior. The same issue appears when accessing the attachments via the timeline (must have All Types selected). I tried downgrading my Fossil version from a0c8a0869d to 6728a8bd08 to match core.tcl.tk, but the problem persisted. I simply cannot see attachments in my clone of the repository. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyDXFAAoJELtYwrrr47Y4108IALlPHiqEPN7T2QfL8rNG56nR h5DrDsLDBYhpPVupDbHcofYnxYQdJ5ot0aIgfR+nRhlArg64Zl1KP+e62YPfIGex omMjuxeOpCxQT2g6aSTDnNl0dhmf9fPxLbaIKSjLpVCuUe7AES8eAYbhb/WQ++uB t0fNA3c5WSh/5a4D7AaNXWRMye3ngp25ZelZD9o7gpCV44PhWu/iukGIuZ9jF9CS 7rqQBjvKV30trBYsrBeOyeKWl4ow6F7R3NdLqse/4jTdCcflHwyEd60Hc57XF3a4 zTTvbBPTYW5i1/vV0BrYNvRGZ4sbU6yHLPXMcENGTn1gekZwOaqWb1H+CIaARLQ= =FxTb -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] libfossil: new script binding
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 might have side effects which the app cannot see (some class loaders inject their classes into the app during the static init phase, before dlopen() returns). Not closing them is the only safe course of action, really, but also incidentally pleases valgrind on my systems. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket attachments sometimes redirect to home
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 display correctly. i cannot reproduce that using e.g. http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/info/64cada818c and a local clone of it. i get sent to the artifact details page for the attachment. I tried downgrading my Fossil version from a0c8a0869d to 6728a8bd08 to match core.tcl.tk, but the problem persisted. I simply cannot see attachments in my clone of the repository. i have no hypothesis. :( -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket attachments sometimes redirect to home
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 change the attachment itself from private to public. As a result, the attachment artifact is will not be synced to other clones, that's where the redirect comes from. Someone will have to make the attachment artifact public again, so it can be synced.. I have seen this happen once before. Regards, Jan Nijtmans ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] CHANGED versus EDITED
-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? What other inconsistencies are possible between these two commands? I would have thought they'd share the same reporting code. I see [fossil changes] also says EDITED. Looks like [fossil diff -brief] is the odd man out. Furthermore, I see [fossil changes] and [fossil status] respect the relative paths setting, as discussed in a previous email Inconsistent paths replied to by Jan Nijtmans. However, [fossil diff] and [fossil diff -brief] do not honor relative paths. Once again, [fossil diff] is the odd man out, and I remain surprised it doesn't share the reporting code with the other two commands I mention. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyEAXAAoJELtYwrrr47Y4UfIIAJqSOs8sNiIzudRITcHH8Td/ kLWBtUePwwCl87pI6kxV9gt6lL68gqvH53JiBlxvCd62HpEPnumxeEPTEwTXjjZF dLB7KjrgNFVq4k4JtsUcz1H2EV1Zs2Q4l1/f9U21HB5kcE6DgfBmAe3mlC/ZmyOl 3JnAwf6Dh9ljIHN/LszGWTTk90YgKCJgj2A0gPASYxtxKjuBXcleULvNqgfBLIoU II9yVTRxDavyQX7VV+Ii/Ebh8o/oR9F7WkURK7Cg/FEB1HG2noduFa5PGNKGBE/e DJJ1WcfGhOcXx5Zm1iqYg+HwbMQvEvxBzAY1dO4isqR3C8Fngr9QozQUywIau4E= =RP5D -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket attachments sometimes redirect to home
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: 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 by myself. So, this happened in sept '13 in the Tcl repository, now the same happened in the Tk repository. Time to have a look. Regards, Jan Nijtmans 2013-09-05 22:17 GMT+02:00 Richard Hipp d...@sqlite.org: On Thu, Sep 5, 2013 at 4:08 PM, Richard Hipp d...@sqlite.org wrote: All of the above are marked PRIVATE in the Tcl repository on core.tcl.tk. I do not know why they are marked that way One theory is that the moderator logic approved the attachment artifact but failed to approve the attachment itself. Items that are pending moderation are marked as private until they are approved. Probably we should get 1.27 out the door before we try to fix this. -- D. Richard Hipp d...@sqlite.org ___ fossil-dev mailing list fossil-...@lists.fossil-scm.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Ticket attachments sometimes redirect to home
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 by myself. I wonder if this is at all related to the other sync problems that have been brought up in the past. If you didn't read my email, I specifically mentioned private files that get converted to public as a potential culprit although I was not aware of any content that could be transitioned from private to public until you mentioned attachments: http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg16467.html I also asked the question about private content becoming public (at the time I didn't know it was even possible) and it seems for now at least there is one type of private content that can become public (attachments)---(if I understand your comments correctly). I wonder if these missing attachment artifacts are part of a cluster? If they are not, are they part of a manifest that gets parsed and inserts known UUIDs of the private attachments into the phantom table; and is this manifest UUID in the cluster artifacts anywhere? If so, then it probably won't matter if they are not in clusters, but it would be interesting to know. Guess I'll have to add looking at how private attachments and clusters work to my TODO. Thanks for sharing---likely unrelated, but worth bringing up I think. Andy -- TAI64 timestamp: 400053c85186 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Partial commit of merge
-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] should require only the files modified *by [fossil merge]* be part of the commit. In other words, it should only be necessary to commit what [fossil changes] labels UPDATED_BY_MERGE. If I have files in my checkout that were changed for other reasons, I shouldn't be forced to stash, commit, or revert them just because I'm doing a merge. - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTyIhCAAoJELtYwrrr47Y4AWwH/jxmlXGIEgvyt9K7fQDSdJEC Z4qBRZbinWx746TAPRNnFl0EkOCO8gAYwTuBSOF9NJ4iUsTy3p4yV3UU0F92l72J 6h7HoxR0wyT+tOaA4bEjJB/M5wvrVE8HloWSM/jFCxVdz7vUUCZTM8gckX/P2w+R oEKOl1//qVSxpru90fHlkzeFn3m7af5Y9oGrrzHXfIOFgjLbP/8I75w25Acljde5 RcK4AdVHaHZESwsuvP9ELpF/j00jZzKFaoOw1vSGfy0LwbawKoatIkQAcL2AxqOz luqTDPD7421QKySPafPbHOg8Fys1TWhE9zjACZLBttf/dYxlt/7VQWEoclgLpbY= =PEvh -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
