Re: [fossil-users] Bug report: fossil settings/unset no longer supports "-R"
Thus said Roy Keene on Tue, 22 Nov 2016 14:45:22 -0600: > In previous versions of Fossil one could do "fossil unset -R > ssh-command", however Fossil 1.36 added a call to verify_all_options() > in src/db.c:settings_cmd ( > http://fossil-scm.org/index.html/info/816bc43b8064bf4d ). > > This function notices the "-R" option is present and not previously > removed and causes an error to be printed. I noticed this as well last week but didn't realize it was a regression, thinking instead that it was just missing functionality. Basically, I wanted to set a local setting in an unopened repository: $ cd /tmp $ fossil new new.fossil project-id: 13375765e947c6124c5c16c51881017a03ec9d53 server-id: 9ae77e171c6925e3c6ee9e3a0d2479c0568688ab admin-user: amb (initial password is "fe1fb8") $ fossil set -R new.fossil http-port unrecognized command-line option, or missing argument: -R $ fossil version This is fossil version 1.37 [467c4269b0] 2016-11-18 08:22:36 UTC According to ``fossil bisect'' it stopped working with [816bc43b8064bf4d]: http://www.fossil-scm.org/index.html/timeline?c=816bc43b8064bf4d Andy -- TAI64 timestamp: 40005834bbc6 ___ 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] Bug report: fossil settings/unset no longer supports"-R"
Roy Keene wrote; > > [rkeene@kps-rsk-laptop pipethread]$ fossil all unset ssh-command > fossil unset -R /home/rkeene/.repos/home.fossil ssh-command > unrecognized command-line option, or missing argument: -R > [rkeene@kps-rsk-laptop pipethread]$ > I see the logic in what you are saying; however, so far, I'm unable to reproduce the error message on Windows or Unix when using set/unset with the -R option. What build configuration/options are you using for Fossil? -- Joe Mistachkin @ https://urn.to/r/mistachkin ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Bug report: fossil settings/unset no longer supports "-R"
To whom it may concern, I would like to report a bug introduced in Fossil 1.36. In previous versions of Fossil one could do "fossil unset -R ssh-command", however Fossil 1.36 added a call to verify_all_options() in src/db.c:settings_cmd ( http://fossil-scm.org/index.html/info/816bc43b8064bf4d ). This function notices the "-R" option is present and not previously removed and causes an error to be printed. The "fossil all unset" and "fossil all setting" command use this functionality and are now subsequently broken (a regression): [rkeene@kps-rsk-laptop pipethread]$ fossil all unset ssh-command fossil unset -R /home/rkeene/.repos/home.fossil ssh-command unrecognized command-line option, or missing argument: -R [rkeene@kps-rsk-laptop pipethread]$ Thanks, Roy Keene ___ 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] private branches
On 11/21/2016 8:47 PM, Scott Doctor wrote: Reading through the fossil documentation about private branches. It states that There is no way to convert a private branch into a public branch. But all of the changes associated with the private branch are folded into the public branch and are hence visible to other users of the project. I am confuzzled. Seems the private branch becomes public by folding into the public branch. After merging a private branch to a public branch, the public sees only a single change containing all the work done on the private branch. As is usual after a merge, you have to provide whatever notes are appropriate to describe that change when you check it in. If you choose to only say "Added new feature, tested and working." then that is all the public will know. You could, instead, provide a summary of the process reflected by the many private changes. Either way, the details on the private branch will remain private to that single repository. Unless you take some additional actions to publicize them. A strong motivation for private branches is to permit a user to make local changes that cannot be accidentally published. This can be valuable when adapting to local conditions when that would require local changes to build scripts and makefiles, for example. The workflow there is to clone the public repository, then in your checkout make the needed changes until you get a working build. You can preserve that work by checking it in to a private branch. When the upstream repository has new features you want to include in your build, you merge *from* it into your private branch. Since you never make changes to a public branch, fossil won't even try to push your changes, and you won't need to have write access to the upstream repository. I am inheriting some 20 year old C code for a device that is being completely redesigned with modern everything. The algorithms used in the old code required going through many months of verification and certification (government mandated). I need to track all changes (I am going to be gut it using a facsimile of the core algorithm) so I figure this is a good candidate for using Fossil. They are currently using an ancient CVS system that, well I could not find a single reference to it anywhere. So I am going to try to convince them to use a different system since we are effectively starting from scratch. So I am back again trying to figure out the details how to use fossil before I am forced to use some other system. Fossil seems to be the least painful of the alternatives. This sort of project is similar to a large number of my past projects. We have found fossil to be extremely valuable. My primary advice would be to find the workflows that make fossil work for you. If it feels like you are fighting fossil, then take a step back and make sure you are trying to do something sensible. Following that, I'd say that getting a local server running so that your repositories can sync with a second machine and be stored on more than one separate physical disk is an important early milestone. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ +1 626 303 1602 ___ 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] private branches
Hi Scott, On Mon, Nov 21, 2016 at 08:47:22PM -0800, Scott Doctor wrote: > Reading through the fossil documentation about private branches. It > states that There is no way to convert a private branch into a > public branch. But all of the changes associated with the private > branch are folded into the public branch and are hence visible to > other users of the project. Private branch use to be very limited in functionality. If I remember well, it was possible to convert all the private branches at once, but not a single branch. But since the addition of the "bundle" functionality, it's now possible to convert a private branch into a public branch easily using the "publish" command. see http://fossil-scm.org/index.html/help?cmd=publish [snip] Regards -- Martin G. ___ 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] private branches
Thus said Scott Doctor on Mon, 21 Nov 2016 20:47:22 -0800: > But all of the changes associated with the private branch are folded > into the public branch and are hence visible to other users of the > project. Precisely, only the changes are visible (e.g. the diff between the two merge parents), but the branch, and all the changes leading up to the merge will still be private. So if you add a line, then remove the line, when you merge there will be no public record of having added and removed a line. Andy -- TAI64 timestamp: 40005834836a ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
