Re: [fossil-users] svn to fossil-scm migration
On Tue, Mar 15, 2011 at 2:51 PM, Richard Hipp d...@sqlite.org wrote: It should never crash, regardless of any model differences. What version of Fossil are you running? (What does fossil version say?) Can you send me your repo by private email so that I can try it here and debug the problem? One, fossil version reports This is fossil version [1d93222627] 2011-03-01 19:04:32 UTC, downloaded from the fossil-scm.org site at 2011-03-12 09:23:15 UTC. Two, I would be happy to send the repository to you by private email. Well, more like a link to a file in a private email, since the fossil repo is about 425 MB (not MiB). If you are still interested in seeing a copy of the repo, let me know and I'll forward the required information. SDR ___ 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] svn to fossil-scm migration
When I said very different models I meant different models of usage between a centralized vs distributed vcs. And I was right! :) In any case, glad the repo was useful to you to in improving fossil. Rather than trying to dump my entire centralized repo into a single distributed repo, I'll have to try breaking it into separate projects. Still trying to get my head around the dvcs model. I've heard people going on and on about how great dvcs systems are, but I just haven't been able to see it from their perspective. The selling point to me about fossil is the integration of bug tracking wiki all those other goodies that I currently have to maintain separately. Svn Trac are a nice cooperative pair, but I really like the idea of a single exe along with a single repository file. I'd better stop rambling. Thanks again for your immediate attention to the report and the fix. Take care. SDR On Tue, Mar 15, 2011 at 6:39 PM, Richard Hipp d...@sqlite.org wrote: On Tue, Mar 15, 2011 at 4:00 PM, Scott Robison sc...@scottrobison.us wrote: I fear that my problem is probably likely due to the very different models between svn fossil (or maybe a less than perfect conversion utility). My svn repo resembles: \repo \trunk \projects \vendor \third-party-libraries \vendor \third-party-libraryies \tag-1 \tag-2 \tag-3 \current Is there a better way to do what I'm trying to do, or should I give up on the 'ideal' of keeping my subversion history in the new fossil repository? Also: is it practical to try to maintain multiple projects in a single repository as I'm trying to do, or should I give that up and go for a single repo per project? Thanks for sending your repo! It is quite interesting. The tip of trunk contains 446,786 different files in 37,217 directories, including: * Complete sources to 5 different versions of Python * Complete sources to 15 different versions of SQLite * Complete sources to 8 different versions of Boost * Complete sources to 4 different versions of Tcl and of Tk * Complete sources and data files to 8 different versions of ICU * Plus multiple versions of 11 other vendor libraries... A complete checkout is 5.7GB. Fossil should not segfault, and I will fix that problem. But in the meantime, I have these recommendations: (1) Keep vendor libraries in separate repositories - one repo per library. (2) If you really need to keep vendor libraries in your own repository, use the versioning system to store different versions of the vendor libraries as different check-ins. Do not create separate subdirectories storing different versions of the same library all within the same check-in. It's a versioning system, not a filesystem. Thanks for any suggestions guidance. I really want to like fossil but am having 'growing pains' or 'migration pains'. SDR ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Commit question
I believe Ctrl-Z is defined as EOF in ASCII which predates Microsoft. Terminating text files with EOF was the solution employeed by CP/M because file sizes were a sector count instead of a byte count. On Apr 5, 2011 3:06 PM, Ron Wilson ronw.m...@gmail.com wrote: On Tue, Apr 5, 2011 at 3:49 PM, Remigiusz Modrzejewski l...@maxnet.org.pl wrote: On Apr 4, 2011, at 22:55 , Stephan Beal wrote: On a related note: some tools (like cvs or svn) warn if a file's last line has no end-of-line marker. That's because (as i was taught, anyway) the official definition of a text file is basically variable-length records separated by a record separator (an end-of-line sequence (\n on *nix, \r\n on Windows)), and that the last record must also have such a separator. Actually, this way the definition says that the last line can not have a \n. You probably wanted to write ended by a record separator, but then the word separator is misleading ;) I recall it being defined as variable length records, each ending with a record terminator, which was, because of the way teletype machine worked, CR-LF. (Though, with the real machine, LF-CR had the same end result.) Interestingly, Microsoft choose control-Z as end-of-file, rather than any of the other defined control values that might have been better. My guess is that that was because Z is the last letter of the alphabet, and Z being closest to the lower left corner of the keyboard. ___ 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] Commit question
Ah, thank you. I am on the road with barely enough bandwidth to email. At least I was smart enough to give myself an out with I believe instead of stating it as solid fact. :) SDR On Apr 5, 2011 6:48 PM, Ross Berteig r...@cheshireeng.com wrote: At 06:37 PM 4/5/2011, Scott Robinson wrote: I believe Ctrl-Z is defined as EOF in ASCII... In ASCII, Ctrl+Z is SUB, intended to substitute for a damaged character read from tape or received in a channel. ASCII did not define a specific end of file code. The closest are Ctrl+C aka ETX for End of Transmission, and Ctrl+D aka EOT for End of Text. Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ 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] crnl-setting bug
On Thu, Apr 7, 2011 at 1:16 PM, Scott Robison sc...@scottrobison.us wrote: I believe the glob-style wildcard pattern matching is being performed by mingw during program startup before handing control over to main (because cmd.exe does not do wildcard expansion itself in either Windows 7 or XP). Bah, stupid gmail (or stupid user of gmail). Anyway, if you type fossil setting crnl-glob * at a command prompt in an empty directory (no expansion opportunity for *) you get a different result than if you type that command in a non-empty directory (where * is expanded into the list of entries in the current directory). The mingw startup code is emulating the behavior one expects from a posix environment. SDR ___ 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] crnl-setting bug
On Thu, Apr 7, 2011 at 1:24 PM, Ron Wilson ronw.m...@gmail.com wrote: On Thu, Apr 7, 2011 at 3:16 PM, Scott Robison sc...@scottrobison.us wrote: I believe the glob-style wildcard pattern matching is being performed by mingw during program startup before handing control over to main (because cmd.exe does not do wildcard expansion itself in either Windows 7 or XP). And, I would guess that cmd.exe is stripping off the s. So, maybe: fossil setting crnl-glob '*' would work. After cmd.exe strips off the s, 's would still be there to protect the * from mingw. Ah, excellent point. cmd.exe strips quotes so that there is a way to embed separator characters such as space in a command line argument. In any case, I just tested and it appears that using single quotes instead of double quotes is sufficient to get the asterisk through the command line processing software stack. SDR ___ 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] crnl-setting bug
On Thu, Apr 7, 2011 at 2:44 PM, Wilson, Ronald rwils...@harris.com wrote: Confirmed. Single quotes work on Win7. Actually, single quotes don't work either because the single quotes get preserved in fossil: According to http://gnuwin32.sourceforge.net/compile.html: Filename globbing Wildcards on the command-line are expanded by the command-line interpreter. If you wish to disable this filename globbing, then add int _CRT_glob = 0; to the beginning of the main program file. Perhaps this will be necessary for Windows builds. SDR ___ 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] [vb.net] Which files/folders can be safely ignored?
I think it's more a question of how you're using fossil. If you are using it for an actual distributed project, then you probably don't (or at least might not want) to include suo files. If you are using it just for vcs as a solo developer, there is no technical reason not to include the suo file. SDR On Mon, Oct 3, 2011 at 9:46 AM, Tomek Kott tkott.s...@gmail.com wrote: The way I see it, you don't want the user options travelling between different users, since they're user options. I don't believe they set anything important for the solution itself. At least, that's how I understand it. Tomek On Mon, Oct 3, 2011 at 11:33 AM, tpero...@compumation.com tpero...@compumation.com wrote: I also ignore the obj folder. All those files get rebuilt anyway. You might want to keep the suo file: What is an suo file? Tony Perovic Compumation, Inc. From: fossil-users-boun...@lists.fossil-scm.org [mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Tomek Kott Sent: Monday, October 03, 2011 9:56 AM To: fossil-users@lists.fossil-scm.org Subject: Re: [fossil-users] [vb.net] Which files/folders can be safely ignored? for C++ projects based in VS2008/10, I have the following ignore glob, which seems to work pretty well: *.vcxproj.user,*Debug/*,*.suo Probably you can replace vcx with vb. Of course, YMMV. I ignore the debug folders since these are used when building, and I assume I can just build things again to get back the exe from the source. Hope that helps, Tomek On Mon, Oct 3, 2011 at 9:59 AM, Gilles gilles.gana...@free.fr wrote: Hello I'd like to start using Fossil to monitor Vb.Net (2008 Express) projects, and need to know which files/folders I can safely ignore when using the add command. FWIW, here's a one form + one module project: Directory of C:\Projects\MyApp\WindowsApplication1 03/10/2011 15:04 3.040 Form1.Designer.vb 03/10/2011 15:04 5.814 Form1.resx 03/10/2011 15:08 2.903 Form1.vb 03/10/2011 13:40 194 Module1.vb 03/10/2011 13:36 DIR bin 03/10/2011 13:36 DIR My Project 03/10/2011 13:36 DIR obj 03/10/2011 13:36 934 WindowsApplication1.sln 03/10/2011 13:36 5.678 WindowsApplication1.vbproj 03/10/2011 13:36 74 WindowsApplication1.vbproj.user Directory of C:\Projects\MyApp\WindowsApplication1\bin\Debug 03/10/2011 15:08 27.648 WindowsApplication1.exe 03/10/2011 15:08 58.880 WindowsApplication1.pdb 03/10/2011 15:08 14.328 WindowsApplication1.vshost.exe 03/10/2011 15:08 127 WindowsApplication1.xml Directory of C:\Projects\MyApp\WindowsApplication1\bin\Release 0 File(s) 0 bytes Directory of C:\Projects\MyApp\WindowsApplication1\My Project 03/10/2011 02:51 1.522 Application.Designer.vb 03/10/2011 02:51 510 Application.myapp 03/10/2011 02:51 1.199 AssemblyInfo.vb 03/10/2011 02:51 2.807 Resources.Designer.vb 30/07/2008 06:54 5.612 Resources.resx 03/10/2011 02:51 3.058 Settings.Designer.vb 30/07/2008 06:54 279 Settings.settings 7 File(s) 14.987 bytes Directory of C:\Projects\MyApp\WindowsApplication1\obj\Debug 03/10/2011 10:56 6.069 ResolveAssemblyReference.cache 03/10/2011 13:36 DIR TempPE 03/10/2011 15:08 27.648 WindowsApplication1.exe 03/10/2011 15:04 180 WindowsApplication1.Form1.resources 03/10/2011 14:30 180 WindowsApplication1.Form2.resources 03/10/2011 15:08 58.880 WindowsApplication1.pdb 03/10/2011 13:40 180 WindowsApplication1.Resources.resources 03/10/2011 15:08 2.764 WindowsApplication1.vbproj.FileListAbsolute.txt 03/10/2011 15:04 905 WindowsApplication1.vbproj.GenerateResource.Cache 03/10/2011 15:08 127 WindowsApplication1.xml 9 File(s) 96.933 bytes Directory of C:\Projects\MyApp\WindowsApplication1\obj\Debug\TempPE 03/10/2011 13:02 7.680 My Project.Resources.Designer.vb.dll 1 File(s) 7.680 bytes Directory of C:\Projects\MyApp\WindowsApplication1\obj\Release 0 File(s) 0 bytes Thank you. ___ 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 mailing list fossil-users@lists.fossil-scm.org
Re: [fossil-users] Trac-to-Fossil Was: Wysiwyg wiki editing. Was: Side-by-side wiki editing?
On 15 May 2012 03:01, Ron Wilson ronw.m...@gmail.com wrote: Trac's versioning for wiki and issues is native to Trac, and is used solely for the wiki and issues. The version control of the source for a project is entirely separate. Trac does not use your source control choice for issues or wiki. Though as I recall, the (default at least) database is SQLite. :) ___ 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] losing history in private branch merge?
On Fri, May 25, 2012 at 12:26 PM, Nolan Darilek no...@thewordnerd.info wrote: Shame, I actually kind of liked that individual commits were preserved. Squashing and such was part of why I left Git. History should be preserved, whether you are working alone in private or in the open. History is preserved in your private branch for your private perusal, isn't it? To borrow some C++ lingo, it sounds like what you're looking for might be better called a 'protected' branch. Or if necessary disable auto-sync and publicly branch until you're done with it, optionally on another clone of the repository. Or probably other things I can't think of at the moment. The desired functionality is there, just not the way you were expecting it, probably. Note: I don't mean for the above to come off terse or rude or condescendingly. Just observing some other possible solutions that haven't been mentioned yet that will publicly preserve history in a way that works with the existing system. SDR ___ 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] source code file is considered by fossil to be binary.
It might be better (more portable) to escape those as octal or hex sequences (like '\002' or '\x02'). On Jun 24, 2012 3:11 PM, James Bremner ravenspo...@yahoo.com wrote: Richard Hipp drh@... writes: In your case there is a Ctrl-B (ascii 0x02) in the 2150th byte of the file, which makes Fossil think it is a binary file. Thank you for clarifying this mystery. FYI: ascii 0x02 is STX = Start of Text It is used by many devices that communicate over RS232 to demark the beginning if a message. This code is used to parse messages from such devices and so the character is sprinkled all through it. Other such codes freuently used are: 1 001 01 0001SOH Start of Heading 2 002 02 0010STX Start of Text 3 003 03 0011ETX End of Text 4 004 04 0100EOT End of Transmission James ___ 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] Fossil 1.23
I downloaded the lastest Windows fossil build tonight and am giving DVCS another shot. Some notes: 1. I like the fact that I could --date-override the initial create date stamp. 1a. I wish that I could --date-override a commit at the command line so that I didn't have to edit the date stamp via the web interface later. 1b. If you don't type the date stamp format just right, fossil will crash trying to display the time line in the web interface. In my case I typed 8:12:23 instead of 08:12:23 for the edited time, omitting the leading 0. 2. I am color blind. The color coding of bullet points in the Edit User pages explaining which marks indicate what is practically worthless to me (I spent a while staring at them trying to figure out what the difference was; I'm not complaining, it's just my burden, and I'm fortunately to not have worse burdens, really). I mention this only as a usability issue for someone to consider. I really don't know what would be better, and hate to be one of those people that sounds like accommodate my disability even though it works for most people just fine! Some obvious alternatives that pop into my head are to use multiple bullet shapes instead of just color coding the same shape or to use subscript or superscript digits or some such. 3. I would be happy to take a stab at modifying the source to implement the stuff above, and I understand there is some sort of copyright assignment or waiver form to be filled out... If someone could forward that my way I would appreciate it. SDR ___ 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 1.23
Ah, then perhaps my first edit will be to document the undocumented rather than implement the unimplemented. :) To answer your question, yes I am converting a smallish multipurpose svn repository I've been using for about three years. It has multiple projects in it that I don't want to all migrate to a single fossil repo, so this exercise has two benefits for me. One, it allows me to cherry pick (as it were) which svn sub-trees to move into each fossil repo. Two, it gives me a little artificial early experience using fossil to build up the new repo mostly like I would have over the last few years. As for the color coding, I was not referring to branch colors, I was referring to colors used to highlight bullet characters in an admin/config page. For me it is especially hard to see the color changes that only apply to occasional foreground characters. It is information I can get elsewhere, but making and submitting a change to modify the character as well as color seemed like a potentially useful little project not just for me but for the community as well (or at least the color blind subset of the community). Thanks for the info! SDR On Aug 25, 2012 2:57 AM, Rene renew...@xs4all.nl wrote: On 2012-08-25 09:47, Scott Robison wrote: I downloaded the lastest Windows fossil build tonight and am giving DVCS another shot. Some notes: 1. I like the fact that I could --date-override the initial create date stamp. 1a. I wish that I could --date-override a commit at the command line so that I didn't have to edit the date stamp via the web interface later. 1b. If you don't type the date stamp format just right, fossil will crash trying to display the time line in the web interface. In my case I typed 8:12:23 instead of 08:12:23 for the edited time, omitting the leading 0. 2. I am color blind. The color coding of bullet points in the Edit User pages explaining which marks indicate what is practically worthless to me (I spent a while staring at them trying to figure out what the difference was; I'm not complaining, it's just my burden, and I'm fortunately to not have worse burdens, really). I mention this only as a usability issue for someone to consider. I really don't know what would be better, and hate to be one of those people that sounds like accommodate my disability even though it works for most people just fine! Some obvious alternatives that pop into my head are to use multiple bullet shapes instead of just color coding the same shape or to use subscript or superscript digits or some such. 3. I would be happy to take a stab at modifying the source to implement the stuff above, and I understand there is some sort of copyright assignment or waiver form to be filled out... If someone could forward that my way I would appreciate it. SDR There is a non documented option to commit to override date and user --date-override --user-override Why do you want to override the date? Are you converting a repository? What the colour coding does is, in de case of multiple branches, is that a commit square gets the same colour as the comment The left side is always the trunk. E.g. [ ] These are on the trunk and has no colour | | | [g] This text has the colour green | | | | | | | [p] This text has the colour purple It is helpful aid to see on which branch activity is going on. But you can get that information also by looking at the squares. Maybe we could number or symbolise the branches in addition to the colouring like 2012-08-24 | 14:50 | [2] 2 [b4ea94b488] Leaf: merge unicode branch (user: jan.nijtmans, tags: eclipse-project) | /| | / | | / | |/ | 13:42 | [3] |3 [c780793749] Leaf: add mkdir to the unicode-supported functions add chinese-named file and | || directory in test directory, demonstrating the fix (user: jan.nijtmans, tags: unicode) | || 13:15 | [3] |3 [d8e1431fc0] Better support for unicode filenames on Win32 (Not tested on | || other platforms yet, will not work!) (user: jan.nijtmans, tags: unicode) | || | / | | / | |/ | 08:16 +---[2] 2 [abbc00fc5b] Merge in the mingw build enhancements (user: jan.nijtmans, || tags: eclipse-project) 08:13 [1] |1 [4e93e84e55] wiki tweaks regarding MinGW build enhancements || || 05:56 [1] |1 [02bff595e1] One more minor Win32 || 2012-08-23 || I'm not sure if that would be of real value to you? -- Rene __**_ fossil-users mailing list fossil-users@lists.fossil-scm.**org fossil-users@lists.fossil-scm.org http
Re: [fossil-users] Fossil 1.23
Thanks for the info. I was going to tackle that myself today so that I could get that benefit, and appreciate the pointers. Of course, submitting it (along with eventual paperwork) gives me 'practical experience' with pushing stuff back to a master repo (where my current personal project needs won't involve much or any of the d in dvcs) and the warm fuzzy of contributing to the project in some small way. SDR On Aug 25, 2012 3:17 AM, Francis Daly fran...@daoine.org wrote: On Sat, Aug 25, 2012 at 01:47:44AM -0600, Scott Robison wrote: Hi there, 2. I am color blind. The color coding of bullet points in the Edit User pages explaining which marks indicate what is practically worthless to me I think that is, fossil ui in an open checkout, then in the browser click Admin, Users, then the specific User ID, to get to a url very like http://localhost:8080/setup_uedit?id=1 Some obvious alternatives that pop into my head are to use multiple bullet shapes instead of just color coding the same shape or to use subscript or superscript digits or some such. If it's the page mentioned above, then the source code is in src/setup.c. Look for the word ueditInheritDeveloper (in two places) and change bull; after it to, say, loz; in the first place, and loz; in the second. (There's an extra space in the first one, to make it display clearer.) Then do something very similar for ueditInheritReader, ueditInheritAnonymous, and ueditInheritNobody -- perhaps dagger;, Dagger;, and leave the other one as bull;? Then rebuild and test that the changes (a) break nothing; and (b) improve something. And then use that as your version of fossil. 3. I would be happy to take a stab at modifying the source to implement the stuff above, and I understand there is some sort of copyright assignment or waiver form to be filled out... You can do what you like with your version of the code. The copyright form is for when you wish to have your changes included in the main repository. And the specific change above is a local display one, so you can get the benefit today and worry about the paperwork later ;-) Cheers, f -- Francis Dalyfran...@daoine.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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil 1.23
I'm not much of a visual/ui design guy but I'll see what I can come up with. SDR On Aug 25, 2012 9:09 AM, Richard Hipp d...@sqlite.org wrote: On Sat, Aug 25, 2012 at 10:25 AM, Scott Robison sc...@scottrobison.uswrote: As for the color coding, I was not referring to branch colors, I was referring to colors used to highlight bullet characters in an admin/config page. That whole colored-dot thing on the users page is hokey and needs to be completely reworked. The page needs to be redesigned from the ground up. I just haven't done so yet because it is a seldom-used page and I've been distracted with more pressing issues. You are welcomed to give it a go. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to save typing when checking out branches with long names?
Just throwing out a couple of ideas: fossil globco 154 Or perhaps slightly less bad: fossil co --glob 154 Though I'm not personally looking for this functionality myself so not having it as an official feature doesn't bother me. SDR On Mon, Aug 27, 2012 at 11:00 AM, Richard Hipp d...@sqlite.org wrote: On Mon, Aug 27, 2012 at 12:35 PM, Stephan Beal sgb...@googlemail.comwrote: On Mon, Aug 27, 2012 at 6:07 PM, v...@lavabit.com wrote: I'd be very happy if I could just type: $ fossil co vim-7.3.154 I'd be even happier if I could just type: $ fossil co 154 Not to sound too pessimistic, but... Yeah. I can't quite put my finger on why, but something just feels wrong about doing prefix matching against tag names. I wouldn't be that hard to implement, actually (thanks to having SQLite with a GLOB operator as the storage engine) but I'm questioning the wisdom of doing so. You're really going to need to sell this proposal if you want it to get into the tree. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How to save typing when checking out branches with long names?
The essence of my suggestion was to not do it by default but to provide a simple way for the user to say yes, I really want you to search for this substring anywhere rather than forcing it on everyone. SDR On Mon, Aug 27, 2012 at 11:24 AM, Stephan Beal sgb...@googlemail.comwrote: On Mon, Aug 27, 2012 at 7:18 PM, Scott Robison sc...@scottrobison.uswrote: fossil co --glob 154 Though I'm not personally looking for this functionality myself so not having it as an official feature doesn't bother me. FWIW: as Richard said, it's _technically_ easy, but brings with it both philosophical and usability concerns. Fossil would need a way of allowing the user to disambiguate, e.g.: possible matches: 1) ... 2) ... type number to continue... and that type of feature would then arguably need to be added to other commands which deal with branches/tags. IMO a custom shell-based solution is the proper place for this. If it can be demonstrated that this is feasible, i'll stop being pessimistic about it ;). i suspect, however, that any attempt at doing so would reveal worms which haven't yet been mentioned. -- - 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] Support for Win9x?
Even if someone is still supporting Win9X, it does not necessarily follow that they are doing anything more that testing binaries in that environment. I would not be heartbroken if such support were removed. SDR On Sep 13, 2012 8:25 AM, Jan Danielsson jan.m.daniels...@gmail.com wrote: On 09/13/12 16:02, Richard Hipp wrote: Is there any reason to try to keep Fossil working on windows9x? I don't think much Win9x development goes on today. But even if I'm wrong, I would guess that the intersection between the sets Win9X developers and Fossil users is roughly empty. Tag last win95-compatible version so anyone so inclined can dig it up easily, just in case? -- Kind regards, Jan Danielsson ___ 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] Fossil enhancement idea. Was: trouble handling text files from SQL Server 2012
I'd like to assist with that contribution. Assuming someone hasn't already done it by the time I click send. :) SDR On Thu, Sep 13, 2012 at 2:08 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 13, 2012 at 3:45 PM, Richard Hipp d...@sqlite.org wrote: On Thu, Sep 13, 2012 at 3:43 PM, Kevin Greiner grein...@gmail.comwrote: I'm using fossil 1.23 on Windows 7. I'm attempting to store text files generated by Microsoft SQL Server 2012 in fossil so I can easily track their changes over time. The problem is that fossil thinks these generated text files are binary data which prevents me from viewing the files via the web ui and generating diffs. When I look at these files in a hex edtor, I see this: ff fe 53 00 45 00 54 00 20 00 41 00. A text editor shows SET A. I've looked in the email list archive where DRH specifies that a null character or a line longer than 8192 chars. The entire file is 1074 bytes so it's not the length. Is fossil reading the 00 bytes as nulls? Any idea why fossil thinks these files are binary? And, more importantly, what encoding I can specify to prevent this? I've tried various permutations of ASCII, UTF8, UTF7 to no effect. The file itself appears to be in utf16le. The diff facilities in Fossil currently only know how to deal with utf8. It would be an interesting project to enhance Fossil so that it could support UTF16 in addition to UTF8. What would be needed is an algorithm to detect when a file was UTF16. (The BOM at the beginning of Kevin's example ought to be a big hint.) Then automatically call a convert routine to generate UTF8 prior to passing the content into the diff logic, or into the wiki engine, or prior to display on the UTF8 webpage, etc. Basically, we need a routine that converts an in-memory buffer from UTF16 to UTF8, and leaves anything that isn't UTF16 unchanged. Then we need to call that routine in a few strategic places inside of Fossil Volunteers to write that routine? I'll help identify the places where it needs to be called. Thanks, Kevin ___ 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 -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil enhancement idea. Was: trouble handling text files from SQL Server 2012
I assumed (dangerous though it may be) that leaves anything that isn't
UTF-16 unchanged meant don't convert any buffer to UTF-8 if the
origination buffer is not UTF-16.
SDR
On Thu, Sep 13, 2012 at 5:04 PM, David Given d...@cowlark.com wrote:
On 13/09/12 21:08, Richard Hipp wrote:
[...]
Basically, we need a routine that converts an in-memory buffer from
UTF16 to UTF8, and leaves anything that isn't UTF16 unchanged. Then we
need to call that routine in a few strategic places inside of Fossil
Could you clarify what you mean by 'leaves anything that isn't UTF-16
unchanged'? Do you mean you just want it to convert up until the point
where it finds non-well-formed UTF-16 and then tells you where it
stopped, or do you actually want to leave the unconverted UTF-16 in the
output file? Because that last will just produce gibberish ---
non-well-formed UTF-8.
The standard way to do all these conversions is just to call out to
iconv, which handles all the horrible edge cases. It is available for
Windows, but it's not small.
OTOH if you don't care about the edge cases, converting well-formed
UTF-16 to UTF-8 is lossless and pretty straightforward.
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│
│ life←{ ↑1 ⍵∨.^3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ }
│ --- Conway's Game Of Life, in one line of APL
___
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] Fossil enhancement idea. Was: trouble handling text files from SQL Server 2012
So I've spent some time writing a small and I think portable routine to detect if a buffer is a valid UTF-16 (either little or big endian). It rejects buffers if they contain an odd number of bytes or contain any of the 66 non-character code-points or have invalid surrogate usage. While this seems to work well on the handful of binary files I've tested it against, I'm curious as to whether it would be desired to additionally use some or all of the current binary file detection criteria? My thought being that a file could be perfectly valid UTF-16 but have an extremely long line or (worse in my opinion) embedded non-text characters (particularly U+ or non-white-space control codes). SDR On Thu, Sep 13, 2012 at 6:07 PM, Richard Hipp d...@sqlite.org wrote: You assume correctly. The use of iconv won't do, though, since everything also needs to work on Unix. There are small, portable conversion routines in SQLite that you can copy. D. Richard Hipp - d...@sqlite.org Sent from phone - pardon brevity On Sep 13, 2012 7:44 PM, Scott Robison sc...@scottrobison.us wrote: I assumed (dangerous though it may be) that leaves anything that isn't UTF-16 unchanged meant don't convert any buffer to UTF-8 if the origination buffer is not UTF-16. SDR On Thu, Sep 13, 2012 at 5:04 PM, David Given d...@cowlark.com wrote: On 13/09/12 21:08, Richard Hipp wrote: [...] Basically, we need a routine that converts an... ___ fossil-users mailing list fossil-users@lists.f... ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Fossil enhancement idea. Was: trouble handling text files from SQL Server 2012
On Fri, Sep 14, 2012 at 5:46 AM, Richard Hipp d...@sqlite.org wrote: Detection of embedded non-printing characters, especially U+, would be nice. Should we insist on a BOM at the beginning of the file? I don't think a BOM should be mandatory, as it is not required by Unicode. Another thought: Unicode characters have a General Category. The categories Letter, Mark, Number, Punctuation, Symbol Separator are obviously useful in the context of Unicode encoded text files. That leaves the Other categories: 1. Other, control: Some of these are useful in the context of text files (tab, CR, LF, FF among others which are used to format text). Some not so much. I'd think however fossil currently classifies such characters in 8-bit text is how they should be treated for Unicode. 2. Other, format: I believe these should be included even though I think they'd be rare in the types of files fossil would need to diff. 3. Other, surrogate: If these appear in an invalid context in a document it is not well formed UTF-16. 4. Other, not assigned [Noncharacter]: If these appear anywhere in a document it is not well formed UTF-16. 5. Other, private use: Should we allow these in a file that fossil might diff? Since they are private-use there is no 'standard' way of displaying them, but people may legitimately want or need them in their private documents. 6. Other, not assigned [Reserved]: These are perfect valid code points, and over time more of them will be allocated to other categories. We can either allow them knowing they won't be displayable now but might be later or restrict them until some future time. Either way the code has to be kept up to date with future Unicode revisions, as a new code could be allocated to a printable character or (theoretically) to a non-printable control code. I'm assuming the desire for identifying UTF-16 and converting to UTF-8 is *only* for the purposes of recognizing them as diffable text vs binary files (though you might also want to use this to identify a file as Unicode text vs 8-bit text vs binary when adding them to the repository). If the first thought is correct, it would be possible to expand normally non-printable characters into printable sequences in otherwise valid UTF-16 buffers. For example: Let's say a line of text in a file has an embedded backspace character (U+0008). We could say it is not a text file for that reason or we could expand the normally non-printing backspace into literal text U+0008. That might be more valuable in the context of diffing files, and it causes no harm in that the file as stored in the file system or the repository remains unchanged. Hopefully I'm not rambling and these thoughts are sufficiently coherent as to make sense... SDR ___ 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 enhancement idea. Was: trouble handling text files from SQL Server 2012
On Fri, Sep 14, 2012 at 8:20 PM, Csaba Kos csaba@gmail.com wrote: I think now would be a good time to discuss the possibility of a more generic text conversion framework, i.e. not only UTF16 to UTF8 but also SHIFT-JIS to UTF8, and so on. Also CR+NL to NL conversion could be handled by such framework as well. One possibility is to support calling of an external command which could be specified in some ...-glob setting. I'm not a git user, but as far as I know, git has a generic text filtering framework that is capable of the above. One thing I thought of yesterday but dismissed (and am now rethinking as a result of your email) is maybe there should be a bit of meta-data that can be attached to files to explicitly set their encoding. Having built in detection code would still be useful to set it initially, and having it as meta-data could make it possible for the user to change the encoding of the file when fossil guessed wrong for whatever reason. A similar bit of functionality could be provided for end of line handling. Regardless, I am a fossil novice myself, so maybe that functionality is there and I am just ignorant of it. Regardless, having some basic UTF-16 to UTF-8 conversion built in is helpful in advancing the goal of providing base functionality that is available on all platforms without need to install or configure extra tools. It would certainly be cool to provide some sort of hook to access external tools that could handle transcoding from more encodings as needed. Maybe options to build with ICU (much as SQLite provides) could provide what you're describing for those that want it, and in the case that ICU is not available, built in diffing is limited to those base supported encodings... SDR ___ 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 enhancement idea. Was: trouble handling text files from SQL Server 2012
On Fri, Sep 14, 2012 at 11:34 PM, Csaba Kos csaba@gmail.com wrote: I am a fossil novice myself, but I don't think there is such functionality built-in currently. I was talking about tagging encoding as well as end of line handling, but mainly I was giving myself an out in case I was speaking in favor of something that already exists. :) My plan for the EOL conversion was to extend the syntax of the crnl-glob setting in the following way: *.txt:cr force CR *.txt:nl force NL *.txt:cr+nlforce CR+NL *.txt:native convert to native format anything else: allow CR+NL (current behaviour) But I agree that properties attached to files (similarly to subversion, perhaps) might be preferable for setting the encoding/line ending. That was my thought as well. SDR ___ 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] Latest stable release or dev release does not compile with option: --static
While I agree that the -Dstrcmp... solution is inadequate, strcmp is subject to the system locale setting. While it might default to the C locale (giving the expected binary comparison behavior), it might not. One may not consider locale the same as localization, but whatever you choose to call it, it can result in non-deterministic behavior based on the exact system configuration. SDR On Wed, Jan 30, 2013 at 8:19 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2013/1/30 Sergei Gavrikov sergei.gavri...@gmail.com: [FYI] An optimized (-O2) default build with entered substitution -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux ... Program received signal SIGSEGV, Segmentation fault. ... Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp before including string.h, and strcmp has a decoration that its arguments are non-null, that is used by the optimizer to remove the two first if's from the fossil_strcmp function: if its arguments cannot be NULL, that's a valid optimization Should be fixed now, by #undef'fing fossil_strcmp in printf.c I'm uncomfortable with this change. If we need to use fossil_strcmp() everywhere (which surprises me, since strcmp() should *not* be subject to localization) then we should do so explicitly, and not depend on preprocessor magic, as the preprocessor magic will likely cause maintenance headaches down the road, and/or introduce subtle bugs such as the above. Many 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 -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Latest stable release or dev release does not compile with option: --static
And never mind, I guess I was wrong. Not sure why I couldn't have checked that *before* clicking send, but c'est la vie. SDR On Wed, Jan 30, 2013 at 8:19 AM, Richard Hipp d...@sqlite.org wrote: On Wed, Jan 30, 2013 at 8:11 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote: 2013/1/30 Sergei Gavrikov sergei.gavri...@gmail.com: [FYI] An optimized (-O2) default build with entered substitution -Dstrcmp=fossil_strcmp fails (SIGSEG) on i686 GNU/Linux ... Program received signal SIGSEGV, Segmentation fault. ... Thanks! That's fully explainable: When setting -Dstrcmp=fossil_strcmp before including string.h, and strcmp has a decoration that its arguments are non-null, that is used by the optimizer to remove the two first if's from the fossil_strcmp function: if its arguments cannot be NULL, that's a valid optimization Should be fixed now, by #undef'fing fossil_strcmp in printf.c I'm uncomfortable with this change. If we need to use fossil_strcmp() everywhere (which surprises me, since strcmp() should *not* be subject to localization) then we should do so explicitly, and not depend on preprocessor magic, as the preprocessor magic will likely cause maintenance headaches down the road, and/or introduce subtle bugs such as the above. Many 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 -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Automation
My apologies if this is too long for reading, but I hope you'll bear with me. I like the idea behind chiselapp, but am paranoid so I want to host something similar for myself (and just myself) to keep things private. I downloaded chiselapp and while it *could* work, I decided it was more than I really needed, plus it is Apache centric and I run lighttpd. I have ported configuration files from apache to lighttpd in the past, but just didn't want to bother with it in this case. To that end, I've started creating a few basic scripts to give me a front end to fossil from a protected webpage on a secured server. I have a directory with an index.php which enumerates a directory full of fossils and gives me simple links to each fossil. I have a two line fossil cgi script that gives me access to those repos. I've even created a little page to allow me to change a password for a single user across all repos at one time. My next goal is to script the creation of a new repository. I have the basics down, in that I can easily use a form to get the needed command line parameters and run a script to create the new repo. I'd like to go a little further with it and set the project name description, default permissions, and so on. It does not appear there is a command line based way to set certain configuration options. I've dumped repos with sqlite3 repo.fossil .dump to see how certain things work. To accomplish my goal: 1. Is there a fossil command line based way to set config options (particularly project name and description) that I'm unaware of? 2. If there is not, is this something that could be done with the json api via cli as it exists today? 3. If the json api is not an option at present, what is the significance of the mtime field in the config table? Must it be set to some particular valid value or would an initial value of 0 be okay. If that is the case (or the proper default value is easily obtained / computed) I could easily just use a little SQL to set the needed config table values. FWIW, this is very plain looking stuff (I'm not a web guy at all) but I'd be happy to share the scripts and such when I'm finished. Probably the most useful part is just the scripts in the directory that give a front end that enumerates the existing repositories. -- Scott Robison ___ 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] Automation
On Fri, May 9, 2014 at 1:21 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 9:15 AM, Scott Robison sc...@casaderobison.com wrote: links to each fossil. I have a two line fossil cgi script that gives me access to those repos. I've even created a little page to allow me to change a password for a single user across all repos at one time. Would you mind sharing that one with us? The fossil cgi script is just based on the one documented elsewhere, so I assume you mean the password change script. You can see it at http://tny.cz/2376d7fa (tinypaste, tny.cz). When the page is accessed via http GET it just displays the page and any optional message that might have been passed as a url parameter. When the info is filled in and the form is POSTed, it does basic validation of the username and passwords. If all is okay, it uses a foreach loop to enumerate all the fossil files in the hard coded directory, runs the fossil command to change the password for the given user on each, and redirects back to the main index with a message. If it detects errors with the username or password, it redirects back to itself with simple messages to give the user a chance to do it again. As I said in my original message, I'm not a web guy, so this is definitely not professional grade. It lives behind a protected directory so I'm the only one with access to it, so robustness and aesthetically pleasing were not my primary considerations. Just something to help automate some things that I continually have to look up whenever I need to do them. If I were looking for a place to host something open source, I'd just go to chiselapp (or expose a repository via a specific unprotected url). In my case: http://www.webducky.com/dev/ - run a front end index script to provide a menu of all the fossils .../dev/project - bash script to set the home environment variable and then... .../dev/fossil-cgi - fossil cgi script. It could be named project directly, but the settings don't work unless the home directory is set first, and this was the easiest way for me to figure out how to do it. .../dev/password.php - the below script linked to from /dev/ .../dev/blah.php - other scripts to be written / finished to create, rename, delete repos. Note there are no copyrights or licenses claimed in the code itself, as I didn't really intend to share it, though I don't mind sharing it. In any case, it is simple enough and non-strategic enough that consider I it public domain, so do with it what you will and realize there is no warranty (not that you could easily prove I was the one who provided it anyway, maybe I just found the link and am claiming it as my own creation). ;) Not nearly as useful or complex as SQLite, but hey, I'm not nearly as bright as DRH either. SDR ___ 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] Automation
On May 9, 2014 3:11 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 9:50 AM, Scott Robison sc...@casaderobison.com wrote: It doesn't need to be great - it'll just be for my own use. i've never gotten around to using the login group support. I looked briefly into it and it seemed that the shared login group stuff only allowed read access to subordinant repos, so I just decided to build a very basic solution that met my modest needs. :) SDR ___ 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] Location of .fossil Database
On May 21, 2014 9:34 AM, Igor de Oliveira Couto i...@semperuna.com wrote: Dear Fossil Gurus, I'm a new user - have been using Fossil for just over a month now - and I'm loving it. One point that I found somewhat disappointing, is that Fossil creates a .fossil database in my home directory. I know that many applications in Linux/Unix store their preferences and settings in dot-files, in the user's home directory - ie., ~/.myapp. This, however, is a Linux standard, and does not translate to other platforms. I see many other people have commented already, but in reading the thread there was one point I never saw raised. In the Mac OS (pre OSX) you pretty much had to write apps specifically for a Mac. OSX however is really two different systems in one: the native Mac system with lots of guidelines om how things are to be done, and a fairly standard POSIX platform underneath that can run a huge number of programs without modification. In this world, fossil is just another app using the posix layer, behaving just as any other similar app would behave. It is a shame that Windows doesn't natively support something similar out of the box, but it's origins and life cycle have *never* coincided with posix. Even so, you don't have to write full blown gui apps on Windows, you just have to use a different API if you want to support console mode. And if you want to support Windows, you either do that or require your app to be built with something like cygwin (which many posix apps do require). OSX however threw away the older Mac history when it decided to go the route of an open source kernel with proprietary stuff on top. In any case, while I can see why one would want a program to give their native platfom more attention, in this case fossil is really just a posix app that can be built like almost any other and run on OSX because it supports those types of apps. SDR ___ 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] Location of .fossil Database
BAH! How dare someone make my wordy points while I'm also making them! :) SDR ___ 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] Location of .fossil Database
On Wed, May 21, 2014 at 12:02 PM, Stephan Beal sgb...@googlemail.comwrote: i will most certainly attempt to remember that point the next time this comes up. It reduces the argument form Mac vs Windows vs *nix to POSIX vs non-POSIX, which is not only simpler to grasp and argue around, but is geeky enough to scare away casual listeners ;). For those who don't know, POSIX == Portable Operating System Interface, a series of standards which specify APIs for various system-level services. _Some_ APIs are specified by the core C specifications (fossil only explicitly relies on C89), but POSIX basically starts off at the points where C leaves the details platform-defined. As Scott points out, MS has had a not-very-POSIX-friendly past: And to some extent, why should it (have a friendly POSIX history)? Mac OS (pre OS-X) had just as bad (I would say worse, actually) POSIX history. The first POSIX standard was released in 1988, and the standardization efforts began around 1985 (according to the Wikipedia article). Both Windows Mac OS pre-date POSIX. Prior to that, there were as many operating system standards as there were brands and models of computers (or very nearly so). 1988 was the first time there existed an actual standard for a minimum set of interfaces that could be used portably between different systems that adhered to the standard. Even then, it is a *minimum* set of standards that a portable application could be written to target, but it is not a maximum set of interfaces. I would say that MSDOS came closer to supporting something that could be called Linux out of the box than Mac OS 9 earlier ever did. It was still a million miles away, so closer isn't saying much, but closer nonetheless, since it actually supported something resembling a terminal window and command line interface and command line oriented tools and Mac OS did not out of the box. OS-X was a brilliant move for them to make (which of course evolved from Apple's acquisition of Next and it's intellectual property). Use that, add shims to provide for backward compatibility (much as they did when they migrated from Motorola 68000 series chips to PowerPC chips), and viola! Something all your fans like that provides the power to move forward. Many people rail on Microsoft modern Windows for not being POSIX compliant, but really, what is the motivation? Early NT versions (early to mid 90s) *did* advertise POSIX compliance, though I don't think it ever shipped with the base system. At least not completely. There are system level APIs needed for POSIX, but there is also a whole host of userland utilities that must work a particular way to be truly POSIX. You could buy or download from Microsoft a bundle of software to bring it up to a full POSIX system if you wanted, but the history just wasn't there. All non-NT versions of Windows were effectively little more than an Xwindow server with a different API that ran on top of DOS. Because of the history, NT versions of Windows provided something that more closely resembled DOS than POSIX, while providing APIs for POSIX and OS/2 compatibility along side the native NT/Win32 APIs. Unix / POSIX has pretty successfully taken over the world of operating systems from virtually all other contenders (Amiga, BeOS, Commodore Kernal, etc, ad nauseum), with the single exception of Windows. Given the origins of Windows as a layer on top of DOS which was basically a CP/M knock off (which is fine, since Linux is really just a Unix knock off), it makes perfect sense why Microsoft doesn't feel the need to natively support POSIX. Mac OS-X supports it, but it would be disingenuous to say they advocate writing POSIX software; they want the whole world to be Mac centric. They just get POSIX support for free so they don't actively disable it. Yet. I say just give them time. ;) SDR ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] users table photo column
You may remember reading a few weeks back I've been playing around with putting together some management web management scaffolding around my repos to automate certain things (like copying shared settings from one repo to another, because I'm OCD like that, and not all config appear to have global versions). In any case, in the process I was looking at schema and saw there is a photo column in the users table. I imagine it is for a photo of the user, but cannot find anywhere that it is used. Is this something that was added for specific skins/themes to use or is it something that is generally usable/accessible? This is mostly a curiosity based question. At the moment all the photo for all rows is NULL so it's not something I'm worried about copying, per se. Just wondering the rationale/workings of it. -- Scott Robison ___ 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] users table photo column
On Tue, May 27, 2014 at 4:22 AM, Richard Hipp d...@sqlite.org wrote: In any case, in the process I was looking at schema and saw there is a photo column in the users table. I imagine it is for a photo of the user, but cannot find anywhere that it is used. Is this something that was added for specific skins/themes to use or is it something that is generally usable/accessible? Originally designed for a photo of the user, but not currently used. Thanks. BTW, for those who might be curious, it is a pain to get php fossil to cooperate to create a new repo (HOME env var needs to be set and user can't be detected so --admin-user must be specified). I think it was mostly due to the late hour, as the php system function doesn't display stderr by default, and it took me a while to realize I needed to redirect it myself so I could read the useful command line errors fossil was *trying* to display. Once I did that, it was trivial to get everything working. Probably shouldn't work so late. Whatever. My stuff is now working. YAY! Sorry for polluting the mail list with my self congratulatory blather. ___ 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, May 28, 2014 at 12:05 PM, Warren Young war...@etr-usa.com wrote: On 5/27/2014 22:58, Scott Robison wrote: The best I can come up with for a link to a wiki page (from another wiki page) is something like [Page](wiki?name=Page) which really seems kinda ugly You probably want this syntax: [Page][1] later, typically at end of doc... [1]: wiki?name=Page Thanks. I did realize I could use [Page](wiki/Page) which is better if I just want to do it inline. The footnote style is good to know as well. Still, I've read various things online about what markdown does fossil support and I've read something like vanilla markdown plus some form tables extension. It would be nice to have a very central place (like a wiki page on the fossil repo) that says Here is the definitive list of what markdown use can use on fossil. I'm beginning to think the only place that documentation exists is in the code (which is fine, no one owes me an explanation for free software). Is this the case? -- Scott Robison ___ 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 May 28, 2014 2:31 PM, Warren Young war...@etr-usa.com wrote:
{deleted stuff}
The attached Fossil repo also contains a copy of the official Markdown
documentation. It was included in the test suite, so I linked to it from
the repo's wiki, rather than remove it.
Thanks very much for the effort!
___
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] DRH's PGCon 2014 Keynote (with Fossil sighting!)
On Sun, Jun 1, 2014 at 5:20 PM, Joel Bruick j...@joelface.com wrote: I just wanted to share Richard's PGCon 2014 keynote for anyone here that wasn't aware of it: Thanks for sharing that. And it was good to hear an entire presentation about SQL without once (that I can recall) hearing it pronounced sequel. :) ___ 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] DRH's PGCon 2014 Keynote (with Fossil sighting!)
DOH! Ah well, usually it was S-Q-L. :) On Jun 2, 2014 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Jun 2, 2014 at 5:10 AM, Scott Robison sc...@casaderobison.com wrote: Thanks for sharing that. And it was good to hear an entire presentation about SQL without once (that I can recall) hearing it pronounced sequel. :) Sorry, Scott: @ 4:41s -- - 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 ___ 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 1:29 PM, Joel Bruick j...@joelface.com wrote: Consider it yours. Thanks. Final form: OH: To understand Git's design takes 99x more effort than 99% of software. Once you get to that point it's wonderful! // Too true! Curse the 140 character limit! :) -- Scott Robison ___ 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)
On Wed, Jun 4, 2014 at 1:56 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Jun 4, 2014 at 3:27 PM, Scott Robison sc...@casaderobison.com wrote: I really want to steal this in tweet form: To get to a place where you understand Git's design takes 99x more effort than 99% of software. Once you get to that point it's wonderful! Does that quote belong on this page: http://www.fossil-scm.org/fossil/doc/tip/www/quotes.wiki The full original definitely belongs there: I think Git is a great, powerful, and flexible tool that actually has a much simpler design than it initially appears. But to get to a place where you actually understand that design (and, thus, understand Git), takes about 99x more effort than 99% of the software I've ever used. Once you get to that point, though, it's wonderful! ;) Attributed to Joel Bruick. :) SDR ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Links within Fossil
I don't think this is currently possible, but I've been wrong before, so let me ask: I know it is possible to link to individual artifacts by ID which displays the source, but is it possible to link to a given line number (range) within a given artifact, perhaps highlighting it in the process? My reason for asking: I've been given a new assignment by my employer to learn / understand some relatively obscure source code written by a former employee. This is proprietary code that can't be shared outside the company, but it is not documented (by which I mean there are comments through the code, but no real design or high level understanding of *why* it does *what* it does). My thoughts on how to handle this task (where code is currently stored in an svn repo and will be migrated in the not too distant future to git) is to take the current code and import it into a fossil repo, then use the wiki / inline documentation features to describe it in detail. Part of what I would like to do in the documentation is link to individual lines or blocks in the individual source files so that the reference is internally complete so that I don't have to keep separate source documentation files in sync. Thanks in advance for your help! -- Scott Robison ___ 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] Links within Fossil
On Jun 6, 2014 4:20 PM, Richard Hipp d...@sqlite.org wrote: On Fri, Jun 6, 2014 at 6:12 PM, Scott Robison sc...@casaderobison.com wrote: ... is it possible to link to a given line number (range) within a given artifact, perhaps highlighting it in the process? You mean like this: http://www.fossil-scm.org/fossil/artifact/6eb26bb7a6?ln=1755-1759 [Snipped] Thank you so much, that's exactly it! ___ 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] autosync from GUI
On Jun 7, 2014 1:27 PM, Ron Wilson ronw.m...@gmail.com wrote: On Sat, Jun 7, 2014 at 2:23 PM, Stephan Beal sgb...@googlemail.com wrote: For the local UI case, sure, i can see it being useful, but people would also expect it to work remotely, and it often wouldn't. When running the local UI, that is seen as part of the local client, but when accessing a remote server the perception is different. I think it reasonable that the server Fossil not try to autosync to another server Fossil. Please forgive what may be a stupid observation, but if there are users that need ticket or wiki access (workflows that are typically ui only), might not the best approach be to give them appropriate access to the master via http (as someone already says they do indirectly by making that the master copy)? SDR ___ 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] autocrlf like in Git?
On Jun 7, 2014 1:47 PM, to...@acm.org wrote: Well, I can give a couple of personal examples that you easily try yourselves: * Windows side: Copy/Paste in Windows can not deal with LF endings correctly. Example: PNotepad editor in Windows loads Linux files but copy-pasting from it (for example) to other apps messes up all text (puts it all in a single line). Yes, though this is more a deficiency with a particular program than with Windows at large. The fact is that the convention of newline only as EOL marker is just a convention. CRLF is arguably more correct, particularly given the era in which it was established. * Linux side (vi): Have you tried editing a Windows text file under vi? It shows all ^M (CRs) at the end of each line. I have, and agree it is annoying, but that is an issue of vi choosing not to handle alien text file formats. * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. This seems to be conflating the editing of assembly source with editing of binaries for which source is no longer available. What am I missing? I also wrongly assumed the guys who maintain Git saw a reason for having this option. I can promise you it wasn’t me who asked for it, so they must have had nothing better to do than to add a useless feature in their app that nobody ever needs. Now this is maybe a slightly emotional response. No one has told you EOL conversion is a useless feature, just that in their opinion that it doesn't belong in a particular DVCS whose primary overriding concern is store what I tell you to store exactly as I have stored it. To me this makes sense, particularly on a platform (unixen) that is notorious (to a fault maybe?) of advocating tools do one thing and do it well. I agree that there are tools that will do the wrong thing with mixed or alien EOL markers. My bread and butter is provided primarily by Windows development, so I have to use Visual Studio extensively. It detects mixed line endings on open and offers to normalize. Perhaps an email to vi or emacs or [insert editor of choice] devs might convince them to change their tools. :) I think one of two potential solutions are possible here though: 1. Convince the devs to support hooks (which have their own issues as argued in the past), particularly pre/post commit and post update hooks. In this way tooling (such as tr or dos2unix/unix2dos) could be made to normalize line endings after changes. 2. In the absence of hooks, relatively simple shell scripts could do the exact same thing. SDR ___ 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] autocrlf like in Git?
On Jun 7, 2014 12:44 PM, Richard Hipp d...@sqlite.org wrote: Years ago (decades ago, actually), somebody rigged up fopen() so that it did automatic NL - CRNL conversions unless you used rb or wb as the type parameter. This seemed like a clever solution at the time and was warmly embraced by many developers. However, with the passage of time, this auto-convert-by-fopen idea was found to be a misfeature. An anti-pattern. It lead to a lot of bugs, and a lot of work-around code. It sometimes converts when you do not want it to. It sometimes fails to convert when you do want it to. It is a general nuisance and pain. I would disagree to this extent: misuse of this feature is a problem, and by extension ignorance of it is a problem (by which I mean those unfamiliar with it, not that you are ignorant of it). It is a platform / portability concern feature, in that if you take pure C run time library based code that uses the C platform standard of newline for EOL markers, you can recompile it without modification and get a program that does the right thing for whatever system (newline on unixen, CRLF for DOS Windows, CR only on classic Mac systems). They will generate text that can easily be consumed on the platform and will be able to consume text created by other programs that follow the platform's standard EOL convention. I don't agree that the presence of the feature is a problem. If you meant that the way it was implemented (an optional modification to a parameter to fopen) is the misfeature, then I can agree that it would have been better to do it some other way with 20/20 hindsight, but it was a reasonable solution based on existing practice and standardization efforts of the 70s 80s. SDR ___ 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] autocrlf like in Git?
On Sat, Jun 7, 2014 at 3:40 PM, to...@acm.org wrote: * Several old time assemblers will choke on wrong line endings. Their binaries cannot be updated as the source is no longer available. So, you must edit code only in the right format or you’re out of luck. This seems to be conflating the editing of assembly source with editing of binaries for which source is no longer available. What am I missing? What is not clear? Old assembly source may still be updated, as needed, to support existing products. But the assembler used to convert this source to binary cannot itself be updated as its source is no longer available, only the binary survives. The assembly source is written for this assembler so you’re stuck using it. For old projects that will eventually die, it's not worth the effort creating a newer (better behaving) assembler, and possibly converting all target source code to a possibly incompatible new assembler's syntax introducing a whole bunch of new problems. AH! That is what was not clear to me, and hence why I asked. You meant the assembler's source code was no longer available to edit, when I thought you meant the assembler's output was not editable. But in this case if you have the source for the program you want to assemble, and an assembler that only understands a single EOL marker, you can modify the EOL markers of your source via tr or dos2unix/unix2dos. Now this is maybe a slightly emotional response. No one has told you EOL conversion is a useless feature, just that in their opinion that it doesn't belong in a particular DVCS whose primary overriding concern is store what I tell you to store exactly as I have stored it. To me this makes sense, particularly on a platform (unixen) that is notorious (to a fault maybe?) of advocating tools do one thing and do it well. In general, an SCM that is supposed to be used by various people each working on a their own ‘random’ platform should be able to give to all of them the impression that text files are normal text files, that is ‘normal’ according to their own system, not to the system of the person who initiated the repo. Otherwise, repos should be marked as ‘Linux-only’, ‘Windows-only’, ‘Mac-only’, etc. and trying to open them in the wrong platform should fail with a related error message. Do we agree so far? If not, there is no need to read further. Given that all text files contain their meaningful info in the part of the file that is not the EOL marker, and the EOL marker is only there to assist the underlying OS/library to be able to correctly load/process that text file, changing those EOL at will to be compatible with the user’s current platform is not a violation of any sanctity. If the platform’s tool cannot deal with a text file in its own native format, then that tool is at fault, nobody else. But if a tool cannot deal with a text file of a different platform, we cannot blame the tool. Finally, regarding a comment in another response about the complexity of this change, as for the hash values computation, a stream can easily be wrapped inside another routine that produces a normalized stream that is then fed into the hash calculator. I really do not see the complexity. Maybe I don't have enough decades in this job yet, who knows? I completely agree with the points other than the one that the DVCS is the only tool that can effectively manage the EOL convention of the files. I use a text editor daily that is capable of normalizing EOL convention (though of course there are few things capable of starting a flame war as effectively as suggesting to any random group of people that their OS or text editor is inadequate to some task). :) As long as we're talking about features we'd like to see in a swiss army knife DVCS: a lot of time is spent telling people what the coding standards are for an individual project, things that make EOL conventions seem minor (but would certainly include such things). I'm surprised no one has grafted onto git (or some other DVCS, or maybe I'm just not aware of the one that does) an ability to reformat all source code to match the standards of the project before committing it to the repository. Plenty of programs exist to reformat source code (at least for C C++), and wouldn't it be awesome if we could always check out code formatted to our own preferences and always make sure that no matter what our preferences were out commits always matched the project standards? Hey, DRH, get right on this, will ya? ;) Also, I dislike editing Ruby. I need a DVCS that will convert it to Python automatically for me and then reverse that when I commit. :) Yes, I'm being ridiculous, and I apology. It's more because I found these last two thoughts amusing (particularly the last). I can see a use for tools / hooks that can do this. I don't always agree with DRH, and admit that I liked the idea of the svn ability to convert EOL markers even though I never
Re: [fossil-users] autocrlf like in Git?
On Sat, Jun 7, 2014 at 4:08 PM, to...@acm.org wrote: I completely agree with the points other than the one that the DVCS is the only tool that can effectively manage the EOL convention of the files. I use a text editor daily that is capable of normalizing EOL convention (though of course there are few things capable of starting a flame war as effectively as suggesting to any random group of people that their OS or text editor is inadequate to some task). :) I didn’t say that (“..only tool..”). But, using tools is all about convenience. Yes, we can use Python, Lua, or whatever other scripts to do whatever work isn’t done automatically. But, this loses on convenience. I could also keep (as I did until I started using FOSSIL) all my older versions in dated RAR files, and go back to any version I want to. But, at what cost in terms of convenience? Fair enough. I like fossil because of the convenience of having the wiki ticket systems integrated into the single file repository. I dislike git because of the inconvenience of needing to earn a post graduate degree to understand it. ;) Again, it doesn't seem overly inconvenient to add a little scripting, but agree that it is less convenient. But I can also see the point to the idea that this is the file I created and this is exactly what I want to see when I pull it out of a repo that I put it into. And that’s why those things should always be optional. I never said it should be imposed on everyone just because some like it this way. But not having the option is akin to the other side imposing their ‘right’ way on everybody else. Flexibility is a nice thing, I agree. I suspect that's why the CRNL glob was put in, to give flexibility to people who didn't want to see warnings because their platform didn't conform to the unixen EOL standard. Or that so much effort is spent to make fossil portable between Windows and posix platforms, or why there is a built in web based GUI interface where other tools would tell you to just use the command line terminal mode. There are ideological differences between git and fossil. It's why Linus created git as he felt the existing tools were inadequate for various reasons (be they centralized in the case of svn or pricey in the case of bitkeeper). It's why DRH created fossil, who wanted immutable history vs rewritten history, among other things. All software is going to tell you there is a right way to do certain things. git vs fossil, vi vs emacs, Windows vs unixen, c++ compilers vs python interpreters. In any case, my offer still stands to help script a solution that'll give you what you need! I'm by no means a fossil expert, but I'm confident I could help with something like this if you needed it. SDR ___ 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 CLI tricks: interrupting a commit message
On Mon, Jun 16, 2014 at 2:24 PM, Stephan Beal sgb...@googlemail.com wrote: Hi, all, This is for Unix-shell users only (including workalikes on Windows)... Here's a time-saving tip which i use very often myself, but most CLI users i know don't seem to know about: It often happens that i'm typing a commit message when i decide i need to stop and go check if what i'm typing in really reflects reality (or needs to be tested). So: fossil commit -m .INTERRUPT POINT You can stick that line in your command history without executing it by doing the following: 1) Move your cursor to the beginning of the line. In Bash-like shells that's normally Ctrl-A, but many terminals support the Home key as well. 2) Type the '#' character (shift-3 on a US keyboard). That's the shell's comment-to-end-of-line marker. 3) Tap ENTER Or, in the Bash shell, simply: 1) Tap Escape, then type the # character. That does all 3 of the above at once. On Windows when using cmd.exe, you can do something very similar. Hit home and type remspace to remark (comment) out the line. The space part is a literal space character (ascii 32), not the characters '', 's', etc. Then hit enter. Now you can scroll back up to it later. rem is a legacy of command.com. :) SDR ___ 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 CLI tricks: interrupting a commit message
On Jun 17, 2014 8:42 AM, Eric Rubin-Smith eas@gmail.com wrote: This thread is hilarious. I thought I was pretty old-school -- I use vi, xterm, fvwm2, and other tools written by my forebears around the time when I was born. I get made fun of by people twice my age for my dev toolkit. But even *I* will have two terminals up concurrently -- so that I can write my check-in comment in terminal 1 while looking at my diff in terminal 2. I must be one of those millennials with their newfangled contraptions and their damn music. Excellent point, though sometimes (occasionally) multiple terminal windows are less practical than stashing the command line. :) ___ 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] File contains invalid UTF-8, but is not UTF-8.
On Tue, Jul 8, 2014 at 3:38 PM, Andy Bradford amb-fos...@bradfords.org wrote: That's a good suggestion for fixing the Tcl script, but I'm still not sure why Fossil thinks that è is UTF-8. I thought it was extended ASCII. I didn't think 0xe8 was UTF-8, but maybe I'm mistaken? In the fossil UI, all files are displayed assuming the encoding is UTF-8. That explains the strange character displayed in the browser. If I switch my browser to ISO-8859-1 it displays fine. More likely is that people are not aware that such characters can cause unexpected problems. The only thing unexpected has been the warning from Fossil for a file that previously had no warnings. :-) Sounds like my options are either to answer Yes, or update the Tcl file that I have stored in a Fossil repository to use \xe8. UTF-8 characters are encoded as a series of strictly formatted bytes, from 1 to 4 bytes in length. The bit patterns of the bytes control whether a stream is considered valid UTF-8 or not. For UTF-8 the 0xE8 byte must be followed by two bytes of the form 0b10xx. The warning you are seeing is that the stream is invalid UTF-8. 0xE8 byte could be an extended ASCII character from one of the ISO-8859-X code pages. Or it could be real binary data that just happens to mostly have ASCII text in it. I think the best idea is to encode these special characters as escaped sequences whenever possible. -- Scott Robison ___ 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] Unusual timeline
On Wed, Jul 9, 2014 at 5:49 PM, Andy Goth andrew.m.g...@gmail.com wrote: http://fossil-scm.org/index.html/timeline?p=92c2c1e5e18b19c5b05ea5684feb0bbeeb6670fd What's going on here? Everything is tagged trunk, yet [b4a53ba45f] is displayed as if on a branch. Was there a fork or something? The only difference I can see is that that commit is marked closed, so I suspect that's why it is considered a branch. If closed were removed from it it'd probably be on the main trunk chart, but ... I'm really just guessing. SDR ___ 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 vs git-based arrangements. code review and ticket export
On Wed, Aug 6, 2014 at 7:42 PM, Warren Young war...@etr-usa.com wrote: I'll finish with my original premise: except in areas where software development is just a way of doing physics or pure mathematics of one sort or another, you probably are not doing engineering from the start. This is why I prefer the term software development. We may not know exactly where we are going or how to get there, but somehow we always recognize it when we arrive. Excellent points. I've been known to tell people I'm either a software engineer (and software developer isn't a bad substitute) or computer programmer depending on how important I want to seem at a particular point in time. :) That being said, I see the two differently. Perhaps software engineer is somewhat of a misnomer compared to more traditional engineering fields, but one could argue software architect is too. A computer programmer to me is someone who knows how to use particular tools / frameworks / libraries / etc to build a particular class of software. A software engineer is one who can successfully design data structures and algorithms to solve problems with whatever tools are available or necessary to complete the task. At my previous job I was the software development manager. I needed software developers to think through problems and solve them. Too many applicants were of the computer programmer variety (and subpar at that): great for when you needed someone to cobble together a web app using C# and ASP.NET. If you needed them to build anything outside that one zone, they were lost. The number of applicants that couldn't write a string reverse algorithm in pseudo code boggled my mind. The reason was clear: We were a startup company, and the founders weren't willing to pay for what they really needed, relying on luck to find good people willing to work for sub-market wages. We found some, but it was an exhausting process. -- Scott Robison ___ 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] Closing fossil output
On Mon, Aug 11, 2014 at 1:33 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: Well, I don't really get, a closed file descriptor wouldn't cause corruption, would? btw, i'll use /dev/null. It wouldn't cause corruption in and of itself, but once you close a file descriptor, it becomes available for use in a future open operation. If you close stderr (descriptor 2) and then a database file is opened as descriptor 2, anyone who assumes descriptor 2 is always stderr is going to write textual data to a non-terminal / non-text file. The fact that descriptor 2 was closed isn't the problem, it is the assumption that descriptor 2 will always be stderr that is the problem. SDR ___ 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] Closing fossil output
On Mon, Aug 11, 2014 at 2:36 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com wrote: I understand why one cannot open a database (or any other command) from descriptor file minor than 3. But why this `fossil branch 21` do work and `fossil branch 2-` doesn't, it's not clear. If i open a database using descriptor 3 and close stderr, does descriptor 3 becomes 2 ? I don't want bother anyone, i just asking because this is something new to me. Your guess is correct. Normally you have STDIN, STDOUT STDERR as fd 0, 1 2 respectively. By telling the shell to close / not open STDERR (2-) 2 becomes the next file descriptor and is used by the environment when SQLite opens one of the databases. SDR ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Versionable settings question
In the admin settings page it reads: Settings marked with (v) are 'versionable' and will be overridden by the contents of files named .fossil-settings/PROPERTY. If such a file is present, the corresponding field above is not editable. It seems that the fields are only uneditable if you use fossil ui or fossil server (or some way of browsing from an open checkout) but not for a CGI session. It makes sense that it works this way because it is relatively easy for fossil to look at the file system of the open checkout to detect if there is a versionable setting and modifying the generated html appropriately, but is probably far more difficult to look into the repository to see if those files exist (and if they do, do they exist for the current trunk, or tip, or whatever). Perhaps impossible is a better word, since the versionable settings have to exist in a given commit, and being versionable you would what whatever current commit is open to be the versions of the settings in use. Since a CGI session is using a specific repo, not an open checkout. Okay, sorry for the rambling. I was thinking of using the versionable settings as a way to avoid pulling configuration settings from the master to my remote repositories, but now this is seeming like a less than perfect option, because the CGI of the master can't see the same settings information that my open checkouts see. Am I missing something? Is it possible for the CGI to see the versionable settings, or am I correct in my reasoning as to why? -- Scott Robison ___ 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] symlinks
On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp d...@sqlite.org wrote: D'oh. I had searched the forum + google and found threads in which the devs described why there was no support, and then tested to see if there was support by just checking in a symlink (which didn't work by default). So I missed the existence of the feature. Sorry for the noise! :-( Not noise. This is signal that means we need to improve the documentation Would there be any interest in adding symlink support to Windows (where available [Vista later], leaving the text file approach where it is not)? -- Scott Robison ___ 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] symlinks
On Thu, Aug 28, 2014 at 9:26 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison sc...@casaderobison.com wrote: On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp d...@sqlite.org wrote: D'oh. I had searched the forum + google and found threads in which the devs described why there was no support, and then tested to see if there was support by just checking in a symlink (which didn't work by default). So I missed the existence of the feature. Sorry for the noise! :-( Not noise. This is signal that means we need to improve the documentation Would there be any interest in adding symlink support to Windows (where available [Vista later], leaving the text file approach where it is not)? Did you just volunteer to submit patches? -- 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 -- Scott Robison ___ 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] symlinks
On Thu, Aug 28, 2014 at 9:26 AM, Richard Hipp d...@sqlite.org wrote: On Thu, Aug 28, 2014 at 11:23 AM, Scott Robison sc...@casaderobison.com wrote: On Thu, Aug 28, 2014 at 9:04 AM, Richard Hipp d...@sqlite.org wrote: D'oh. I had searched the forum + google and found threads in which the devs described why there was no support, and then tested to see if there was support by just checking in a symlink (which didn't work by default). So I missed the existence of the feature. Sorry for the noise! :-( Not noise. This is signal that means we need to improve the documentation Would there be any interest in adding symlink support to Windows (where available [Vista later], leaving the text file approach where it is not)? Did you just volunteer to submit patches? That was my idea (unless mentioning it motivated a dev to do it and commit in 15 minutes or less, as often seems to happen around here). :) -- Scott Robison ___ 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] how to use git to lose data
On Mon, Sep 1, 2014 at 9:29 AM, Stephan Beal sgb...@googlemail.com wrote:
Okay, more git bashing...
{snipped stuff went here}
It occurred to me today that in nearly 31 years of using a computer i
have, in total, lost more data to git (while following the instructions!!!)
than any other single piece of software. Also concluded is that git is the
only SCM out there which makes SCM difficult for the simple stuff. Even RCS
is simpler to use. Sure CVS has limits, but respect those limits and it
works just fine. Never lost a line of code in CVS.
Interesting. I think I've mentioned my employer is in the midst of
converting from an svn backed model to a git based model, though slowly on
a subproject by subproject basis. I've shared this with the
git-master-chief person at work and followed it up with the following
questions / observations:
Based on reading {Stephan's message}, what do you agree or disagree with?
It seems to me (after reading this and thinking about version control
systems in a slightly new way for the first time today), git is focused
less on securely keeping track of source code and far more on providing a
toolbox of ways to reorganize code to simplify (I use that term loosely)
social interactions between developers / users of git (aka collaboration).
It's not that it can't keep track of source code, but that it considers the
social aspects / reorganization tools to be more important, while at the
same time being quite terse / obtuse in the documentation / usage area.
Is that an unfair assessment on my part? I still readily agree that I'm a
git newbie, and even a dvcs neophyte, and the reasons I use fossil have
little to do with its distributed nature (though I'm using it more often
that way as time goes by). Also that for certain project types where large
/ deep hierarchies of collaborators are at work, fossil is probably not an
ideal solution. It certainly wouldn't work in the same way git is used by
the linux kernel team.
I'll be interested to hear back from him what he thinks.
--
Scott Robison
___
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] how to use git to lose data
On Tue, Sep 2, 2014 at 2:44 AM, Gour g...@atmarama.net wrote: 9) Source control system is not only for keeping the code - here it's used for very general writings (even non-computer-related). (too) specific = selfish, universal = broad-minded. Interesting you should write this. One of my newest uses for fossil is the one case in which I'm using it distributed (even though all by myself): My blog (such as it is). It is not a unique idea at all, but I finally tired of heavy weight blog platforms and decided I wanted to just keep track of things in text files. I've started using the pelican static site generator to keep all my site's source files (restructured text files in a content tree config files etc) as well as the generated files (public tree). I only maintain the site on my home computer (including generating the public stuff), but then I commit sync it to the remote server and update the live site, making the generated file tree available (and giving me a live backup of all the files). -- Scott Robison ___ 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] how to use git to lose data
On Sep 2, 2014 12:10 PM, Ron W ronw.m...@gmail.com wrote: On Mon, Sep 1, 2014 at 5:49 PM, Scott Robison sc...@casaderobison.com wrote: It certainly wouldn't work in the same way git is used by the linux kernel team. Git was originally created by the Linux Kernel team, including Linus. It's hardly surprising that git would be a better fir for them than Fossil or any other VCS (distributed or not). That was the point I was going for. Maybe should have made it explicit. ___ 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] More on Fossil-v-Git
FYI the Google translation service is reporting that the site is compromised in some way. So no translation at the moment, and I would probably advise extreme caution loading the original site even of you can read Russian. Sorry for top post, sent from phone. SDR On Sep 5, 2014 5:52 AM, Richard Hipp d...@sqlite.org wrote: There seems to be a spirited debate on the relative merits of Fossil and Git going on at the Russian-language website: http://habrahabr.ru/post/235369/ Machine translation here: https://translate.google.com/translate?hl=ensl=rutl=enu=http%3A%2F%2Fhabrahabr.ru%2Fpost%2F235369%2F My summary: Some people get it and understand why Fossil is an interesting idea. Others (perhaps due to different backgrounds or work styles or expectations) cannot seem to grasp why anyone would ever consider using Fossil. -- 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil for web site maintenance [was how to use git to lose data]
On Sat, Sep 6, 2014 at 9:52 AM, Miles Fidelman mfidel...@meetinghouse.net wrote: Scott Robison wrote: ... One of my newest uses for fossil is the one case in which I'm using it distributed (even though all by myself): My blog (such as it is). It is not a unique idea at all, but I finally tired of heavy weight blog platforms and decided I wanted to just keep track of things in text files. I've started using the pelican static site generator to keep all my site's source files (restructured text files in a content tree config files etc) as well as the generated files (public tree). I only maintain the site on my home computer (including generating the public stuff), but then I commit sync it to the remote server and update the live site, making the generated file tree available (and giving me a live backup of all the files). A little late getting back to this, but... Scott, can you say a little more about your tool chain, end to end from editing to online? (I've been thinking about doing something similar, but for maintaining some project documentation and works in progress). It's been a while since I started, so there may be some amounts of hand waving over things I don't remember exactly, but: 1. I installed the pelican static site generator along with its prerequisites: http://blog.getpelican.com/ 2. I had been using a private Wordpress installation, so I exported that database somehow and used some utility to convert it to restructured text files. 3. I use Notepad++ on Windows 7 for my text editing, and a command prompt for organizing files (moving or deleting some older blog posts that I didn't want in the exported blog for whatever reason). 4. I wrote a few simple scripts in PHP to provide a very basic chisel-esque management portal on my website; they are used to create repos, change passwords, and provide a front end to all my repositories. Using that I created my initial empty repo. 5. I cloned/opened the repo to my Windows 7 machine and added all the source and generated public files. 6. I synced that back to my server and opened the repo in the web directory, organized so that my public directory is the only one published. 7. Because I was porting an older blog to this new system, I had a fair number of media files (mostly images, some audio, a sprinkling of others) that were not in the Wordpress database, only in the old file system. So as I cleaned up each of the approximately 100 posts on my Win7 box, I would move media from the old location of my blog on the server to the open workspace, add them and commit them server side. 8. Update on Win7 to get the changes. 9. Regenerate the blog, addremove, commit, sync to the server. 10. Update the server side and check out my work, making any needed tweaks to ensure everything was presented essentially as I wanted it. 11. Repeat steps 7 through 10 for each of the posts. It's not a very impressive or sophisticated workflow IMO, but it did what I wanted quite nicely. While the blog itself is also not terribly impressive and not frequently updated (though I keep meaning to change that!) you can see it's current state at www.casaderobison.com. I've cleaned up all the posts and made sure all the media is available. I still have work to do cleaning up the category/tag system and tweaking the theme to my liking. I hope that answers the questions and wasn't *too* tedious. :) -- Scott Robison ___ 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] how to use git to lose data
On Sat, Sep 6, 2014 at 5:24 PM, Nico Williams n...@cryptonector.com wrote: git branch -D name Eh, filesystems let you delete files. Unlike most filesystems, git lets you restore your deleted branches (yes, provided you don't gc the repo). Then just use a file system and various command line tools! But seriously, it's a philosophical difference between those who want to be able to rewrite their history to what they should have done and those who want to keep the history around to see what they did. It's not perfect, and certainly there are arguments for both approaches, but git seems fragile to some people while fossil seems inflexible to others. -- Scott Robison ___ 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] security notice for _potential_ problem with _some_ CGI-hosted repos
On Thu, Sep 25, 2014 at 10:43 AM, Stephan Beal sgb...@googlemail.com wrote: My mother just sent me this, bless her heart: http://www.wired.com/2014/09/internet-braces-crazy-shellshock-worm/ Management summary: CGI scripts which use bash (as opposed to /bin/sh, with the caveat that /bin/sh is an alias for bash on some systems) might _potentially_ be affected. Some of this article is downright FUD[1], some of it is not _necessarily_ FUD. i pass it on primarily because all my CGI Fossil repos (currently) use /bin/bash instead of /bin/sh (will be resolved momentarily). [1] = PHP does _not_ use bash to run scripts in any environment i've ever seen in 15 years of admin'ing PHP-using servers. (PHP has whole books' worth of other security problems, though, unrelated to this article. ;) Thanks for sharing that. As it turns out I do use a couple of bash scripts behind a HTTP Basic secured site (so now script access until after authentication, and I am the only one with a username/password, at least for now). I'm not too worried about it, but it's good to know that I probably need to go do security updates on my server. -- Scott Robison ___ 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] Proposed improvement to inheritedprivilegessubscripts.
On Sep 28, 2014 12:49 AM, Stephan Beal sgb...@googlemail.com wrote: Sidenote: i'm curious why most people prefer postscript addition, when prefix is never slower and sometimes faster. (Not that it matters one iota for a case like this, it just seems to be very deeply embedded in most people i know.) I think most people (I am not most people in this case) prefer / use postfix increment decrement because it is what they learned first and how most examples seem to be written. I prefer to use prefix operators (barring the need for postfix side effects) just because they read more naturally in my native language. I think it makes more sense when thinking increment i to see ++i. The fact that it is potentially more efficient (though probably not in practice) is just a bonus. Now if only I could get everyone on board with making $ for currency a postfix operator (because 1$ makes more sense than $1). :) ___ 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] Proposed improvement to inheritedprivilegessubscripts.
On Sep 30, 2014 9:57 AM, Stephan Beal sgb...@googlemail.com wrote:
On Tue, Sep 30, 2014 at 5:54 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
I actually did try to update it myself last night but had alignment
issues due to the font on the (s) letter not being a fixed font.
i didn't even consider the font width - excellent point.
{snipped}
Sorry for opening this huge can of worms! :)
___
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] Tip: abusing autosync to abort a commit
On Oct 6, 2014 12:26 PM, Stephan Beal sgb...@googlemail.com wrote: Hi, all, (This just happened...) The autosync option provides (incidentally, not specifically by design) a feature one doesn't have if it is turned off: the ability to abort a commit within a small (and unknown/varying) time frame. For example: the intention here was to commit a single file, but 3 are actually modified: [stephan@host:~/cvs/fossil/cwal/s2]$ f com -m 'Minor build tweak.' Autosync: http://step...@fossil.wanderinghorse.net/repos/cwal/index.cgi ^C autosync gave me the time frame my brain needed to realize the mistake, giving me the opportunity to tap Ctrl-C. I have that functionality without auto sync. I don't use the -m comment option so I get a text editor showing me what has changed before I type the message. If I decide I need to not commit, I don't enter a message and fossil warns me allowing me to abort the conmit! :) ___ 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] Tip: abusing autosync to abort a commit
Bah! Commit not conmit. Stupid phone keyboard. On Oct 6, 2014 12:39 PM, Scott Robison sc...@casaderobison.com wrote: On Oct 6, 2014 12:26 PM, Stephan Beal sgb...@googlemail.com wrote: Hi, all, (This just happened...) The autosync option provides (incidentally, not specifically by design) a feature one doesn't have if it is turned off: the ability to abort a commit within a small (and unknown/varying) time frame. For example: the intention here was to commit a single file, but 3 are actually modified: [stephan@host:~/cvs/fossil/cwal/s2]$ f com -m 'Minor build tweak.' Autosync: http://step...@fossil.wanderinghorse.net/repos/cwal/index.cgi ^C autosync gave me the time frame my brain needed to realize the mistake, giving me the opportunity to tap Ctrl-C. I have that functionality without auto sync. I don't use the -m comment option so I get a text editor showing me what has changed before I type the message. If I decide I need to not commit, I don't enter a message and fossil warns me allowing me to abort the conmit! :) ___ 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] Tip: abusing autosync to abort a commit
I just wanted to give you a little grief based on past -m comments. :) On Oct 6, 2014 12:42 PM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Oct 6, 2014 at 8:39 PM, Scott Robison sc...@casaderobison.com wrote: I have that functionality without auto sync. I don't use the -m comment option so I get a text editor showing me what has changed before I type the message. If I decide I need to not commit, I don't enter a message and fossil warns me allowing me to abort the conmit! :) Well... yeah... that'd be the easy way ;). i always use -m, simply out of long-standing habit. Your argument is a good reason to start weaning myself off of that, though. -- - 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 ___ 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] Tip: abusing autosync to abort a commit
On Mon, Oct 6, 2014 at 1:34 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Stephan Beal on Mon, 06 Oct 2014 20:25:55 +0200: The autosync option provides (incidentally, not specifically by design) a feature one doesn't have if it is turned off: the ability to abort a commit within a small (and unknown/varying) time frame. joke Perhaps there should be a known and variable configuration setting that gives you that brief amount of time on purpose? ;-) fossil commit-wait-interval 5 Will wait for 5 seconds before actually attempting to commit anything. /joke My first year of college I took a fortran (I mean FORTRAN) class. Our lab was hosted on big heavy terminals connected to a mainframe. In any case, the newbie friendly system had a triple prompt any time you tried to delete a file from your workspace: 1. Delete filename (y/n)? 2. Are you sure you want to delete filename (y/n)? 3. Last chance! Are you really sure you want to delete filename (y/n)? Naturally, muscle memory kicks in before long and you get used to hitting D Y Y Y in quick succession to delete a file. Which I did once. I blamed myself for not thinking it through. And later as a TA for the class I dealt with a few students who had the same problem. Students were more apt to blame me (even though there was nothing I could have done about it). :) Anyway... yeah. Not all safety systems are very safe. :) -- Scott Robison ___ 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] http --enforce-remote-user
On Oct 13, 2014 7:42 AM, David Mason dma...@ryerson.ca wrote: On 13 October 2014 04:54, Tony Papadimitriou to...@acm.org wrote: The claim that once you shun a 0-length file you will not be able to commit another 0-length file again is not entirely true. If you first delete the existing 0-files, and re-enable the shunned SHA1, then you can add 0-length files again. Yes, when I said never I should have added unless you unshun that id. I wasn't necessarily advocating a change in behaviour, just pointing out what a big stick this was. Perhaps pointing out this edge-case in the documentation or the shunning web page would be sufficient (or a pop-up warning if the user enters the 0-length UUID on the shunning page). I would think documentation is the best course. One could make almost the same argument about any really short file, or the (extremely unlikely) case of a hash collision (though at that point there are far worse problems to deal with). Rather than trying to catch all possible potentially bad uses of the shun stick, just improve the quality of the documentation. ___ 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] Hungarian Notation Used in Fossil
On Tue, Dec 16, 2014 at 10:29 PM, Warren Young w...@etr-usa.com wrote: On Dec 16, 2014, at 7:37 PM, Richard Hipp d...@sqlite.org wrote: But they are useful at times. Yes. It’s not as useful as a type system that simply doesn’t let you do questionable things,[*] but when you have to write in C or C++, it’s good to buttress the type system with some notation. I’ve used a similar system for decades: a = array (some like v for vector instead) b = Boolean c = character (except when used as an 8-bit integer) e = enum f = floating-point number g = global h = handle (haven’t used this since my Win32 days) k = constant n = integer number p = pointer s = string (C++ only; C strings are pc or kpc) _ = trailing underscore on C++ private member variables The thing I dislike about the strict Microsoft way is the embedding of actual type data into the variable name, so that if you decide to change a type later, you have to change all the names. (I realize the above quote is not the strict Microsoft way, just commenting). I like the idea of a loose Hungarian notation which helps you remember the general purpose of a variable (handle, string, number, pointer). I loathe ... uh ... do not care for ... the embedding of scope or constness. Which is not to say I never do it (when in Rome) but I still don't care for it. If source code is meant to be read by humans (as well as processed by compilers) then I want as little crypticness (is that a word) while reading as possible. The nature of programming prevents that from being achieved anywhere near 100% of the time, of course, but I prefer not to sound like I'm coughing up a furball if I'm discussing source out loud. :) My actual function was fairly complex, and I accidentally left one of the “return false” calls unchanged. C++ allows false to convert to 0 which converts to const char* which turned a failure condition into success! The compiler didn’t even blink, even with -Wall. Perfectly sane according to GCC. Grrr. Well, it's just a widening conversion of 0 from 1 bit to 32 or 64 bits. Of course it's sane! :) -- Scott Robison ___ 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] Hungarian Notation Used in Fossil
On Dec 17, 2014 8:26 AM, Ron W ronw.m...@gmail.com wrote: On Wed, Dec 17, 2014 at 2:10 AM, Scott Robison sc...@casaderobison.com wrote: The thing I dislike about the strict Microsoft way is the embedding of actual type data into the variable name, so that if you decide to change a type later, you have to change all the names. (I realize the above quote is not the strict Microsoft way, just commenting). The irony of this is that they are corrupting what of their own people (Charles Simonyi) proposed (see below). I had heard that but never read it. Thanks for the link. SDR ___ 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] Hungarian Notation Used in Fossil
On Wed, Dec 17, 2014 at 11:35 AM, Warren Young w...@etr-usa.com wrote:
On Dec 17, 2014, at 12:10 AM, Scott Robison sc...@casaderobison.com
wrote:
I loathe ... uh ... do not care for ... the embedding of scope or
constness.
g is easy to justify. It’s a heads-up to the programmer: “Pay attention,
you’re looking at something that some other bit of code way over on the
other side of the source tree could be changing on you!” It also prevents
the old problem of “global i”.
{snipped}
I understand why they are useful. Everything (well, most everything) has
pros cons. Just a personal preference on my part.
I prefer not to sound like I'm coughing up a furball if I'm discussing
source out loud. :)
You talk to _other people_??! :gobsmack:
As little as possible. :)
--
Scott Robison
___
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] Repo with many initial commits + more wish list
On Tue, Jan 27, 2015 at 6:57 AM, Tony Papadimitriou to...@acm.org wrote: * People wanting to come to FOSSIL from other systems (with the exception of git for which there is an import feature) have to wait for a new project if the want to keep the full history of changes, or go through a very tedious and time consuming process of manually generating the repo to look as if it was used from the beginning of the project. (To get an accurate result, you need to fiddle with the system clock to pretend you're committing at an older date/time. Although fossil's concept is to have an immutable repo (and I completely agree with that), While it is not documented, I used a --date-override option with fossil commit several years ago while migrating my repos to accomplish exactly what you're describing. Much less tedious than fiddling with the system clock prior to each commit. :) -- Scott Robison ___ 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] what determines the string length of sha1 display in the timeline?
On Mon, Feb 9, 2015 at 11:17 PM, j. van den hoff veedeeh...@googlemail.com wrote: and if one cannot agree on whether this is good or bad when using 10 char substrings (or whatever length), I would like to have a flag/option enforcing the use of the full 40 char hashes in the generated output (notably timeline and finfo). that for sure would solve your JS example as it would my does not match a fixed regex and messess up keys in tcl dictionary problem. what do you think? While a very (*very*) remote possibility, there are 10E40 sha1 hash values that have no letter in them whatsoever. It is less than 0.02% of the total possible sha1 hashes, so I'm not worried about it personally. Just throwing it out there for consideration. :) -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] FLOSS interview
Just watched the interview at http://twit.tv/show/floss-weekly/320 ... good
job! I can't believe DRH didn't drop my name, but I'll forgive him this
time. {snicker}
Oh, and I'm always looking for a good text editor. Show us what you've got!
:)
--
Scott Robison
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Possible Bug in Merge Conflict Blocks
I was going to get my old winsymlink branch caught up with trunk, so, using a build from the tip of trunk (This is fossil version 1.32 [a7e1101d71] 2015-03-17 21:10:44 UTC) I: 1. fossil update winsymlink 2. fossil merge trunk 3. merge conflict reported for src\file.c, src\update.c, src\vfile.c. I view src\file.c where there is a single merge conflict. The first block (BEGIN MERGE CONFLICT: local copy shown first) shows exactly what I'd expect to see. The second and third blocks, however, are missing the last line from each. In this case the last line should be #endif for both the COMMON ANCESTER MERGED IN blocks. Instead it is showing the all except for the final line. Just FYI. I can try to take a look at it later, but given the speed that these things are often fixed, I figured I'd report it now. -- Scott Robison ___ 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] Possible Bug in Merge Conflict Blocks
On Wed, Mar 18, 2015 at 11:42 AM, Richard Hipp d...@sqlite.org wrote: On 3/18/15, Scott Robison sc...@casaderobison.com wrote: Just FYI. I can try to take a look at it later, but given the speed that these things are often fixed, I figured I'd report it now. Too many balls in flight right now. Please have a look and send patches. Tnx. Understood. I'll see what I can find. -- Scott Robison ___ 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] Git-v-Fossil. Was: Google code shutting down
On Mar 16, 2015 9:44 AM, James Moger james.mo...@gmail.com wrote: On Fri, Mar 13, 2015 at 8:26 PM, Richard Hipp d...@sqlite.org wrote: Fossil was created to support the development of SQLite. All other use (and there is more and more of that lately) is just gravy. They all start somewhere. :) Git Hg were both written to solve the Linux kernel's BitKeeper conundrum. Both grew to be larger than just a solution for the initial need. It could happen for Fossil too. It has happened for fossil. Just to a different magnitude. :) SDR ___ 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] Possible Bug in Merge Conflict Blocks
On Wed, Mar 18, 2015 at 5:41 PM, bch brad.har...@gmail.com wrote: I tried this, and I see what you're talking about -- It's not clear to me it's an error (I'm not apologizing for anything that happened here, but I'd have to better understand the merge algorithm to know if this is logically sane). Its easy to see how this could be confusing though. I'll have to fiddle more to understand this. Understood. It is arguable in my mind that either the #endif should be in both of the baseline and merge portions, or that it should be present once after the merge conflict block. To not show it anywhere around the merge conflict though seems wrong. I'm also looking / debugging, trying to puzzle it out. I've created another repository that just has that one function from that one file in a similar trunk/branch configuration, and the same behavior is still present. Will keep looking. -- Scott Robison ___ 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 6:32 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Scott Robison sc...@casaderobison.com wrote: I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. So the staging area is being used as a way of working around the fact that Git does not allow multiple independent check-outs against the same repository? Am I understanding that correctly? That is the best answer I've been given. I explained how I worked (in both svn fossil) on separate branches in separate directories, but received no further feedback on that topic. -- Scott Robison ___ 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] Is this a crazy idea?
On Thu, Mar 19, 2015 at 6:14 PM, Richard Hipp d...@sqlite.org wrote: On 3/19/15, Abilio Marques abili...@gmail.com wrote: Most of the friends I've shown fossil to love the idea of having SCM, wiki and tickets in the same, tiny place. Looks promising for them... but then they miss the git staging area. Does the git staging area provide any capability beyond this? Am I missing something? Please help me to understand why people think that the git staging area is a good idea. I can't answer for Abilio, but given my recent increased experience with git due to workplace changes: the git folk seem to prefer the staging area because you're less likely to accidentally commit something you didn't mean to. Essentially, it seems like a feature for people who can't or don't want multiple open work areas so ensure the right things get committed on the right branches, since they very well may be working on multiple branches at the same time in the same tree. See this: http://stackoverflow.com/questions/6270193/multiple-working-directories-with-git The staging area can be disabled / skipped, but that's how it has been explained to me. -- Scott Robison ___ 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] home directory must be writeable
On Thu, Mar 19, 2015 at 5:45 PM, Richard Hipp d...@sqlite.org wrote: I remembered that change as having occurred years and years ago. But upon consulting the timeline, I see that Joe put it in two months ago. I don't recall the exact reason. Thanks Joe! This solves an annoyance for me. -- Scott Robison ___ 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] Is this a crazy idea?
On Mar 20, 2015 1:07 PM, Abilio Marques abili...@gmail.com wrote: Yeah, stash is the way I do all the time, but sometimes I want to exclude binaries that are regenerated each time a change and compilation occurs, until I'm ready to the new version to go into trunk. Top of my mind, the PDF files that are generated when I use LaTeX. I want to keep the stable version in trunk, yet avoid including binaries that are sometimes hundreds of Kbytes each commit to my this is just a test branch, or this is a modification in progress branch. I would have to stash the PDFs before each commit (and they are not useful anyway) or type down the entire list of files that I want to include on each commit, which are different each time. But by doung fossil ci --ignore file1.pdf file2.pdf -m here is an example, I can reuse that command 15 times without using the brain harder than a normal complete commit will ask me for, until I'm ready to go to the trunk. Just throwing out an idea: I can see the utility in ignoring certain files on the command line. An ignore switch fits with other commands which take an ignore glob on the command line (I think). The extended thought that came to mind was a new command like fossil pause, which would not remove a file from the repo, probably would only apply to the working copy, but would stop committing updates to paused files until unpaused. For those of us that use the interactive commenting feature at commit, it could easily provide a list of not only what files are included in the commit, but what files are updated but paused. Or maybe it is a solution in search of a problem. ___ 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] Possible Bug in Merge Conflict Blocks
On Thu, Mar 19, 2015 at 9:32 AM, bch brad.har...@gmail.com wrote: The reality is that nothing can be perfect for 100% of all possible use cases, and in this particular case, I just got unlucky. The merge conflict information as given couldn't support a mechanical pick one or the other resolution (which was fine because this particular merge needed a thought out solution, not a mechanical resolution). This is what I was leaning toward. I'm inclined to just leave it alone and live with the reality. Sorry for yelling fire (or whatever). Thanks for filling a reasonable report - I think the next step is developing a *workflow* that illustrates what's going on: i.e.: select you edits, run a diff to see what the changes really are. One thing that struck me is that code references (i.e.: last common ancestor) could stand to have their SHA1 identifier included in the header so I've got it for immediate reference. And to be clear that's the sort of thing I do (and what is typically necessary). As I've thought more about it, I think the reason for the disconnect for me in my head (not having dealt much with merge conflicts in the past) is that the merge conflict block greatly resembles a diff between two revisions, yet it is not a traditional diff (and thus does not replace the need for actual analysis via traditional diff between the baseline each of the two descendants, possibly more). No biggie. Just a little embarrassment for crying wolf. But the good thing is that I understand the merging code and rationale a lot better now than I did 24 hours ago. :) -- Scott Robison ___ 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] Possible Bug in Merge Conflict Blocks
On Wed, Mar 18, 2015 at 12:19 PM, bch brad.har...@gmail.com wrote: Scott -- if there's a case you concoct (and post) that demonstrates the issue, more eyeballs and brains can review. I posted a Reader's Digest condensed one earlier, but here it is in more detail: 1. From an opened working directory of fossil, run fossil update 44a160a341 (the most recent winsymlink branch prior to one I updated earlier today). 2. Next, fossil merge a7e1101d71 (merge the last almost five months of trunk updates). 3. Observe that there are merge conflicts for src/file.c, src/update.c, and src/vfile.c. 4. Open src/file.c and go to BEGIN MERGE CONFLICT at line 295. 4a. The local copy shown first portion is fine. It shows exactly the body of the file_wd_perm function from the original version of the file. Diff src/file.c against src/file.c-original and you should see it immediately (or at least I did with WinMerge). 4b. The COMMON ANCESTOR portion is missing #endif from line 259 of the baseline version of the file. Diff src/file.c against src/file.c-baseline to see the missing line. 4c. The MERGED IN portion is missing #endif from line 249 of the merge version of the file. Diff src/file.c against src/file.c-merge to see the missing line. So if you discard the COMMON ANCESTOR and MERGED IN versions, you'll have a a complete body. If you discard the local copy and keep one of COMMON ANCESTOR or MERGED IN, you'll have an incomplete body. If you look at it for an hour or so trying to make sense of which if any pieces of each version you should include, you'll be quite confused as you try to come to terms with your first merge conflict and simultaneous uncertainty about the meanings COMMON ANCESTOR / baseline and MERGED IN / merge and local copy / original and where to find all this in src/file.c. Or at least I was. It was a perfect storm. Confusing changes between trunk branch some sleep deprivation experiment my body is forcing me into took me a while to come to the realization I shared above. -- Scott Robison ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 2:55 PM, Steve Stefanovich s...@stef.rs wrote: If we are discussing partial, I'm more interested in partial checkouts than partial commits, i.e. having the ability to checkout a specific directory only. Now that would be useful for us with big source trees where there are third party components included. +1 -- Scott Robison ___ 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] Select specific changes within files
On Fri, Mar 20, 2015 at 10:26 AM, bch brad.har...@gmail.com wrote: I'm still confused about what complete or split means in the contexts that I think people are using this -- If I accidentally code two different logical thoughts into a single file -- and so they are combined, and uncommitted -- why would tools or facilities to aid making-discrete two different logical ideas be discouraged, and what precludes testing this separated code ? I think the problem is not everyone is using test exactly the same way. If you are talking about automated testing, it can only happen after committing code. If you are talking about developer testing, yes, you can test code after committing it, but ideally you've made changes, tested them, then committed. The staging mechanism seems to require you to make a commit before testing. With git, not so bad. You can rewrite history as much as you want until you're satisfied. With fossil, this doesn't work. Except that it can work in a similarly functional way (yet less confusing from my perspective) as I outlined in my previous email. -- Scott Robison ___ 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] Select specific changes within files
stage partial files, using some user interface to specify which portions are staged, and commit. 4. You stage the other set of changes and commit them elsewhere. 5. Only now that you've saved the two different sets of changes do you test / rewrite history / whatever. I personally don't see where the suggested fossil workflows are inferior to what git provides. I'm sure there are possible improvements, but I personally can't see where the git partial file commit functionality buys you anything you can't just as effectively do with a text editor and existing support from fossil, and with far less confusion or complexity. -- Scott Robison ___ 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] Google code shutting down
On Fri, Mar 13, 2015 at 4:22 PM, Graeme Pietersz gra...@pietersz.net wrote: 6. There are cases where Fossil’s single-executable philosophy really matters. The ones I’ve run into amounted to cross-compiling: it’s easier to build an ARM executable for a Chromebook or Raspberry Pi and copy just that across than to set up a whole cross-compilation toolchain complete with shared libraries, package managers, etc., then ship some massive bolus-of-code over to the other platform and unpack it there. You don’t always get the luxury of building on the target platform. ChromeOS doesn’t even come with compilers. In the case of the Pi, Git and Fossil (and Mercurial and Bazaar and more) are in the Raspbian repos. So is gcc so I imagine you could compile the latest version on the Pi itself if you wanted to. ChromeOS seems to be rather an odd choice for a development machine, and if you are not using it for development why would you want to install a DVCS on it? Is this really a common problem? I can appreciate (potentially, anyway) why one might want fossil on a ChromeOS machine, given the ability to do wiki ticket stuff via the web interface. One could do all that stuff while disconnected even if actual code banging was not in progress. -- Scott Robison ___ 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 STASH wish list
On Apr 30, 2015 8:21 AM, to...@acm.org wrote: To add to the perpetual wish list: Can the STASH [SAVE] command be made to behave similarly to the COMMIT command with respect to comments in the editor? That is, if nothing is typed as stash comments, the stash operation to be aborted. It currently does not allow one to abort, and if you don’t, you end up with a ‘mystery’ stash entry which is kind of useless if you can’t remember what that was about. (Currently, you can of course undo with a STASH POP right after you mess up, and re-do by adding a comment but I think the proposal would save time.) Alternatively, maybe just be able to amend the comment. I don't think forcing a comment is necessary for something that will be very short lived, but I can see your point about utility of a comment in some cases. ___ 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] Limiting HTTP/1.1 host
On Thu, Apr 30, 2015 at 1:27 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Apr 30, 2015 at 2:57 PM, Scott Robison sc...@casaderobison.com wrote: In any case, if they are looking for a machine to exploit, and they request a page from http://1.2.3.4/; instead of http://www.legitimate-domain.com/;, simply dropping the connection could be an effective mitigation strategy. A typical 404 response might include all the information the bad actor needs. Why make their job any easier? Good point. Normally, I would say this is something for a front end webserver to handle. I agree. I wasn't arguing for the feature to be added to fossil necessarily, but I think it is a good idea in general. Just as SMTP servers have become more strict in their desire to thwart spam, perhaps it is time to think about web servers becoming more strict for related though not identical reasons. A lot of information potentially leaks even through a negative response. Usually I setup my web servers to redirect any bad request to a good request. This makes sense for truly public servers that are trying to spread information as far and wide as possible. For something that is online only for convenience (such as a private fossil repo)? The less info out there the better. While there are those that might stone me for suggesting this, this might be a better idea in some cases than even a 404. Not just dropping the connection for a bad host name, but dropping the connection for a not found. Given how many hits I get on my non-wordpress site for wordpress login pages, I wonder if this might be a good idea. But it's not directly related to fossil, so I'll drop it here. -- Scott Robison ___ 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] Limiting HTTP/1.1 host
On Thu, Apr 30, 2015 at 11:36 AM, Ron W ronw.m...@gmail.com wrote: On Thu, Apr 30, 2015 at 10:36 AM, Andy Goth andrew.m.g...@gmail.com wrote: Seems I have a lot of people trying to access my repository who have no business doing so: I'd like to limit access based on the HTTP/1.1 Host: header. If Host: isn't un.is-a-geek.com or un.is-a-geek.com. (note final period) then just drop the connection. The HTTP Host header field is the name of targeted server, not the client's host. This field is used to support virtual hosting. True, but I can see the utility of the request. If someone is looking for an exploitable host, they probably haven't built a table of every host name that maps to that address. They might have one host name, or more likely they only have an IP address. In any case, if they are looking for a machine to exploit, and they request a page from http://1.2.3.4/; instead of http://www.legitimate-domain.com/;, simply dropping the connection could be an effective mitigation strategy. A typical 404 response might include all the information the bad actor needs. Why make their job any easier? -- Scott Robison ___ 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 Tue, May 12, 2015 at 5:05 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 5/12/2015 3:38 PM, Warren Young wrote: The OP said that each of his clients has artifacts in the repository that can’t be shared with other sub-sections of the repository, for unspecified reasons. He also talked about a shared code base. That’s an N+1 situation. Let me make a correction here. I am not the OP. That would be Abilio Marques. I amplified his points to show that there is some interest in a way to add some finer-grained protection to Fossil. In my view, the scripting mechanism may be the way to do it so the specifics of the implementation are given over to the administrator. The unspecified reasons are ITAR regulations and the like. They don't have to make sense because they flow down from government. I would prefer to not discuss them further. drh and I had a private conversation on this subject several years ago. This is more of a generic reply to the thread rather than a specific comment on a particular recent entry. While I agree that there is certainly utility in finer grained permissions, the biggest problem I see is enforcing those technical constraints in a DVCS. Even if we accept as a given that it would not be too difficult to build in scripting logic that could ensure people do not commit to particular threads (or do any of the other fine grained things that have been discussed), the difficult part comes in the sync, since they only deal with artifacts. Once someone clones the repo, they have full access to that copy to do with as they please. To make finer grain permissions ultimately useful: 1. The initial clone would have to include not just the artifacts but some minimal subset of configuration data to ensure the user can't violate policies. 2. Disallow the user from making changes in the clone that would disable the configuration data from step 1. 3. Disallow / report to the user any violations while performing local only commands. 3. Disallow / report on any push or sync that results in violations. None of these are impossible obstacles to overcome, but taken together as a whole they do mean there is a significant amount of work to be done to ensure policies are enforced, because the first time a policy is not enforced for any reason at all, people will cry bug. From that point of view I can appreciate why people are hesitant to try to implement something like this. If fossil were a CVCS like svn (or could be configured for a similar use case), it would be easier to enforce these types of permissions. -- Scott Robison ___ 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 Tue, May 12, 2015 at 9:27 PM, Warren Young w...@etr-usa.com wrote: On May 12, 2015, at 5:51 PM, Scott Robison sc...@casaderobison.com wrote: the difficult part comes in the sync, since they only deal with artifacts. Once someone clones the repo, they have full access to that copy to do with as they please. I’m not so sure about that. I think all that is required is for the access tags to be checked on both check-in and on sync. All that is required. Just a trifling! ;) But seriously, that *is* the complicated part. It involves refactoring a fair amount of code so that it can be used in both places *or* it involves duplicating code so that the same checks can be done in both places. That's why it is the difficult part. Anyway, I’m still against this feature in principle, because I think it tries to invent new mechanisms where they aren’t strictly needed. But, it’s a fun design problem. :) I'm not against it. Just stating *why* it would be difficult. As has been pointed out, there are many features that aren't strictly needed depending on just how strict one wants to be. Heck, why am I using VCS software instead of just keeping my own periodic backups in zip files? It just complicates things! Except for when it doesn't, just as some would find this sort of functionality advantageous for their use case. -- Scott Robison ___ 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] terminology confusion
On Thu, Apr 16, 2015 at 1:27 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Apr 16, 2015 at 2:41 PM, Andy Bradford amb-fos...@bradfords.org wrote: This document contains what Fossil considers a fork: https://www.fossil-scm.org/index.html/doc/trunk/www/branching.wiki Yes. And the _connotation_ of the term fork within the Fossil community is unintended/accidental commit to a parent commit with other child commits. My point is that Fossil uses the term fork differently from many other many other open source projects. Examples: Devuan is a fork of Debian, Inkscape is a fork of Sodapodi, etc. Or, how Github uses it to mean a contributor's clone. Some thoughts: If a unique term is required, how about calling an undesirable branch a twig. ;) More seriously, the Wikipedia article on forking is probably worth a read: http://en.wikipedia.org/wiki/Fork_(software_development) I would claim that github is the odd man out here, having appropriated a term that historically meant something undesirable and changing it into an intended desirable part of the software development process. Mind you, forking in a github sense doesn't have to mean project branch with future pull requests though obviously that's how they intend it. A github fork is really just a heavyweight branch, and until github was launched in 2008 (assuming their fork functionality was an original concept introduced at launch) no one in the world used fork in this sense. Looking at the list of DVCS projects on Wikipedia, it means every notable DVCS was introduced prior to that usage (except for Veracity, which is apparently / arguably dead anyway). I don't think github's success devolves on anyone else to change their terminology any more than I think git's success means that everyone should adopt their confusing hodge podge mass of commands options. In fact, from this point of view, github redefining terminology is unsurprising given how I feel about git's use of terminology in places. Given the traditional meaning of fork (an undesirable branch of development that, if allowed to remain, limits future development options in some way), I don't see that there is a real problem continuing to use the term fork. Introducing a new non-obvious term just so there is distinct separation between fossil forks and github forks seems to only complicate the understanding of fossil. Note that undesirable branch of development could apply to how fossil uses fork, or how github might use fork in the case that the original project never pulls anything back so the two projects diverge, or how BSDs or emacs/xemacs forked deliberately. Accidental head or accidental branch don't seem to apply if for no other reason a fork *can* be deliberate. That's not the norm but --allow-fork does exist as an option for those cases when fossil can detect a fork will happen but to allow it anyway. I suspect most people don't type --allow-fork accidentally (when they type it at all). :) So, if we *must* have a unique term, I'd vote for twig as I've never heard it used in a dvcs context and can't find such a reference via Google. Mind you, if we started using twig there is nothing to stop github (or others) from coming along and appropriating the terminology, so we could wind up right back in this position seven years down the road. Or we just continue to document what we mean when we use the term fork (perhaps providing the extra text two leaves on the same branch or some such when a fork warning is generated) and continue to provide the existing tools to merge or rename. -- Scott Robison ___ 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] terminology confusion
On Thu, Apr 16, 2015 at 2:58 PM, Ron W ronw.m...@gmail.com wrote: On Thu, Apr 16, 2015 at 4:30 PM, Scott Robison sc...@casaderobison.com wrote: Some thoughts: More seriously, the Wikipedia article on forking is probably worth a read: http://en.wikipedia.org/wiki/Fork_(software_development) I would claim that github is the odd man out here, having appropriated a term that historically meant something undesirable and changing it into an intended desirable part of the software development process. Certainly, Github's use of fork is different that saying Devuan is a fork of Debian. As to whether a fork is undesirable depends on point of view. I am willfully ignorant regarding the Debian people's opinions of Devuan. I will, however, admit that I think the Inkscape fork of Sodapodi benefited me, I'd never heard of Devuan before today. I am familiar with the other examples quoted from ESR: Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs http://en.wikipedia.org/wiki/GNU_Emacs/XEmacs http://en.wikipedia.org/wiki/XEmacs split, the fissioning of the386BSD http://en.wikipedia.org/wiki/386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore. It's not that no one benefits from a traditional project fork. Someone must or no one would ever go to the effort. But they often come at a high price in hours spent keeping up with the other project, or incompatible drift between two projects which is potentially hard on the community. Even though there are benefits to the project fork there are also undesirable side effects. Pros Cons. In the case of the branch fork that fossil describes, the negative is the time it takes to merge the two back into one branch, or to rename one of the forks so that it becomes its own branch. Certainly learning about forks as early as possible so that they can be addressed appropriately is beneficial to a project. Maybe calling it a branch fork or forked branch might be adequate terminology. Accidental head or accidental branch don't seem to apply if for no other reason a fork *can* be deliberate. That's not the norm but --allow-fork does exist as an option for those cases when fossil can detect a fork will happen but to allow it anyway. I suspect most people don't type --allow-fork accidentally (when they type it at all). :) In my experience, a fork results when I or one of my teammates forgets to start a new branch. So, from our perspective, accidental is very applicable. Even with fossil forks, such an undistinguished branch would be easy to loose track of. I would not want to create a fork. Agreed, a deliberate fork would likely be quite rare. I was only saying it is possible so accidental branch is not perfectly descriptive. So, if we *must* have a unique term, I'd vote for twig as I've never heard it used in a dvcs context and can't find such a reference via Google. Mind you, if we started using twig there is nothing to stop github (or others) from coming along and appropriating the terminology, so we could wind up right back in this position seven years down the road. I'm not saying _must_. I only want to point out that it could be a non-trivial obstacle to adoption for Fossil for some people. Sorry, I should have included a smiley in there somewhere. While part of me does like the idea of using twig as a term somewhere just because it's amusing, I did mean it tongue in cheek. I still think fork is the right term. Fossil's use of it predates the later redefinition by github. The software development industry use of it predates github. If anything, change displayed instances of fork to forked branch or fork [two leaves on the same branch]. In fact, as I think more about it, forked branch would be sufficiently clear that it's not a github fork (a forked project if you will) while alerting the person reading the text that something different from the normal flow has occurred. Assuming they read it at all, anyway. -- Scott Robison ___ 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] Merge - including files from other branches - best practice?
On Thu, Apr 16, 2015 at 8:15 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Scott Robison on Thu, 16 Apr 2015 16:36:59 -0600: It is by design. Merging isn't always intuitive, and certainly there could be a bug in it. Perhaps like this one: http://fossil.bradfords.org:8080/info/b1e9974a37c648fe Why was that merge essentially a no-op? Partly I think it is because your test case consists of a single file of a single line, which means probably (I would think) every merge resulted in a conflict that you had to resolve manually. Here is what I think is happening: [1413f8301f] on trunk leads to [793622de13] on newbranch leads to [2b0c514af3] on newbranch [ec781a493d] on trunk At this point trunk is merged into newbranch resulting in [d228092800]. There had to have been a conflict and the merge was resolved as taking the line from trunk, not newbranch. At this point newbranch has a single file with a single line that came from trunk. There are 5 more commits before [b1e9974a37] which merges newbranch back into trunk, and since newbranch came from trunk during conflict resolution, the nearest common ancestor came from trunk, so trunk wins. Effectively, the line from newbranch was deleted and the line from trunk was inserted, so by the time of the merge there is nothing new or changed in newbranch to merge into trunk. Note that I have not deconstructed and played back all these changes. I have looked at all of the commits though and this is the best I think one can expect a merge algorithm to do with the lines in question. -- Scott Robison ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
