Re: [fossil-users] Incomplete help command output / manpage
On Wed, May 13, 2015 at 11:38 PM, Stéphane Aulery saul...@legtux.org wrote: Le mercredi 13 mai 2015 à 03:42:30, Warren Young a écrit : On May 13, 2015, at 3:14 PM, Stéphane Aulery saul...@legtux.org wrote: I could not find how to report this bug to the tracker. This is subject to the Agreement as well as the contribution of code? I think you can consider it reported. And if I had another, how I should do aside post on the list? This list is the preferred approach. -- - 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] Stash DIFF
On 5/13/15, Tony Papadimitriou to...@acm.org wrote: Hello, Is there a way to see a ‘diff’ between two stashed ids, rather than stash to disk? How about fossil stash goto ID1 fossil stash diff ID2 -- 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] fossil http -h causes a segfault
Eric ___ 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 http -h causes a segfault
Tnx for the message. Fixed now on trunk. https://www.fossil-scm.org/fossil/info/648dc3e7046d657a -- 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] Feature idea: Protected branches
On 13/05/15 16:45, Ramon Ribó wrote: Hello, A reasonable solution could be a pre-commit hook, where the script in TH1 or TCL had access to the branch name of the commit and other details. As a result, the hook could accept the commit, raise a warning, ask for confirmation or deny the commit. This hook would not stop a determined hacker to make a sabotage of the repository, but would give some control over the distracted programmer. And in my experience it is much more common to deal with distracted programmers than with professional saboteurs. RR It wouldn't offer much control over a distracted programmer, because your local repo is always going to be under the full control of the user on the local machine - no hacking required. In which case, all you can do is prompt asking are you sure you want to commit to this branch. Is that feature really that useful? Maybe someone who thinks it us could write some code and supply it as a bundle so other's interested can try it, and see if it truly helps or is a hindrance in practice. I don't know the fossil codebase, so I don't know what's easiest to do, whether to add a TH hook, or for the sake of investigative purposes, just add another setting, which maybe takes a regexp, which is then used to determine whether or not to prompt. ___ 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] Feature idea: Protected branches
On Thu, May 14, 2015 at 1:51 PM, paul pault.eg...@gmail.com wrote: It wouldn't offer much control over a distracted programmer, because your local repo is always going to be under the full control of the user on the local machine - no hacking required. As I previously pointed out, with any DVCS - not just Fossil - any such controls will ultimately be advisory in nature. If you need actual enforcement, you probably need a CVCS, not a DVCS. I don't think it's likely a distracted dev will override or subvert the rules imposed by the hook mechanism. A dev determined to get around the rules is a completely different issue. ___ 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] Feature idea: Protected branches
On 14/05/15 20:04, Ron W wrote: I don't think it's likely a distracted dev will override or subvert the rules imposed by the hook mechanism. A dev determined to get around the rules is a completely different issue. But a developer could just disable the hook code in the local repository? There wouldn't be anything to stop that. Or am I misunderstanding something? What I'm saying is a developer wouldn't need to be determined. ___ 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] Feature idea: Protected branches
On Thu, May 14, 2015 at 4:37 PM, paul pault.eg...@gmail.com wrote: But a developer could just disable the hook code in the local repository? There wouldn't be anything to stop that. Or am I misunderstanding something? If a dev wants to do that, he could. But a dev who is merely distracted, is unlikely to do that. What I'm saying is a developer wouldn't need to be determined. Perhaps the connotation of determined is too strong. Anyway, disabling or changing the hook in the local repo would be an deliberate action, not an accidental mistyped or omitted parameter to a command. ___ 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 changes] and execute/symlink flag changes
On 5/8/2015 1:13 PM, Warren Young wrote: On May 7, 2015, at 6:21 PM, Andy Goth andrew.m.g...@gmail.com wrote: My question is whether this extra level of reporting should be standard [fossil changes] behavior or only accessible if an extra option is supplied. My vote is to make it always report execute bit and symlink state changes. I’m in favor of the idea, but I’ll tell you this up front: I’ll never see the warning unless it appears in either “fossil status” output or in the editor text generated by the interactive form of “fossil checkin”. I don’t use “fossil changes” at all. Deep svn muscle memory keeps me saying “f stat” instead. I made it standard in [fossil changes] and [fossil status]. See commit [03679b58]. Please give it a whirl and let me know if it satisfies. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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 changes] and execute/symlink flag changes
On 5/15/2015 12:02 AM, Andy Goth wrote: On 5/8/2015 1:13 PM, Warren Young wrote: On May 7, 2015, at 6:21 PM, Andy Goth andrew.m.g...@gmail.com wrote: My question is whether this extra level of reporting should be standard [fossil changes] behavior or only accessible if an extra option is supplied. My vote is to make it always report execute bit and symlink state changes. I’m in favor of the idea, but I’ll tell you this up front: I’ll never see the warning unless it appears in either “fossil status” output or in the editor text generated by the interactive form of “fossil checkin”. I don’t use “fossil changes” at all. Deep svn muscle memory keeps me saying “f stat” instead. I made it standard in [fossil changes] and [fossil status]. See commit [03679b58]. Please give it a whirl and let me know if it satisfies. Discovered a side effect. This reduces the need for the -allow-empty option to [fossil commit] since it is now aware of execute and symlink changes. -- Andy Goth | andrew.m.goth/at/gmail/dot/com 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
[fossil-users] Fossil check-ins [46675ed2] and [010451e7] (remove add access-check and andygoth-versioned-open merge)...
I am a fan of both of these changes. However, does everybody think they have had enough testing to be included in a release that is imminent? I just reviewed the changes again and I'm starting to think they are low risk enough to include in 1.33. Does anybody disagree? -- Joe Mistachkin ___ 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 error fossil knows nothing about: C20131_IR_At7_OpSystem_ProjectFile.fossil
Hi Martin, This was attempted but did not resolve the problem. Thanks for the contribution; the problem was bogus whitespace. May be you can set 'Gary_Gabriel_Dev' as the default user for this repo. $ fossil user default Gary_Gabriel_Dev - Gary Gabriel ___ 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 error fossil knows nothing about: C20131_IR_At7_OpSystem_ProjectFile.fossil
Hi Warren, Thanks for the excellent explanations and helping me understand the problem. The syntax error was a good catch. This was right on. There was bogus whitespace in the user name that the query with 'fossil sqlite' rendered. Other comments follow. The fact that the “default command fails even though “list” shows that user tells me you have a fairly serious problem, like a corrupted repository, or bogus whitespace in the user name. You could try saying “fossil ui” and seeing if you can fix it from the Admin page. If you’re feeling brave, “fossil sqlite” will open your repository in the SQLite shell. Then the output of “select * from user;” may be enlightening. Have you read the Schimpf book? http://www.fossil-scm.org/schimpf-book/doc/2ndEdition/fossilbook.pdf No not yet, I'll follow-up on your recommendation. Thanks for your efforts and time, I understand a lot more now and learned. - Gary Gabriel ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
