[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] ERROR: file is different on disk compared to the repository during commit
On Friday, August 24, 2012 10:35 PM, Richard Hipp wrote: Fossil keeps track of which files have changed (by default) by looking at the file size and the mtime. If neither the file size nor the mtime have changed, fossil (by default) assumes that the content of the file is also unchanged. Perhaps your edit somehow preserved both the file size and mtime and so Fossil didn't realize that the file had been editing as it started the commit. If that ever happens, you can always fix it by doing: fossil status --sha1sum You can also do fossil setting mtime-changes off and afterwards Fossil will always check the complete file content rather than relying on the mtime and file size. That will be a little slower, but it avoids confusion such as the above. Thanks for the pointers, I've managed to get a commit through! I've looked a little more into how the problem came about: I had merged a branch into trunk, then modified quite a number of the files prior to commit. Among these, one was a new file created during the branch. This one was modified but fossil status showed ADDED_BY_MERGE rather than EDITED. What didn't help was that it was modified, not by hand but by overwriting it with a copy from a backup folder -- this meant that it had a timestamp older than the version merged by fossil (but you were right: by coincidence, the file size *was* the same). (So when I said, I'd not done anything out of the ordinary, I'm afraid I was not so accurate -- I had forgotten all these things, my apologies!) So, anyway, I tried your suggestion re fossil status --sha1sum but this didn't work. I also tried touching the file to give it a more recent timestamp -- this also didn't work. I also tried the fossil setting... but this didn't help directly (but I've left it on for the future!). I also tried modifying the file in a random location (not totally random, but one of the changes made, I un-made), but this didn't cause fossil to realise the file had been modified -- this surprised me. I then modified the *first* line of the file, and then did a fossil status and *now* the file was marked as EDITED so I unmodified the first line, and was able to make the commit without error. So, thanks again for the help: I know what to do next time! (as does anyone else who stumbles across this thread with the same problem!) I am certainly glad of the backup check, though, since otherwise I may have ended up with an incorrect commit and never realised :o) Cheers Andy ___ 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
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
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
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
