Re: [fossil-users] Enhancement: commit and close merged leaf
2013/7/12 Stephan Beal sgb...@googlemail.com: 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_BY_INTEGR (comparable to their XXX_BY_MERGE equivalent) in fossil (status|changes|ls -v) See: http://www.fossil-scm.org/index.html/info/2015bbd55d Still no objections, anyone? I think it's ready to be integrated into trunk (using merge --integrate, of course), but another round of evaluation never hurts! Thanks, 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] Enhancement: commit and close merged leaf
On Tue, Jul 30, 2013 at 10:11:52AM +0100, Jan Nijtmans wrote: 2013/7/12 Stephan Beal sgb...@googlemail.com: 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_BY_INTEGR (comparable to their XXX_BY_MERGE equivalent) in fossil (status|changes|ls -v) See: http://www.fossil-scm.org/index.html/info/2015bbd55d Still no objections, anyone? I think it's ready to be integrated into trunk (using merge --integrate, of course), but another round of evaluation never hurts! Hello all, I'll try to add some feedback. :) Why INTEGR, and not INTEGRATE? There is also case -1, -2, -4. Why not -3? 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? Regards, Lluís. ___ 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] Enhancement: commit and close merged leaf
On Tue, Jul 30, 2013 at 11:11 AM, Jan Nijtmans jan.nijtm...@gmail.comwrote: 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 ..._BY_INTEGR8? Still no objections, anyone? I think it's ready to be integrated into trunk (using merge --integrate, of course), but another round of evaluation never hurts! i like it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Enhancement: commit and close merged leaf
2013/7/30 Lluís Batlle i Rossell vi...@viric.name: Why INTEGR, and not INTEGRATE? 2013/7/30 Stephan Beal sgb...@googlemail.com: 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 not aligned anyway, so I guess INTEGRATE would be just as well. (An earlier version used ADD_BY_INTEGR/CHG_BY_INTEGR, in an attempt to keep the colums in the output well-aligned) There is also case -1, -2, -4. Why not -3? There's no need to keep values continuous, just keeping some room for future improvements. -3 is just as good. Thanks! 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] Enhancement: commit and close merged leaf
2013/7/30 Lluís Batlle i Rossell vi...@viric.name: 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 which branches should be closed. Existing merges never produce id=-4 so the query will give the empty result then. 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] Enhancement: commit and close merged leaf
On Tue, Jul 30, 2013 at 10:45:31AM +0100, Jan Nijtmans wrote: 2013/7/30 Lluís Batlle i Rossell vi...@viric.name: 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 which branches should be closed. Existing merges never produce id=-4 so the query will give the empty result then. But maybe it should not run unless in 'integrate' mode? ___ 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] Enhancement: commit and close merged leaf
2013/7/30 Lluís Batlle i Rossell vi...@viric.name: 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, the vmerge table is where this information can be found. 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] Inofficial naming contest...
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). That means it's not really v2, but instead provides an alternate interface for v1 repos[1]. That just shows how good is the design :) - libfossil - nothing wrong with that, IMO I'm for this one - just keep things simple. Kind regards, Remigiusz Modrzejewski ___ 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] Inofficial naming contest...
2013/7/30 Remigiusz Modrzejewski l...@maxnet.org.pl 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). That means it's not really v2, but instead provides an alternate interface for v1 repos[1]. That just shows how good is the design :) - libfossil - nothing wrong with that, IMO I'm for this one - just keep things simple. +1 But if you really want a joke call it librush (like stiff brushes use during the fossils cleaning). ___ 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] Inofficial naming contest...
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 gautier.difo...@gmail.com wrote: 2013/7/30 Remigiusz Modrzejewski l...@maxnet.org.pl 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). That means it's not really v2, but instead provides an alternate interface for v1 repos[1]. That just shows how good is the design :) - libfossil - nothing wrong with that, IMO I'm for this one - just keep things simple. +1 But if you really want a joke call it librush (like stiff brushes use during the fossils cleaning). ___ 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] Inofficial naming contest...
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 is a good occasion to remove the ambiguity with that filesystem. Sacrilege ;). The underlying model, and much of the (being ported/refactored) code came from Richard, and i wouldn't dare to try to rename that part. But i wouldn't be able to resist a good pun-name based off of fossil (feather is stretching the imagination a bit, but it is funny). Does anyone actually use that filesystem still? i thought it was an old Plan9 thing? http://en.wikipedia.org/wiki/Fossil_(file_system) Oh, it's only 10 years old. i thought it went back much further. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Inofficial naming contest...
Stephan Beal wrote: [...] - libname of some specific dinosaur species 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 been carefully for reliability. --- anonymous │ computer hardware manual signature.asc Description: OpenPGP digital 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] Inofficial naming contest...
On Tue, Jul 30, 2013 at 3:33 PM, David Given d...@cowlark.com wrote: Stephan Beal wrote: - libname of some specific dinosaur species 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 reference. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Inofficial naming contest...
On Tue, Jul 30, 2013 at 9:36 AM, Stephan Beal sgb...@googlemail.com 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Inofficial naming contest...
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 sgb...@googlemail.com wrote: On Tue, Jul 30, 2013 at 3:33 PM, David Given d...@cowlark.com wrote: Stephan Beal wrote: - libname of some specific dinosaur species 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 reference. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Inofficial naming contest...
On Tue, Jul 30, 2013 at 1:06 PM, Stephan Beal sgb...@googlemail.com 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). That means it's not really v2, but instead provides an alternate interface for v1 repos[1]. So... in light of that insight i am looking for a new name for the prototype code and am hoping you guys have some nice ideas. Things to keep in mind while coming up with a name: a) this is in no way official. The prototype is just that, and an experiment. It's coming along nicely so far, and it can open repos, but not do much of anything useful (e.g. no writing to the db yet and no timeline - timeline's coming up shortly, though). b) i'm looking to name the library, not the application. In the grand Unix tradition, however, applications often inherit part of their name from the underlying framework or library, so the chosen name might end up sticking around a while. c) The name will likely determine the name of the main header and library files. So that's the prize for the best idea (by vote, but DRH and i get extra votes ;) - the winner will have chosen the names clients will see when they do: #include libfossil-or-whatever.h or: gcc ... -lfossil-or-whatever The obvious choices include: - libfossil - nothing wrong with that, IMO. - libfsl - flib - is already used by several projects - libdino - libname of some specific dinosaur species Dino names? Gasosaurus Micropachycephalosaurus Piatnitzkysaurus Or maybe codasaurus (pronounced code-asurus)? I vote to stick with fossil. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] Inofficial naming contest...
On Tue, Jul 30, 2013 at 3:47 PM, Steve Landers st...@digitalsmarties.comwrote: 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] scriptable timeline demo
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 timeline events for /home/stephan/cvs/fossil/f2.fsl: uuid timestampString user eventType tags comment 83f00c7e07eb 2013-07-30 13:51:14 stephan ci trunk test code cleanups. 3f69c014c972 2013-07-30 13:38:42 stephan ci trunk merged in [attach-dbs] branch. 2634b9a151aa 2013-07-30 13:33:04 stephan ci attach-dbs Minor touchups and test code. The script can be seen here: http://fossil.wanderinghorse.net/repos/f2/index.cgi/finfo?name=th1ish/timeline.th1ish -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Q: What Unix / Linux _DISTRIBUTIONS_ Does The Fossil Project Care About?
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 systems are going to get special consideration? Likely, the answer will be (as is the case with most open source software): Where the interests of the developers lie. For example, I'm interested in BSD (NetBSD specifically), and so I pay attention to how fossil behaves on it. In terms of fixes then, when I supply patches or bug reports, they are considered, and then appropriate actions are taken (patches applied or rejected, changes made, or not). I suspect most any other OS you're thinking of would receive the same consideration. -bch On Jul 30, 2013 8:04 PM, Joseph R. Justice jayare...@gmail.com wrote: [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 your response to both lists unless you deem it necessary to do so for some reason. You can CC me or not in any response you send to a list. If I've violated list custom by doing this, please flame me off-list.] [Meta: If you want to skip ahead to what I am proposing / offering to do, go to PROPOSED ACTION ITEM below.] Recently on the fossil-users mailing list, Stephan Beal sgb...@googlemail.com started an extensive discussion thread titled Random thoughts on Fossil v2, which discussed among other things creating a library for core Fossil functionality (I'll refer to it as libfossil2) and one or more user-facing applications which would use this library to provide actual functionality (I'll refer to them collectively as fossil2client). In a response to his original post, I submitted some comments which, among other things, suggested things I thought should be done for such a hypothetical Fossil v2 so as to make it easier for a Unix / Linux Distribution to package and distribute the library and applications according to the standards and processes they normally use. Some of the things I suggested along this line included: * Fossil2client not requiring or expecting libfossil2 to be compiled / linked into it statically, and that dynamic run-time linking be the expected norm; * The source for fossil2client not having an embedded copy of the source for libfossil2 incorporated within it; * (Unspoken here, but implicit, is that other libraries or sources for libraries, most specifically that for sqlite3, should not be compiled into the fossil2client statically or have a copy of its source incorporated into the source for fossil2client either); * Libfossil2 being implemented in such a way that multiple versions of it can be installed simultaneously on a given system, so that different clients can use different versions of libfossil2 if necessary and all successfully coexist on the system. * Otherwise doing things where possible to make it easier, or at least less difficult / inconvenient, for a Unix / Linux distribution to package and distribute libfossil2 and fossil2client. * In a later response, that amalgamation builds not be done or expected to be done. * Also somewhere along here that many of these things might well also apply to the existing fossil (v1) monolithic application, at least insofar as they represented things that Unix / Linux distributions would need to alter and/or undo so as to make that version of fossil conform to whatever their internal standards for the applications they distributed and supported happened to be. In Stephan's response to this, he commented in such a way that it seemed he at least believed that many Unix / Linux distributions wouldn't really care about these things, but would just follow the path of least resistance in terms of generating library and client binaries which they could then distribute to their end-users. I want to emphasize that he did not come across as saying my suggestions were somehow wrong, but that he simply didn't see why anybody would bother doing things other than the easiest or default way as provided by the software as released by the Fossil Project. I believe he is mistaken about this, and that Unix / Linux distributions in general behave in a fashion significantly different than would an individual end-user running on Unix / Linux who was compiling fossil for their own personal or otherwise internal use. I claim they do this because they are acting, albeit generally on a far smaller scale, as an operating system integrator, akin to what Microsoft does for Microsoft Windows or Apple does for MacOS/X, but also on a far larger scale in that they package and directly provide under
