Re: [fossil-users] Random thoughts on Fossil v2
On 28/07/2013, at 8:53 AM, Paolo Bolzoni paolo.bolzoni.br...@gmail.com wrote: Marketing I am afraid ... ... Of course whoever is interested in selling other languages will mark the C++ way as older. I respectfully disagree, strongly. Some OO languages support greater degrees of introspection and dynamic type checking than others. Some encourage delegation, dynamic binding and dispatch, whether classes are part of the object system, whether the class of classes can be subclassed, etc., these differences are really fundamental things. One thing I appreciate about Tcl is that I can choose which type of OO suits my needs, or none at all (sometimes an OO system gets in the way of a clean solution). But, in summary, the main difference in OO systems is the degree to which they support dynamic stuff and whether they support delegation. ___ 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] homepage (first wiki page) for a repository
On Wed, Jul 31, 2013 at 4:54 PM, Jiri Navratil j...@navratil.cz wrote: Are you fine with my approach? Could you help me to get them to trunk from unplanned fork? Hi! Was the intention really to show the whole URI path to the page? On my system the first entry in the /wiki page looks like: /doc/trunk/www/index.wikihttp://localhost:8080/%2Fdoc%2Ftrunk%2Fwww%2Findex.wiki wiki home page. That looks strange (or unintended) to me. That link works but the URL is encoded differently that the other links on that page: a href=/%2Fdoc%2Ftrunk%2Fwww%2Findex.wikihttp://localhost:8080/%2Fdoc%2Ftrunk%2Fwww%2Findex.wiki /doc/trunk/www/index.wiki/a wiki home page. i think that's caused by using %t here: li %z(href(%R/%t,zWikiHomePageName)) i think that should probably be %s in that case. -- - 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] Any objections to renaming /stats_report...
On Tue, Jul 23, 2013 at 10:09 PM, B Harder brad.har...@gmail.com wrote: I personally have no objections, but as a matter of business and visibility, perhaps do final last call for objections/alternatives! on a business day. My apologies - i forgot about this. Here's the last reminder - this weekend it'll be renamed. -- - 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] Problem with fossil mv
fossil version This is fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC fossil ls -l EDITED first/testfile.txt dir /b/f/s testfile.txt D:\var\fossil\junk\first\testfile.txt D:\var\fossil\junk\second\testfile.txt fossil mv first/testfile.txt second/testfile.txt RENAME first/testfile.txt second/testfile.txt fossil diff second/testfile.txt C:\usr\bin\fossil.exe: file second/testfile.txt does not exist in checkin: During development I decided to move some files to a different dir under the repo tree. No problem, moved the files in the filesystem, used fossil mv to rename them in the repo. But then I wanted to diff the files against the repo before committing the changes. Doing the diff was, apparently, a problem for Fossil. The transcript above was on Windows. Linux behaves the same. Because, in the test scenario, both files still existed on the filesystem, I then tried: fossil diff first/testfile.txt --- first/testfile.txt +++ first/testfile.txt @@ -1,6 +1,6 @@ ... Wait. What? Now I'm really confused. This disconnect seems wrong to me. I'm expecting Fossil to immediately follow the changes in second/testfile.txt, and lose any knowledge of first/testfile.txt. On commit, it gets second/testfile.txt, so at least that part is behaving like I expect. But as-is, my only choice seems to be back-out the move/rename, or commit. And I'm not willing to commit my real project without reviewing the diff. I seem to remember an older version behaving the way I expected. What am I missing? Is this a Fossil problem? Or a user expectation problem? Thanks in advance. -Clark ___ 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] Problem with fossil mv
Thus said Clark Christensen on Wed, 31 Jul 2013 10:01:58 -0700: dir /b/f/s testfile.txt D:\var\fossil\junk\first\testfile.txt D:\var\fossil\junk\second\testfile.txt fossil mv first/testfile.txt second/testfile.txt RENAME first/testfile.txt second/testfile.txt Did you forget to mv the actual file here? It seems to work when the actual file is moved: $ echo change f/t $ f ls -l EDITED f/t $ f mv f/t s/t RENAME f/t s/t $ mv f/t s/t $ f diff Index: s/t == --- s/t +++ s/t @@ -1,1 +1,1 @@ -rename +change The following error, on the other hand, does still occur: fossil diff second/testfile.txt C:\usr\bin\fossil.exe: file second/testfile.txt does not exist in checkin: $ f diff s/t file s/t does not exist in checkin: But then I wanted to diff the files against the repo before committing the changes. Try the diff without explicitly naming the files. I'm not saying this isn't a bug, just pointing out that Fossil can actually show the diff (at least in my test scenario above). Andy -- TAI64 timestamp: 400051f94b3d ___ 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 12:06 PM, Stephan Beal sgb...@googlemail.comwrote: - libfossil - nothing wrong with that, IMO. That seems to be the most popular (and arguably the most natural) choice so far, so that's the tentative name until/unless someone proposes something mind-blowing. Thanks for your input! -- - 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] API docs for libfossil prototype are online
Hi, all, FYI: i've posted the API docs for the libfossil prototype code here: http://fossil.wanderinghorse.net/repos/f2/doxygen/ Feedback is always welcomed. i'll try to get those regenerated when there are significant code changes. To build them locally: # cd doc # make doc (requires 'doxygen') Happy Hacking! -- - 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...
I'm going to recycle a project name I've used before: urvogel (the first bird), and suggest for its logo: http://www.ucmp.berkeley.edu/diapsids/birds/archie2.jpg On Jul 30, 2013 3:06 AM, 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 :-? [1] = http://fossil.wanderinghorse.net/repos/f2/ -- - 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...
In that case, why not go with libbingfossil :) On Tue, Jul 30, 2013 at 6:10 AM, f...@southshield.net wrote: On 2013-07-30 06:06, Stephan Beal wrote: The obvious choices include: - libfossil - nothing wrong with that, IMO. That seems to be the obvious choice. But if you want to get creative I would vote for a living fossil. My fossils are very much alive, thanks to you guys :) I'm partial to plants so I propose: - libginkgo - After 170 million years the living Ginkgo biloba looks pretty much identical to its fossil ancestor. And it has medicinal properties to boot, amongst other things to improve memory and concentration ... __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-usershttp://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 Wed, Jul 31, 2013 at 10:32 PM, B Harder brad.har...@gmail.com wrote: I'm going to recycle a project name I've used before: urvogel (the first bird), and suggest for its logo: http://www.ucmp.berkeley.edu/diapsids/birds/archie2.jpg Hmmm. That one just doesn't grab me. The more i think about Jeremy's idea the more i like that one - libingfossil: a) living fossil (as FVD originally suggested) b) we're lib'ing fossil c) ibing... ibing... i was hoping to find an extinct creature with that name, but it's apparently a seldom German surname[1]. [1] = http://www.verwandt.de/karten/absolut/ibing.html OMG, there are other Beals in Germany http://www.verwandt.de/karten/absolut/beal.html -- - 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?
On Wed, Jul 31, 2013 at 1:05 AM, B Harder brad.har...@gmail.com wrote: 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. Well, sure. Portability is important; it's pretty much a necessary prerequisite for the sort of thing I'm talking about. And a distribution having the *right* to redistribute fossil (or whatever software) is necessary also, else it simply can't take the risk of redistributing it. (And right to modify is necessary if only so the distribution can repair bugs, etc without having to go back to the upstream author for every little change.) What I'm talking about is more the sort of things that make it more difficult or less difficult for a distribution to package an application which it can then provide to the distribution's users and support for its users. Some of these things might be trivial for the Fossil Project to do, but make a big impact for distributions. Other things might require more effort, or even be a significant change in workflow or practice for the Project; the Project might decide that a given change is sufficiently beneficial that it's worth the cost to the Project of making the change, while other things might be insufficiently helpful (or too difficult for the Project to change) such that the Project decides to not change that thing and require distributions using what the Project provides (in terms of released software, etc) to just suck it up and deal. This is all ultimately something the Fossil Project and its constituent developers have to decide upon; no one outside the Project can force the Project to make any given change in what the Project does or what it provides. The most any distribution outside the Project can do is simply decline to package the Project's software for that distribution. *shrug* 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. Kinda semi... I think I'd phrase it more as (1) *if* there are any particular distributions the developers collectively and/or individually care about, and if so (2) *which* distributions these are. I can do a Generally Accepted Best Practices For Upstream Authors Of Software Being Packaged In Major Unix / Linux Distributions, which would likely focus on the distributions I mentioned and perhaps a few more (maybe some source-intensive distributions like Gentoo, for instance). But I was hoping to find out if there were any distributions that people did (or did not) specifically care about, and which they were, so that I could be sure to make a point of addressing those distributions in specific along with things which apply to distributions in general and/or to most or many (if not all) distributions. I'll fully agree with your answer -- it usually *is* where the interests of the developers lie. I'm trying to find out what (if any) interests there are, along these lines. (It may well turn out that there isn't any interest. I think that'd be regrettable, but if that's what it is, so be it.) 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. That's precisely the sort of information I'm trying to elicit! Now I know that there is (presumably) at least a little interest amongst the active developers (or at least the active users -- I haven't investigated to see if you are a developer) of Fossil for NetBSD, so that's a distribution which probably should be covered. With respect to Stephen Beal's followup to your response... It's useful (albeit in a negative way) information to know that to the best of his recollection developers in general have not expended efforts on behalf of any specific distribution. I'd be curious to know what sorts of distribution-specific packages have been distributed in the past, what distributions they were for, if they're still available (or even perhaps still maintained by the developers in question), etc. Is there a list or wiki page for this somewhere? If not, I guess I can search the back mailing list archives for any information available there if I have to. I appreciate the time you and Stephan took to respond to my original message. Thank you both. I also look forward to receiving any other responses anyone might care to make. Be well. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
Re: [fossil-users] Q: What Unix / Linux _DISTRIBUTIONS_ Does The Fossil Project Care About?
On Wed, Jul 31, 2013 at 1:05 AM, B Harder brad.har...@gmail.com wrote: 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. As I recall, several distros already include SQLite, and Fossil is pretty much run the same way SQLite is - aside from SQLite being a library while Fossil, currently, is a self contained application. Anyway, I suspect Fossil is already reasonably friendly for most distros to package for inclusion in their repositories. ___ 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
Thus said Jan Nijtmans on Tue, 30 Jul 2013 10:11:52 +0100: 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! It might be a little late in the game, but why is it called integrate? Maybe I missed the discussion about why it is called that---I'll scour the archives. Something like --closeleaf would seem to be more representative of what it does. I tested it out and it worked. I even was able to close trunk with it by doing: fossil update branch fossil merge --integrate trunk Getting a new trunk was also kind of interesting. I'm not suggesting that this be prevented, by the way, because it's already possible to close the ``trunk'' leaf. Andy -- TAI64 timestamp: 400051f9ca02 ___ 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
Thus said Andy Bradford on 31 Jul 2013 20:37:19 -0600: It might be a little late in the game, but why is it called integrate? Maybe I missed the discussion about why it is called that---I'll scour the archives. After reading the archives it does appear that --integrate, while not quite as descriptive of the closing aspect, is quite representative of the whole operation that is going on. By the way, I like the option. Making it possible to close the leaf with the merge/commit is quite nice. I even tried to trick it by doing: fossil merge --integrate non-leaf-branch-artifact-id And it ignored the fact that it wasn't a leaf and just did a normal merge. Nice! Thanks, Andy -- TAI64 timestamp: 400051f9f264 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
