Re: [fossil-users] Problem with compilation under MINGW
Joe Mistachkin escribió: A clean build from Fossil trunk compiles fine here. Can you please run make clean and try again? That did the trick. I'll make sure to include this in my troubleshooting before reporting a problem again -- sorry for the noise. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] keep viewing snapshot of files corresponding to a tag
Hello, sometimes I want to casually browse, through the web-UI, sourcefiles in a repo crresponding to a certain release-tag. What I do now: click on 'Tags', pick the tag I'm interested in, click on the checkin-ID (1 entry) corresponding to the tag, then click 'files' in the displayed checkin-summary. I can then browse what I call snapshot, and I see the checkin-ID being used as CGI-parameter 'ci=...' when clicking through directories. Can I shortcut this and simply use something like '/dirtag=THE_TAG' ? (Or on a more general level: is the CGI-interface documented somewhere? (I understand it might make sense not documenting everything, since some commands/args are not meant for interactive use and may be subject to change between revisions, but let's ask anyway.) Thanks, Michai ___ 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] keep viewing snapshot of files corresponding to a tag
On Sat, Jan 4, 2014 at 9:55 AM, Michai Ramakers m.ramak...@gmail.comwrote: Hello, sometimes I want to casually browse, through the web-UI, sourcefiles in a repo crresponding to a certain release-tag. What I do now: click on 'Tags', pick the tag I'm interested in, click on the checkin-ID (1 entry) corresponding to the tag, then click 'files' in the displayed checkin-summary. I can then browse what I call snapshot, and I see the checkin-ID being used as CGI-parameter 'ci=...' when clicking through directories. Can I shortcut this and simply use something like '/dirtag=THE_TAG' ? (Or on a more general level: is the CGI-interface documented somewhere? (I understand it might make sense not documenting everything, since some commands/args are not meant for interactive use and may be subject to change between revisions, but let's ask anyway.) Query parameters are not as well documented as they ought to be. But there is some sparse documentation of some parameters. See http://www.fossil-scm.org/fossil/help for what little documentation there is. Yes, the ci= parameter to /dir and /tree can be a tag. Example: http://www.fossil-scm.org/fossil/dir?ci=trunk Thanks, Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] CSS classes in tree-view?
Hi all, I really like the new tree-view feature. I set out to apply the same CSS tricks to differentiate files and directories, but it turns out that unlike the 'flat view', no CSS classes are included. Would it be possible to add those to each a link? -- Martijn Coppoolse ___ 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] CSS classes in tree-view?
I think Joel Bruick is already working on this in a branch. I just haven't gotten around to vetting and merging his changes, yet. On Sat, Jan 4, 2014 at 10:06 AM, Martijn Coppoolse li...@martijn.coppoolse.com wrote: Hi all, I really like the new tree-view feature. I set out to apply the same CSS tricks to differentiate files and directories, but it turns out that unlike the 'flat view', no CSS classes are included. Would it be possible to add those to each a link? -- Martijn Coppoolse ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ 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 compilation under MINGW
On Fri, Jan 3, 2014 at 9:28 PM, Richard Hipp d...@sqlite.org wrote: OK, so I propose the following fix: [...] (2) Remove the --disable-internal-sqlite option on trunk. Require the use of the built-in SQLite only, since SQLite needs to be built with non-standard compile-time options to fully meet the needs of Fossil. [...] (4) When distributions complain, we simply explain that we tried using an external SQLite but it introduced too many complications and bugs and that we now require statically linking SQLite for reasons of security and reliability. Just to make sure I understand... You intend to eliminate the capability of --disable-internal-sqlite for Fossil not only for tip-of-trunk of Fossil, and not only for development snapshots (although you don't really have that, do you?), but *also* for future *release* versions of Fossil as well. Correct? In other words, on http://www.fossil-scm.org/download.html , if and when there is a Version 1.28 (and also for later versions beyond that one), the distributed source code for that version (or later) of Fossil will no longer support --disable-internal-sqlite, and any distribution wishing to package that version of Fossil such that it will use their system-provided shared library version of SQLite (which presumably will or at least may be different from the version provided with Fossil as an embedded code copy) will be entirely on their own to implement that capability. And further, presumably, the fossil-scm.org devs will not accept patches from external contributors (such as distribution packagers of Fossil) to be applied to the source code for the released version of Fossil to re-add this capability. Thanks for your time. Joseph ___ 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 compilation under MINGW
On Sat, Jan 4, 2014 at 10:59 AM, Joseph R. Justice jayare...@gmail.comwrote: On Fri, Jan 3, 2014 at 9:28 PM, Richard Hipp d...@sqlite.org wrote: OK, so I propose the following fix: [...] (2) Remove the --disable-internal-sqlite option on trunk. Require the use of the built-in SQLite only, since SQLite needs to be built with non-standard compile-time options to fully meet the needs of Fossil. [...] (4) When distributions complain, we simply explain that we tried using an external SQLite but it introduced too many complications and bugs and that we now require statically linking SQLite for reasons of security and reliability. Just to make sure I understand... You intend to eliminate the capability of --disable-internal-sqlite for Fossil not only for tip-of-trunk of Fossil, and not only for development snapshots (although you don't really have that, do you?), but *also* for future *release* versions of Fossil as well. Correct? In other words, on http://www.fossil-scm.org/download.html , if and when there is a Version 1.28 (and also for later versions beyond that one), the distributed source code for that version (or later) of Fossil will no longer support --disable-internal-sqlite, and any distribution wishing to package that version of Fossil such that it will use their system-provided shared library version of SQLite (which presumably will or at least may be different from the version provided with Fossil as an embedded code copy) will be entirely on their own to implement that capability. And further, presumably, the fossil-scm.org devs will not accept patches from external contributors (such as distribution packagers of Fossil) to be applied to the source code for the released version of Fossil to re-add this capability. That is my proposal, yes. The rational is that --disable-internal-sqlite adds no new capabilities to the program, but it does add complexity and risk. -- D. Richard Hipp d...@sqlite.org ___ 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 compilation under MINGW
On Fri, Jan 03, 2014 at 10:17:47PM -0500, James Turner wrote: [snip] I'll check with others but I'm not sure reliability is really the concern. We imported SQLite into our base tree. Because of this we try, when possible, to limit duplicating libraries in ports to reduce having to patch multiple versions of the same libraries. A good example of this is Firefox and newer software that uses WebKit. These projects like to ship their own copies of libraries to make their building process easier. For us, it just increases our headaches when it comes to maintaining required patches. SQLite is clearly a different case. I believe the only major patch we have in our tree relates to adding arc4random(3) support. If fossil removes --disable-internal-sqlite I highly doubt I'll be asked to maintain this feature in our ports tree (again I'll check with others and get back with you). -- James Turner I didn't get a strong outcry from other OpenBSD porters. We understand embedding SQLite is the typical way it's used and therefor somewhat of a different case. We would prefer --disable-internal-sqlite to remain but again you are the maintainers and of course must make the final decision. -- James Turner ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Best practices: merge + new code change in single commit?
Hello, I have a question regarding how to handle check-ins that include both a merge into a branch from trunk (or another branch) and new code. Specifically, when such an event happens, is it possible when using the ui (or command line) to view a vdiff between the previous checkin and the merge+code checkin that does not include the merged content? I ask because I sometimes find it difficult to figure out which code was newly introduced and which code came from a merge when this happens and I wonder if I just don't know enough about the tool that I'm using to display just the relevant changes? For example, based on the comment of this checkin, I assume that there are both changes made to the branch and also changes that were brought in from a merge: http://www.fossil-scm.org/index.html/info/555c44eb5d Is there a way to filter out the changes that came in as part of a merge? Or is it possible to distinguish somehow? Thanks, Andy -- TAI64 timestamp: 400052c84629 ___ 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] Best practices: merge + new code change in single commit?
On Sat, Jan 4, 2014 at 12:34 PM, Andy Bradford amb-fos...@bradfords.orgwrote: Hello, I have a question regarding how to handle check-ins that include both a merge into a branch from trunk (or another branch) and new code. Specifically, when such an event happens, is it possible when using the ui (or command line) to view a vdiff between the previous checkin and the merge+code checkin that does not include the merged content? I ask because I sometimes find it difficult to figure out which code was newly introduced and which code came from a merge when this happens and I wonder if I just don't know enough about the tool that I'm using to display just the relevant changes? For example, based on the comment of this checkin, I assume that there are both changes made to the branch and also changes that were brought in from a merge: http://www.fossil-scm.org/index.html/info/555c44eb5d Is there a way to filter out the changes that came in as part of a merge? Or is it possible to distinguish somehow? From the link above click on family. That shows a small graph which contains the [555c44eb5d] check-in together with its parents and children. In that graph, click once on the primary parent ([4f32dced74]) then a click on the merged-in parent ([b7fff13a0aa]) and that will show you the differences between those to versions: http://www.fossil-scm.org/index.html/vdiff?from=4f32dced744f4514to=b7ff13a0aa6317f2sbs=1 And those differences are the merge. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Minor bug in new views
File ages view: No buttons to go to other views. All other views: There seems to be some inconsistency about which button are displayed. I don't remember the old behavior, but I think Tip/Trunk/All should always be displayed (except when on Tip/Trunk/All), and 2 of Flat View/Tree View/File ages should be there. -- ˙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
[fossil-users] fossil server commit and other hooks?
Hi,
I'd like to know how to setup commit hooks on a fossil server
so that, for example, I can perform an automatic checkout,
run tests and restart a server. I intend to use this for
deploying projects on a server - sort of like heroku's
deploy using git push.
This has come up a few times in the past iirc, but I'm not
sure whether there is any resolution on whether fossil will
ever accept to support this and if so in what form it might
take.
I'd like to propose something that (afaik) has not been
proposed --
Expose fossil server activity in the form of hook URLs
to which information about the activity is sent by POST
with the body in JSON format. With this setup, it would
be possible to code up a hook client in, say, node.js
which can respond appropriately.
So, for example, if trunk just got a new commit, and
a hook URL root of http://localhost:/myserver/;
is registered, then a POST to http://localhost:/myserver/commit;
is made with the body something like -
{branch:trunk, commit:longhexSHAid, comment:some text, ...}
Multiple such root URLs may be registered. In case connection
to one fails, it can be simply ignored.
I think there would be no need for the fossil server
to wait for the post action to complete before continuing
with whatever it needs to do (though I admit I haven't thought
that through).
Thoughts?
-Kumar
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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 compilation under MINGW
On Sat, Jan 4, 2014 at 11:04 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Jan 4, 2014 at 10:59 AM, Joseph R. Justice jayare...@gmail.comwrote: On Fri, Jan 3, 2014 at 9:28 PM, Richard Hipp d...@sqlite.org wrote: OK, so I propose the following fix: [...] (2) Remove the --disable-internal-sqlite option on trunk. Require the use of the built-in SQLite only, since SQLite needs to be built with non-standard compile-time options to fully meet the needs of Fossil. [...] (4) When distributions complain, we simply explain that we tried using an external SQLite but it introduced too many complications and bugs and that we now require statically linking SQLite for reasons of security and reliability. Just to make sure I understand... You intend to eliminate the capability of --disable-internal-sqlite for Fossil not only for tip-of-trunk of Fossil, and not only for development snapshots (although you don't really have that, do you?), but *also* for future *release* versions of Fossil as well. Correct? In other words, on http://www.fossil-scm.org/download.html , if and when there is a Version 1.28 (and also for later versions beyond that one), the distributed source code for that version (or later) of Fossil will no longer support --disable-internal-sqlite, and any distribution wishing to package that version of Fossil such that it will use their system-provided shared library version of SQLite (which presumably will or at least may be different from the version provided with Fossil as an embedded code copy) will be entirely on their own to implement that capability. And further, presumably, the fossil-scm.org devs will not accept patches from external contributors (such as distribution packagers of Fossil) to be applied to the source code for the released version of Fossil to re-add this capability. That is my proposal, yes. The rational is that --disable-internal-sqlite adds no new capabilities to the program, but it does add complexity and risk. Okay. I intend (from the perspective of an interested bystander both of fossil-scm and of Unix/Linux distributions, wishing them to cooperate and coexist as happily as possible), to contact the package maintainers of Fossil within the various major Unix/Linux distributions (for some definition of the word major, for distributions which provide Fossil as part of their distribution *and* which actively package it (as opposed to just using some other distribution's package without changes), and where I can identify and contact the applicable package maintainer), to inform them of this proposed change to future release versions of Fossil, and to encourage them to comment here on this list if they wish to speak up concerning this proposal before it is implemented by the fossil-scm devs. I will also encourage them to subscribe to this list if they have not yet done so, so that they can do a better job of representing their distribution to the fossil-scm.org devs (who are the upstream for Fossil). I will notify this list of the distributions and package maintainers I contact (and of any distributions which should be contacted but where I cannot manage to identify or contact the maintainer). At a minimum, I expect/hope to contact the applicable packager for the following distributions (subject to their packaging Fossil as part of the distribution; if they do not, there is no reason for me to contact them): (1) Debian (Ubuntu derived from Debian and has the same maintainer, Linux Mint derived from Ubuntu and/or Debian may use the same package, many others derived from Debian and/or Ubuntu) (2) Fedora (CentOS and Scientific derived from RHEL which is largely derived from Fedora, note that Fedora provides EPEL which is Fedora packages compiled for RHEL, CentOS, Scientific; might be good to contact CentOS and Scientific anyway) (3) openSUSE () (4) Gentoo (Sabayon derived from Gentoo) (5) Slackware () (6, 7, 8) The BSDs: FreeBSD, NetBSD, OpenBSD (NOTE: The packager for Fossil for OpenBSD is already a participant in this discussion and does not need to be contacted!) (9, 10) The Solaris variants: OpenIndiana, SmartOS I may also contact: Arch (Manjaro derived from Arch), Mageia (), Puppy (), DragonFly BSD, GhostBSD, MidnightBSD, PC-BSD (all these BSDs derived from FreeBSD), but will not worry about them as much as the 10 I've identified above. Proposed message, *please* comment if you disagree with any of it or wish me to add any information, I will not send this message before the evening (East Coast USA time) of Tues, 7 Jan 2014 (possibly later if it takes me longer to identify a maintainer): == Hello. I am an interested bystander of the Fossil SCM project (www.fossil-scm.org). I am *not* a developer within this project, nor do I have any other authority or responsibility within it than any random bystander and member of the peanut gallery might have. I have identified you as the person within
Re: [fossil-users] fossil server commit and other hooks?
On 04/01/14 18:52, Srikumar K. S. wrote: [...] This has come up a few times in the past iirc, but I'm not sure whether there is any resolution on whether fossil will ever accept to support this and if so in what form it might take. I believe that currently most people do this the other way round, by using the RSS feed functionality. Your build server periodically polls the feed for a particular branch, and whenever it sees a new checkin, it schedules a new checkout and build. Using a pull approach rather than a push approach simplifies things considerably as the only server/server interaction is initiated from the test framework, which has to have it anyway. Not having Fossil have to know anything about the test framework is a big win. -- ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─ │ There does not now, nor will there ever, exist a programming │ language in which it is the least bit hard to write bad programs. --- │ Flon's Axiom 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] fossil server commit and other hooks?
2014/1/4 Srikumar K. S. srikuma...@gmail.com: I'd like to propose something that (afaik) has not been proposed -- Expose fossil server activity in the form of hook URLs to which information about the activity is sent by POST with the body in JSON format. With this setup, it would be possible to code up a hook client in, say, node.js which can respond appropriately. Yes, something like this has been proposed, and is currently implemented in trunk. It takes the form of a new commit TH1 hook( Admin - Xfer), which can do http requests. The only information available in the hook GET/POST is the uuid, from that the server can derive anything else it needs to know by accessing the fossil repository. Other people already used this successfully, so feel free to try it and post your feedback here. Thanks! 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] fossil server commit and other hooks?
On Sat, Jan 4, 2014 at 1:52 PM, Srikumar K. S. srikuma...@gmail.com wrote: This has come up a few times in the past iirc, but I'm not sure whether there is any resolution on whether fossil will ever accept to support this and if so in what form it might take. The difficulty here is that the server does not know when it has received a push of a check-in. A single check-in consists of one or more artifacts. There is always at least a manifest artifact. And there are usually additional artifacts containing the text of files that have changed. The repository is just a bag of artifacts. Some artifacts are unique to a particular check-in. Some artifacts are shared between multiple check-ins. Other artifacts contain wiki pages or changes to trouble tickets, etc. When a sync or push or pull occurs, the two endpoints merely exchange artifacts. The sync operation does not know what those artifacts represent however. So the sync logic does not know if it has received a wiki page change, or a complete check-in, or 5 different check-ins, or just part of a single check-in. The sync logic just knows that it got a few artifacts. Because the sync logic does not know the meaning of the artifacts it has received, it has no way of triggering some action when a check-in is received. -- D. Richard Hipp d...@sqlite.org ___ 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] fossil server commit and other hooks?
2014/1/4 Richard Hipp d...@sqlite.org: Because the sync logic does not know the meaning of the artifacts it has received, it has no way of triggering some action when a check-in is received. The sync logic itself indeed doesn't know the meaning of the artifacts, but every artifact which is received is parsed in order to be able to update the various tables. After this parsing, the needed information is available, this is used to trigger the Transfer Commit Script if it was a commit or the Transfer Ticket Script if it was a ticket change. 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
[fossil-users] TH1: set v 0; unset v; info exists v;
Hi Excuse my batch mails on TH1 :-) And although they say that TH1 is the scripting language for web pages ... [http://en.wikipedia.org/wiki/TH1] TH1 is great tool for other tasks. And as I play with TH1 in these days my scripts find some things. New one SYNOPSIS % ./fossil version This is fossil version 1.28 [da90bbe591] 2014-01-04 16:17:47 UTC % ./fossil test-th-eval 'set v 1; unset v; info exists v' 1 We expect 0. No issues with unset % ./fossil test-th-eval 'set v 1; unset v; expr $v+0' TH_ERROR: no such variable: v It seems this was introduced with Th_ExistsVar() http://fossil-scm.org/index.html/artifact/a561c58c237b3eb43eaf55e6f9cc6a9b8a26e5d1?ln=1154-1159 (check-in http://fossil-scm.org/index.html/info/4f8c8975bc). As I could see Th_ExistsVar() does miss a test for pValue-zData as Th_GetVar() does http://fossil-scm.org/index.html/artifact/a561c58c237b3eb43eaf55e6f9cc6a9b8a26e5d1?ln=1142-1149. Right? Could you, please, fix that? Thanks for Fossil and TH1. Sergei ___ 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] fossil server commit and other hooks?
On Sat, Jan 4, 2014 at 5:24 PM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2014/1/4 Richard Hipp d...@sqlite.org: Because the sync logic does not know the meaning of the artifacts it has received, it has no way of triggering some action when a check-in is received. The sync logic itself indeed doesn't know the meaning of the artifacts, but every artifact which is received is parsed in order to be able to update the various tables. After this parsing, the needed information is available, this is used to trigger the Transfer Commit Script if it was a commit or the Transfer Ticket Script if it was a ticket change. Receiving a manifest does not mean that you have received the entire check-in. -- D. Richard Hipp d...@sqlite.org ___ 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] fossil server commit and other hooks?
2014/1/4 Richard Hipp d...@sqlite.org: Receiving a manifest does not mean that you have received the entire check-in. True. The file content might not be available yet, but the commit comment message and the file list is. The server might need some delay and/or retry. But it should be usable enough. 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] New Tree-View feature requires newer sqlite.
On Thu, Jan 2, 2014 at 9:52 PM, Nico Williams n...@cryptonector.com wrote: More generally, trying to ensure that a) there's only one copy of every library in the distro/OS, b) all version dependencies match up, is *super* hard, if not impossible. Eventually there are some very commonly used libraries where the simplest thing to do is to just ship multiple versions, but first the distro maintainer ought to make sure that the POSIX file locking disaster you mention can't happen as a result. If I may ask, because I'm confused... Is your position on distributions trying to ensure that there is only one copy of every library in the distribution by desiring (or even requiring mandatory) use by distribution-distributed applications of shared system/distribution-provided versions of libraries (instead of allowing applications to have and use private copies of libraries) that they need that: (a) it is generally a good or desirable thing (albeit a super hard task); (b) it is generally a bad or undesirable thing; (c) you have no position either way on whether it is good or bad, you are merely noting for the record that to do it is a super hard or even impossible task for the distributions; and/or (d) something else altogether (and if so what if you are willing to say)? Also, I'm curious about your claim that there are some very commonly used libraries where the simplest thing to do is to just ship multiple versions. I am *not* saying this is not the case, because I simply do not know! I haven't even attempted to do the research (nor am I sure how or if the research could be easily done). I'm certainly willing to accept that what you say on this is true. I am wondering however if you could identify some of these libraries and/or the distributions which ship multiple copies of them, at least if there are any that spring quickly to your mind. (Note, I do *not* consider that if you do or can not identify any such libraries or distributions that this means your claim about them is not true! It just means that while you might have encountered them in the past you haven't done so recently enough to recall them easily in response to a casual request.) Thanks for giving me a moment of your time. Hope this is of some use, interest. I look forward to seeing any response to this query you might care to make. Joseph ___ 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] CSS classes in tree-view?
Hi Martijn, Martijn Coppoolse wrote: Hi all, I really like the new tree-view feature. I set out to apply the same CSS tricks to differentiate files and directories, but it turns out that unlike the 'flat view', no CSS classes are included. Would it be possible to add those to each a link? My csstree branch uses nested lists instead of one big PRE element. This gives us quite a bit of flexibility in changing the look of the tree. The classes for dirs/files are the same as in the flat view (they're also placed on the LI elements). I'm guessing it'll be merged into trunk fairly soon. ___ 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] CSS classes in tree-view?
Richard Hipp wrote: I think Joel Bruick is already working on this in a branch. I just haven't gotten around to vetting and merging his changes, yet. Richard, I'm pretty happy with the state of the csstree branch now. Unless I'm overlooking something, I'd say it can be merged anytime. Let me know if there's anything you'd like me to change. ___ 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] CSS classes in tree-view?
On Sat, Jan 4, 2014 at 8:12 PM, Joel Bruick j...@joelface.com wrote: Richard Hipp wrote: I think Joel Bruick is already working on this in a branch. I just haven't gotten around to vetting and merging his changes, yet. Richard, I'm pretty happy with the state of the csstree branch now. Unless I'm overlooking something, I'd say it can be merged anytime. Let me know if there's anything you'd like me to change. I compiled it and ran it but found the output hard to read. I think the problem is that the descending lines that come out of the bottom of folders do not terminate at the list subelement of that folder, but instead appear to keep going down into the next sibling of the folder. -- D. Richard Hipp d...@sqlite.org ___ 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] Best practices: merge + new code change in single commit?
Thus said Richard Hipp on Sat, 04 Jan 2014 13:13:11 -0500: From the link above click on family. That shows a small graph which contains the [555c44eb5d] check-in together with its parents and children. In that graph, click once on the primary parent ([4f32dced74]) then a click on the merged-in parent ([b7fff13a0aa]) and that will show you the differences between those to versions: Hmm, perhaps I'm misusing the word ``merge'' as this vdiff still seems to show all the changes that were brought in by the merge with [b7fff13a0aa]. What I am trying to do is see the difference between [4f32dced74] and [555c44eb5d] as if [b7fff13a0aa] had not been merged in, or in other words, to know which changes did not come as a result of the merge with [b7fff13a0aa] but were introduced as new changes. For example: http://www.fossil-scm.org/index.html/fdiff?v1=90129388bc0ef2ffv2=2f327786b8b200adsbs=1 I believe this is one such change that was made to a file that did not come from [b7fff13a0aa] but I had to guess that this change did not come from [b7fff13a0aa] based on the comment in the check-in. Hopefully I'm making myself clear, or maybe just thinking about this the wrong way... If the only change made when merging from trunk to a feature branch is the merge, then it is easy to track the changes. But when a merge from trunk is made and new code is originated and both are committed in the same check-in, I find it hard to locate the newly originated code for that feature branch. Maybe this is just how it is and there is nothing Fossil can do to clarify the situation? Thanks, Andy -- TAI64 timestamp: 400052c8b741 ___ 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] Best practices: merge + new code change in single commit?
On Sat, Jan 4, 2014 at 8:36 PM, Andy Bradford amb-fos...@bradfords.orgwrote: I am trying to do is see the difference between [4f32dced74] and [555c44eb5d] as if [b7fff13a0aa] had not been merged Maybe this is what you want: fossil up 4f32dced74 fossil merge b7ff13a0aa fossil diff --from 555c44eb5d Then after you finish, restore your checkout using fossil revert. -- D. Richard Hipp d...@sqlite.org ___ 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] Best practices: merge + new code change in single commit?
Thus said Richard Hipp on Sat, 04 Jan 2014 21:06:50 -0500: Maybe this is what you want: fossil up 4f32dced74 fossil merge b7ff13a0aa fossil diff --from 555c44eb5d Yes, this is one way of accomplishing what I want, thank you. Andy -- TAI64 timestamp: 400052c8c28d ___ 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] CSS classes in tree-view?
Richard Hipp wrote: On Sat, Jan 4, 2014 at 8:12 PM, Joel Bruick j...@joelface.com mailto:j...@joelface.com wrote: Richard Hipp wrote: I think Joel Bruick is already working on this in a branch. I just haven't gotten around to vetting and merging his changes, yet. Richard, I'm pretty happy with the state of the csstree branch now. Unless I'm overlooking something, I'd say it can be merged anytime. Let me know if there's anything you'd like me to change. I compiled it and ran it but found the output hard to read. I think the problem is that the descending lines that come out of the bottom of folders do not terminate at the list subelement of that folder, but instead appear to keep going down into the next sibling of the folder. I've made some small tweaks that hopefully improve things in this regard. ___ 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] Markdown
On Wed, 24 Jul 2013 10:46:01 -0500 djg...@gmail.com wrote: Didn't read the change notes for 1.26 until a couple days ago. I just noticed that markdown is now turned on by default this is awesome! I'ts beginning of New Year and another opportunity to re-evaluate Fossil...having Markdown I very nice feature, but I wonder where one can find some docs about its usage, what kind of 'dialect' is supported etc.? I was looking in the wiki, but didn't find much. Sincerely, Gour -- One must deliver himself with the help of his mind, and not degrade himself. The mind is the friend of the conditioned soul, and his enemy as well. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] Markdown
I was caught off guard since I saw my email your reply. You can use the as a starting guide: http://daringfireball.net/projects/markdown/ Jonathan Otsuka On Jan 4, 2014, at 11:10 PM, Gour g...@atmarama.net wrote: On Wed, 24 Jul 2013 10:46:01 -0500 djg...@gmail.com wrote: Didn't read the change notes for 1.26 until a couple days ago. I just noticed that markdown is now turned on by default this is awesome! I'ts beginning of New Year and another opportunity to re-evaluate Fossil...having Markdown I very nice feature, but I wonder where one can find some docs about its usage, what kind of 'dialect' is supported etc.? I was looking in the wiki, but didn't find much. Sincerely, Gour -- One must deliver himself with the help of his mind, and not degrade himself. The mind is the friend of the conditioned soul, and his enemy as well. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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
[fossil-users] Issues with Compiling Fossil on Windows with SSL
I am having trouble compiling fossil on windows with SSL. I have tried MinGW/MSYS and Cygwin, and I get stuck at different parts. When I use MinGW/MSYS, I get an error in utf8.c about cywgin_conv_path not being defined. When I use Cygwin, I get pretty far before getting an error, wbld/sqlite3.o:sqlite3.c:(.text+0x158e7): undefined reference to `_msize' // wbld/sqlite3.o:sqlite3.c:(.text+0x3b21): undefined reference to `_msize' followed by bad reloc address in section '.data'. I have successfully compiled Fossil with SSL, but it was more than a year ago and I would like to update to the latest version. I have basic installations of MinGW/MSYS and Cygwin, with all the right extras added in, but I do not know what to do with these errors. I am a primarily Windows user, so I do not have any experience with compiling programs. I searched through the list archives and tried to adapt the solutions and steps I saw to fix my problems, but was ultimately unable to. I am hoping somebody can help. Thank you. // JR ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
