Re: [fossil-users] submitting issue reports to/about fossil-scm.org
On 21 July 2015 at 12:07, Adam Jensen han...@riseup.net wrote: What is the best way to report little things like this? Also, what is a convenient format for project maintainers? (an HTML diff?) I'm not a maintainer but this is what I have done in the past, with guidance of others. 0. clone the repo 1. make your changes 2. fossil changes to list your changes 3. fossil diff filename here's the diff: --- www/webui.wiki +++ www/webui.wiki @@ -61,11 +61,11 @@ bfossil ui/b The latter case is a very useful short-cut when you are working on a Fossil project and you want to quickly do some work with the web interface. Notice that Fossil automatically finds an unused TCP port to run the -server own and automatically points your web browser to the correct +server on and automatically points your web browser to the correct URL. So there is never any fumbling around trying to find an open port or to type arcane strings into your browser URL entry box. The interface just pops right up, ready to run. The Fossil web interface is also very easy to setup and run on a -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] submitting issue reports to/about fossil-scm.org
On Tue, 21 Jul 2015 12:40:27 -0700 jungle Boogie jungleboog...@gmail.com wrote: I'm not a maintainer but this is what I have done in the past, with guidance of others. 0. clone the repo 1. make your changes 2. fossil changes to list your changes 3. fossil diff filename here's the diff: --- www/webui.wiki +++ www/webui.wiki @@ -61,11 +61,11 @@ bfossil ui/b The latter case is a very useful short-cut when you are working on a Fossil project and you want to quickly do some work with the web interface. Notice that Fossil automatically finds an unused TCP port to run the -server own and automatically points your web browser to the correct +server on and automatically points your web browser to the correct URL. So there is never any fumbling around trying to find an open port or to type arcane strings into your browser URL entry box. The interface just pops right up, ready to run. The Fossil web interface is also very easy to setup and run on a Interesting, thanks! What is step 4? Is the diff submitted to this mailing list, or is some kind of repo sync performed, or is a ticket submitted through the https://fossil-scm.org/index.html/ticket web interface (I don't see a way to do that, which seems odd)? ___ 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] close leaf from command-line, and 'apropos(1)'-like behaviour?
Thus said Michai Ramakers on Tue, 21 Jul 2015 11:06:31 +0200: Is there a way using legacy commands? You can always use fossil tag, however, using it requires more knowledge of internal mechanisms than you probably care to know. Andy -- TAI64 timestamp: 400055aec1d1 ___ 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 interest in testing/merging check-in-edit branch?
Thus said Stephan Beal on Tue, 21 Jul 2015 09:28:43 +0200: To be honest, i wouldn't bother with this - the code overhead of having to collect and sort the tags would not be worth it for this case, IMO. In principle there is no inherent limit. Save it for v2 ;). Also, I just realized, while there is no limit in the manifest design, nor is there a limit elsewhere internal, does this mean that the Fossil CLI has to allow someone to submit more than a fixed number? If they want to design their own tool to inject a manifest with more than X they certainly could do so. At the moment, the limit is 1. Would it be more useful if it were some number larger than 1? Thanks, Andy -- TAI64 timestamp: 400055aec371 ___ 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 interest in testing/merging check-in-edit branch?
Thus said Stephan Beal on Tue, 21 Jul 2015 09:28:43 +0200: for bonus points (certainly not necessary), allow multiple f-tag/-cancel lags: An unlimited of them (except of course by memory)? Or Fossil only account for a maximum number of tags? If the latter, what? To be honest, i wouldn't bother with this - the code overhead of having to collect and sort the tags would not be worth it for this case, IMO. In principle there is no inherent limit. Save it for v2 ;). Well, I already wrote the code for it last night (just hadn't committed pending your reply), and it only adds about 8 lines of additional code. All of the sorting is already handled by the database, so the only question is, should it be limited to some number of tags (I currently have it handling 16), or more, or less, or unlimited? Or not be implemented at all? Thanks, Andy -- TAI64 timestamp: 400055aec167 ___ 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] submitting issue reports to/about fossil-scm.org
On 21 July 2015 at 22:01, Adam Jensen han...@riseup.net wrote: On Tue, 21 Jul 2015 12:40:27 -0700 jungle Boogie jungleboog...@gmail.com wrote: I'm not a maintainer but this is what I have done in the past, with guidance of others. 0. clone the repo 1. make your changes 2. fossil changes to list your changes 3. fossil diff filename here's the diff: ... Interesting, thanks! What is step 4? Is the diff submitted to this mailing list, or is some kind of repo sync performed, or is a ticket submitted through the https://fossil-scm.org/index.html/ticket web interface (I don't see a way to do that, which seems odd)? (typo is fixed, thanks for the report) My $0.02: problem reports / questions / comments should probably go to this mailing-list first - plenty of people reading along, and feedback / fixes are fast most of the time. To be honest, I have never submitted a bug on the actual fossil-scm.org bugtracker - anyone correct me/us if this is desired instead :-) A diff can also make things very clear, indeed. 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] submitting issue reports to/about fossil-scm.org
On 21 July 2015 at 13:01, Adam Jensen han...@riseup.net wrote: Interesting, thanks! What is step 4? Is the diff submitted to this mailing list, or is some kind of repo sync performed, or is a ticket submitted through the https://fossil-scm.org/index.html/ticket web interface (I don't see a way to do that, which seems odd)? Well if you're like me and without commit access, just submit here on the mailing list. You can either do inline or as attachments. Many months ago Michai took many diffs from me and updated some verbiage on the site, and at that time, I attached the diffs because there were many. There's likely a few things I missed so feel free comb through the code and submit the improvements. FWIW, the fossil-scm.org bug tracker doesn't allow you to create bugs for the 'anonymous' user. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] moving part of existing branch onto another branch
Hello, question about pitfalls of fixing 'multiple open leaves' by closing all but one: Suppose I have a trunk with 4 check-ins A, B, C and D (in order of creation), and then decide to move B and C onto a separate branch. If I then move B to new branch 'parked-here', then move D (back) to trunk, then close leaf A, is the result something that could cause problems later on? (If so, which ones?) 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] Any interest in testing/merging check-in-edit branch?
On Tue, Jul 21, 2015 at 7:07 AM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Thu, 16 Jul 2015 08:19:00 +0200: for bonus points (certainly not necessary), allow multiple f-tag/-cancel lags: An unlimited of them (except of course by memory)? Or Fossil only account for a maximum number of tags? If the latter, what? To be honest, i wouldn't bother with this - the code overhead of having to collect and sort the tags would not be worth it for this case, IMO. In principle there is no inherent limit. Save it for v2 ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] close leaf from command-line, and 'apropos(1)'-like behaviour?
On Tue, Jul 21, 2015 at 11:06 AM, Michai Ramakers m.ramak...@gmail.com wrote: Hello, I was searching for a way to close a leaf from the command-line, and didn't find it. (The new 'check-in-edit' branch can do this using 'amend --close'.) Is there a way using legacy commands? Kind of, but this might not be what you are looking for: http://www.fossil-scm.org/index.html/help/commit see the --close option. Also, I notice there are generally questions on this list of the form 'where is command XYZ to do PQR', just like this very post. As the set of command-line commands and options grows, it becomes more difficult to find how to do something; some functionality exists as a separate command, some other exists as option to a command. (I had expected the 'branch' command to have a 'close' subcommand, for instance.) fwiw, that's where i just looked for it, too ;). Is it an idea to have an 'apropos(1)'-like subcommand or option to the... In my case, I knew I needed/wanted something that CLOSEs something, so I would have keyword-searched for 'close'. I'm happy with the 'amend' command btw. And I guess that as I become more familiar with fossil's internals or philosophy, it becomes easier to guess the command that provides a wanted behaviour. Sounds like a reasonable suggestion to me, but not sure how bothersome it would be to maintain the apropos mappings (maybe via extra internal tags in the help text blocks). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] close leaf from command-line, and 'apropos(1)'-like behaviour?
On 21 July 2015 at 11:12, Stephan Beal sgb...@googlemail.com wrote: On Tue, Jul 21, 2015 at 11:06 AM, Michai Ramakers m.ramak...@gmail.com wrote: Is it an idea to have an 'apropos(1)'-like subcommand or option to the... Sounds like a reasonable suggestion to me, but not sure how bothersome it would be to maintain the apropos mappings (maybe via extra internal tags in the help text blocks). Right; I somehow assumed the help-pages were generated (but didn't look yet). W.r.t. 'commit --close': thx, saw that, but that would be used with '--allow-empty' if I wanted to close after actually doing the last commit, right? I'm guessing 'amend' will find its way into trunk at some point. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] close leaf from command-line, and 'apropos(1)'-like behaviour?
Hello, I was searching for a way to close a leaf from the command-line, and didn't find it. (The new 'check-in-edit' branch can do this using 'amend --close'.) Is there a way using legacy commands? Also, I notice there are generally questions on this list of the form 'where is command XYZ to do PQR', just like this very post. As the set of command-line commands and options grows, it becomes more difficult to find how to do something; some functionality exists as a separate command, some other exists as option to a command. (I had expected the 'branch' command to have a 'close' subcommand, for instance.) Is it an idea to have an 'apropos(1)'-like subcommand or option to the 'help' command? For those that don't know, the 'apropos' command on *nix does a keyword search accross all manual pages - or perhaps help-pages, in case of fossil. In my case, I knew I needed/wanted something that CLOSEs something, so I would have keyword-searched for 'close'. I'm happy with the 'amend' command btw. And I guess that as I become more familiar with fossil's internals or philosophy, it becomes easier to guess the command that provides a wanted behaviour. Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] personal workflow: branches to subdivide big repo
Hello, (tl;dr = 'branches are nice') ok, this is probably somewhat obvious but it hit me only quite late. In a previous post I wondered whether people use nested / separate repos or one big repo to host a big project (http://lists.fossil-scm.org:8080/pipermail/fossil-users/2014-January/014922.html). What I really wanted then was to be able to see the 'sequence of edits' only applying to a subset of a big project-tree - e.g. to see all changes between points A and B in time, done in project-subdir 'source/GUI' (and ignore all other changes done elsewhere within that timespan). Related post: http://lists.fossil-scm.org:8080/pipermail/fossil-users/2014-July/017347.html I've been experimenting a bit with nested repos, which work nicely but add complexity, but only just now I realise a branch does exactly what I wanted to do - display an isolated sequence of edits. D'oh! 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] close leaf from command-line, and 'apropos(1)'-like behaviour?
On Tue, Jul 21, 2015 at 11:27 AM, Michai Ramakers m.ramak...@gmail.com wrote: W.r.t. 'commit --close': thx, saw that, but that would be used with '--allow-empty' if I wanted to close after actually doing the last commit, right? It could be used that way, but i've personally never tried --allow-empty. i assume everyone has been using the UI for closing branches or using merge --integrate (which closes the merged-in branch when the merge is committed). I'm guessing 'amend' will find its way into trunk at some point. i hope so :). -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
