Re: [fossil-users] few TODO items
On Sat, Aug 3, 2013 at 3:36 PM, Gour g...@atmarama.net wrote: a) Search feature seems to be addressed, right? Yes. b) uncomit - ability to simply uncommit last commit which I'd do while still staying in my local repo and prior to pushing any changesets to the wilderness. It's simply tedious not to be able to fix simple/common mistakes and edit commit line is simply not enough. Any pending plan in regard? i _think_ that came up once before, but it hasn't been specifically addressed, AFAIR. c) pushing/managing single branches - at the present moment the mantra is 'all or nothing' which is also quite inconvenient when one wants to have e.g. several experimental feature branches and merge (even rebase them to the main trunk) before pushing (some) to the upstream. Any work on it? One of the devs did some work on this a year or so ago, but i don't know how that ended. -- - 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] Code review (reloaded)
On Sat, Aug 3, 2013 at 5:55 PM, Andy Bradford amb-fos...@bradfords.orgwrote: fossil tag find experimental It doesn't appear to have a way to limit the number of results to return, so it isn't exactly the same. Sure, it does! http://fossil-scm.org/index.html/info/73135ec22a -- - 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] Code review (reloaded)
On Sat, Aug 3, 2013 at 6:23 PM, Stephan Beal sgb...@googlemail.com wrote: Sure, it does! http://fossil-scm.org/index.html/info/73135ec22a Caveat: when using the --raw flag the ordering is undefined (those elements have no time information, apparently), so the limit is not all that useful there. -- - 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] Code review (reloaded)
Thus said Stephan Beal on Sat, 03 Aug 2013 18:23:46 +0200: http://fossil-scm.org/index.html/info/73135ec22a Wow that was quick! I suppose an alternate approach could have been to modify ``fossil timeline'' to accept a TAG to restrict its search to just those artifacts with the TAG, since it already had the ability to restrict it to a limit. It also has the ability to restrict the search to particular timeframe. Andy -- TAI64 timestamp: 400051fd3375 ___ 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] few TODO items
On Aug 3, 2013 7:09 AM, Stephan Beal sgb...@googlemail.com wrote: On Sat, Aug 3, 2013 at 3:36 PM, Gour g...@atmarama.net wrote: a) Search feature seems to be addressed, right? Yes. b) uncomit - ability to simply uncommit last commit which I'd do while still staying in my local repo and prior to pushing any changesets to the wilderness. It's simply tedious not to be able to fix simple/common mistakes and edit commit line is simply not enough. Any pending plan in regard? i _think_ that came up once before, but it hasn't been specifically addressed, AFAIR. c) pushing/managing single branches - at the present moment the mantra is 'all or nothing' which is also quite inconvenient when one wants to have e.g. several experimental feature branches and merge (even rebase them to the main trunk) before pushing (some) to the upstream. Any work on it? One of the devs did some work on this a year or so ago, but i don't know how that ended. Sorry, on mobile and time constrained, but do private branches address this in any way? -- - 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] few TODO items
On Sat, Aug 3, 2013 at 6:49 PM, B Harder brad.har...@gmail.com wrote: Sorry, on mobile and time constrained, but do private branches address this in any way? No idea - i have never used private branches. -- - 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] Code review (reloaded)
On Sat, Aug 3, 2013 at 6:44 PM, Andy Bradford amb-sendok-1378140242.poacifknllljkhgok...@bradfords.org wrote: Thus said Stephan Beal on Sat, 03 Aug 2013 18:23:46 +0200: http://fossil-scm.org/index.html/info/73135ec22a Wow that was quick! Only because it was easy to do and i'm belly-deep in the fossil sources working on the library API ;). I suppose an alternate approach could have been to modify ``fossil timeline'' to accept a TAG to restrict its search to just those artifacts with the TAG, since it already had the ability to restrict it to a limit. It also has the ability to restrict the search to particular timeframe. It can already search by tags: http://fossil-scm.org/index.html/help?cmd=/timeline Ah, right, that's the www interface and you want the CLI... that one's a bit more difficult, so i won't be patching that tonight. The timeline is probably the most complicated single piece of functionality in the app, and touching it requires more nerves than i have left in me for today ;). But... using the new library API it took me about 3 minutes to tweak the timeline test script to do that: [stephan@host:~/cvs/fossil/f2/th1ish]$ ./th1ish t2.th1ish -- -R=../../fossil.fsl -t=experimental -n=3 The 3 most recent timeline event(s) for ../../fossil.fsl: ci @ 2013-01-23 13:31:09 [970cc4f16f34] by [joerg] in branch [experimental] Only check time, if it is set. ci @ 2013-01-18 23:05:39 [ee6ae580eee0] by [joerg] in branch [experimental] Add new option max-download-time to limit the processing time of pull/sync /clone requests. This helps to significantly cut down the number of time outs clients receive on busy server with reverse proxy configuration. It generally provides better response times. ci @ 2012-10-09 16:32:44 [b21df7ecafa5] by [drh] in branch [experimental] An alternative way to get mime-types from attachments for the raw page. So... just an idea of how users will be able to write ad-hoc solutions for their Fossil repos once this code is up and running. :) -- - 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] Code review (reloaded)
Thus said Stephan Beal on Sat, 03 Aug 2013 19:48:07 +0200: Ah, right, that's the www interface and you want the CLI... that one's a bit more difficult, so i won't be patching that tonight. The timeline is probably the most complicated single piece of functionality in the app, and touching it requires more nerves than i have left in me for today ;). Haha, I did have a look at the code but I found, as you have stated, that the query/code for the CLI timeline was complex enought that it would warrant more time. Andy -- TAI64 timestamp: 400051fd5061 ___ 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] few TODO items
B Harder wrote: Sorry, on mobile and time constrained, but do private branches address this in any way? I get a lot of mileage out of them, FWIW. When working on the Fossil codebase, I do all my experimental work (which turns out to be most of it...) in private branches. Then when I have something I feel relatively good about, I merge it into a public branch. This way I can fumble around with code I'm unfamiliar with or ideas I'm unsure about without flooding the timeline for everyone else. Richard would probably revoke my commit privileges if I didn't. ;) For anyone that's interested and doesn't know about/hasn't used private branches, here's a simplified example workflow from when I was working on what eventually became the sbsreloaded branch: fossil update trunk # Make some changes to diff-related files and start an experimental branch. fossil commit --private --branch diffexp # Make some more changes, committing to this branch as I go along. # ... # Just had an idea for an alternative implementation. # Go back to trunk, make a few changes, and branch again. fossil update trunk fossil commit --private --branch diffexp2 # Make several more commits to this branch before realizing I don't want # to continue down this path. Go back to the original experimental branch. fossil update diffexp # After a bunch of commits, I finally have something I want to share. # Merge it back into trunk and then commit it to a new public branch. fossil update trunk fossil merge diffexp fossil commit --branch sbsreloaded ___ 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] few TODO items
On Sat, 3 Aug 2013 09:49:43 -0700 B Harder brad.har...@gmail.com wrote: Sorry, on mobile and time constrained, but do private branches address this in any way? I don't know if something has changed, but previousy the only way to get rid of private branches was via: fossil scrub --private but, iirc, there was no option to select branch, iow. all the private branches are removed. Moreover, iirc, there was also another request to be able to push distinct branches which also, afaict, is not implemented. Both features are something which one takes for granted in every other DVCS (bzr, darcs, git, hg...) Sincerely, Gour -- From anger, complete delusion arises, and from delusion bewilderment of memory. When memory is bewildered, intelligence is lost, and when intelligence is lost one falls down again into the material pool. 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] few TODO items
Thus said Gour on Sat, 03 Aug 2013 21:25:01 +0200: Moreover, iirc, there was also another request to be able to push distinct branches which also, afaict, is not implemented. Both features are something which one takes for granted in every other DVCS (bzr, darcs, git, hg...) I distinctly recall reading a description of the differences between ``branches'' in Fossil and other DVCS (specifically Git), which likely explains why things are the way they are: http://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki Also, Additional Notes in the following mentions that it isn't currently possible (which we already knew): http://www.fossil-scm.org/fossil/doc/trunk/www/private.wiki This is not to say that things shouldn't change in Fossil regarding how branches work. Regarding private branches, I do use them, however, I'm not yet certain when I would ever want to scrub them, singly, or as a whole. But it does seem like private branches could be used to work on things that don't get sync'ed and then merge them in when ready. This does mean, however, that the whole history of the development of whatever feature/bug is being worked on won't show up, but I see that as a benefit. Andy -- TAI64 timestamp: 400051fd5f39 ___ 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] few TODO items
On 3 Aug 2013 13:50:46 -0600 Andy Bradford amb-fos...@bradfords.org wrote: I distinctly recall reading a description of the differences between ``branches'' in Fossil and other DVCS (specifically Git), which likely explains why things are the way they are: Yeah, this explains things: So to a first approximation, branches in Git are developer-centric whereas branches in Fossil are feature-centric. But having private branches in Fossil is then not consistent with: One consequence of the everybody-sees-everything focus of Fossil is that branch names are global and are part of the distributed and synchronized content of a Fossil repository, rather than being private and user-specific as they are in Git. This is not to say that things shouldn't change in Fossil regarding how branches work. Well, recalling how much opposition was against using some more 'standard' markup (ala markdown) and how long it took to implement it, I would not hold by breath in regard to changing branches mechanism. :-) Regarding private branches, I do use them, however, I'm not yet certain when I would ever want to scrub them, singly, or as a whole. In Git, as well as in other DVCS which I used before (darcs, bzr, hg), it's quita natural to get rid of 'used' feature branches when they are merged. But it does seem like private branches could be used to work on things that don't get sync'ed and then merge them in when ready. That's correct. This does mean, however, that the whole history of the development of whatever feature/bug is being worked on won't show up, but I see that as a benefit. Yes, I agree that having private branch for unfinished/experimental work is useful, but, otoh, it seems quite logical if I one can make *single* branch as private, why not deleting it? Sincerely, Gour -- Perform your prescribed duty, for doing so is better than not working. One cannot even maintain one's physical body without work. 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] ip addr in log problem
On Sat, Aug 3, 2013 at 4:52 PM, reverse reve...@snowflakejoins.com wrote: Hi, I also had some problems behind proxy. Solved those by having one more Apache instance just for Fossil deployment. Please consider taking value of HTTP_FORWARDED_REQUEST_URI (if present) instead of PATH_INFO, and of X-Forwarded-For instead of REMOTE_ADDRESS. I sent in a patch to use X-Real-IP (same as X-Forwarded-For, I think?). Not sure why it wasn't accepted, but it's here if you want to apply it yourself: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2013-January/011414.html ___ 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] few TODO items
On 3 Aug 2013 14:58:01 -0600 Andy Bradford amb-fos...@bradfords.org wrote: Sometimes it's a matter of simply convincing enough people about why the current mechanism is *wrong* (offering to write the code also helps). Heh, check The case for Markdown (yes, I rtfm) thread from 2009. ;) Sincerely, Gour -- One who is not disturbed in mind even amidst the threefold miseries or elated when there is happiness, and who is free from attachment, fear and anger, is called a sage of steady mind. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 -- One who sees inaction in action, and action in inaction, is intelligent among men, and he is in the transcendental position, although engaged in all sorts of activities. 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] ip addr in log problem
On Sat, Aug 3, 2013 at 4:59 PM, Maxim Khitrov m...@mxcrypt.com wrote: On Sat, Aug 3, 2013 at 4:52 PM, reverse reve...@snowflakejoins.com wrote: Hi, I also had some problems behind proxy. Solved those by having one more Apache instance just for Fossil deployment. Please consider taking value of HTTP_FORWARDED_REQUEST_URI (if present) instead of PATH_INFO, and of X-Forwarded-For instead of REMOTE_ADDRESS. I sent in a patch to use X-Real-IP (same as X-Forwarded-For, I think?). Not sure why it wasn't accepted, Your patch would allow clients to forge their IP address by injecting an X-Forwarded-For header in the HTTP request. Fossil has no way of knowing if the X-Forwarded-For comes from a trusted proxy or a malicious client. -- 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] ip addr in log problem
On Sat, Aug 3, 2013 at 5:59 PM, Richard Hipp d...@sqlite.org wrote: On Sat, Aug 3, 2013 at 4:59 PM, Maxim Khitrov m...@mxcrypt.com wrote: On Sat, Aug 3, 2013 at 4:52 PM, reverse reve...@snowflakejoins.com wrote: Hi, I also had some problems behind proxy. Solved those by having one more Apache instance just for Fossil deployment. Please consider taking value of HTTP_FORWARDED_REQUEST_URI (if present) instead of PATH_INFO, and of X-Forwarded-For instead of REMOTE_ADDRESS. I sent in a patch to use X-Real-IP (same as X-Forwarded-For, I think?). Not sure why it wasn't accepted, Your patch would allow clients to forge their IP address by injecting an X-Forwarded-For header in the HTTP request. Fossil has no way of knowing if the X-Forwarded-For comes from a trusted proxy or a malicious client. What about adding a config option to allow this header only when fossil is running behind a reverse proxy? Alternatively, you could accept X-Forwarded-For by default when the remote address is the local host. That should take care of the most common setup. ___ 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] ip addr in log problem
On Sat, Aug 3, 2013 at 6:16 PM, Maxim Khitrov m...@mxcrypt.com wrote: Your patch would allow clients to forge their IP address by injecting an X-Forwarded-For header in the HTTP request. Fossil has no way of knowing if the X-Forwarded-For comes from a trusted proxy or a malicious client. What about adding a config option to allow this header only when fossil is running behind a reverse proxy? Alternatively, you could accept X-Forwarded-For by default when the remote address is the local host. That should take care of the most common setup. I'm testing a patch to do the latter now. Actually, my patch adds a subroutine cgi_accept_forwarded_for() which can return true or false to decide if the X-FORWARDED-FOR header is accepted. We can tweak that algorithm as necessary moving forward - to look for command-line options perhaps, or perhaps to accept X-FORWARDED-FOR from machines on the same subnet - stuff like that. -- 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 running out of memory
On Fri, Aug 2, 2013 at 11:55 AM, Richard Hipp d...@sqlite.org wrote: On Fri, Aug 2, 2013 at 11:51 AM, Benedikt Ahrens benedikt.ahr...@gmx.netwrote: Hello, I am having trouble with a fossil repository containing many binary files. The fossil version is the one packaged in Debian Wheezy: $ fossil version This is fossil version 1.22 [ab461f39af] 2012-03-29 08:48:38 UTC Any hints what I could try to better debug the problem, or to even solve it? Version 1.22 is pretty old. I suspect that this problem is already solved. Just upgrade and you should be fine. [I have intentionally CC'd the original poster with this response, on the off-chance he is not subscribed to fossil-users.] Debian Wheezy (a.k.a. 7.0) is the current stable version of Debian Linux. He is using the version provided by the distribution (specifically 1:1.22.1+dfsg-0.1 -- the +dfsg-0.1 presumably refers to modifications made by the packager to the original source code as provided by the Fossil Project to make it acceptable for distribution in the main (as opposed to contrib or non-free) section of Debian Linux). Debian Wheezy was officially released on 4 May 2013, with its first point release update on 15 Jun 2013. (It looks like Wheezy started to be frozen in terms of adding new software or new versions of software, so as to stabilize it for release as the next stable version of Debian Linux, around Apr 2012, tho not all of it was frozen at that time.) The current version of fossil in Debian Testing (which will become the next stable version of Debian Linux in due time) is 1:1.24+dfsg-0.1, entering Testing on 5 May 2013, which is still two point releases behind the current stable release of Fossil as distributed by the Fossil Project itself. Assuming the correct / easiest way to fix the problem is to upgrade the version of fossil being used, and assuming the original poster wishes to continue using fossil as provided by Debian (which allows it to be managed by the package management system, the bug tracking system, etc), he could either: 1: Upgrade his version of fossil to the version available through Debian Testing, which might involve changes to his system configuration -- how to do this is outside the scope of the fossil-users mailing list, and he should probably contact / use one or more of the resources available for support of Debian Linux if he needs help (which is the *point* of using a distribution-provided binary, after all). Good places to look at would include: 1.1: http://www.debian.org/support (talks about many different points of contact for support, including IRC, wikis, bug reports, mailing lists, etc); 1.2: http://www.debian.org/MailingLists/ (talks about the many Debian mailing lists for end-user support and other purposes); and specifically 1.3: http://lists.debian.org/debian-user/ (Help and discussion among users of Debian / Support for Debian users who speak English. (High-volume mailing list.)) 2: Request that the version of fossil available in Debian Testing be backported to Debian Wheezy, where it will be found in the wheezy-backports repository, and then install it from wheezy-backports. See http://www.debian.org/News/2013/20130320.en.html - Backports integrated in the main archive for more information. 3. Request that the version of fossil in Debian Testing be upgraded to the most recent stable version of fossil as released by the Fossil Project, which appears to be 1.26 (per http://www.fossil-scm.org/download.html), and then (if applicable) request this updated version be backported to wheezy-backports. The easiest way to do this would be to file a wishlist bug against fossil in the Debian bug tracking system requesting the new version be packaged and/or backported. Alternatively, the original poster could resend the bug and/or ask for help directly to Debian (by filing a bug against fossil in the BTS, sending a mail message requesting help to debian-user, etc). This might result in a version upgrade as mentioned above, or might result in just this bug being fixed (which fix hopefully would be sent upstream to the Fossil Project). Since Debian is providing the binary the original poster is using, Debian (and not the Fossil Project) is responsible for first-tier end-user support. (Debian presumably would forward upstream bugs and/or patches for them which were bugs in the original source code as distributed by the Fossil Project.) Unfortunately, I am not currently using Debian (or any) Linux, nor am I actively using fossil, so I myself cannot be of more direct help. But, that's my advice for the original poster, assuming they wish to continue to use fossil as provided by Debian (as opposed to fossil as provided by the Fossil Project). Thanks for giving me some of your time by reading this response. I hope it is of some use, interest. Be well. Joseph ___ fossil-users mailing list fossil-users@lists.fossil-scm.org
