Re: [fossil-users] Merging two leaves not on the same graph?
2014-05-08 19:26 GMT+02:00 Stephan Beal sgb...@googlemail.com: It's funny you say that because in libfossil i've had to go back and reexamine my 0 semantics, and let them be legal (empty repo) in some cases, but stand for the current checkout in others (where 0 otherwise makes no sense). Negatives are always invalid, but 0 has a few uses. In some cases, there's a small bit of extra handling for rid 0, but nothing tragic. Well, I did some more tests, creating an empty repository and one with a single non-empty initial commit: http://fosclipse.sourceforge.net/cgi-bin/empty/stat http://fosclipse.sourceforge.net/cgi-bin/one/stat Everything works just fine. Even fossil export --git works: $ fossil export --git one.fossil blob mark :4 data 6 hallo commit refs/heads/trunk mark :3 committer jan.nijtmans jan.nijtmans 1400010155 + data 9 hallo.txt deleteall M 100644 :4 hallo.txt And I can succesfully import it back into fossil, getting back the same single-non-empty-initial-commit repository. Sounds like a plan :) The plan worked! After Andy managed to trigger a bug in unsaved_changes() it was successfully reverted. Bug was later fixed in trunk. [http://fossil-scm.org/index.html/info/f7d9413ccf] Since GIT can handle non-empty initial check-in's just fine, is that enough reason for fossil to allow it as well? ;-) Anyway, I would like to execute the same plan (merge branch no-initial-commit to trunk) once more. If anyone thinks this is a bad idea (maybe because another bug prevents us to do that), I'm all ears. 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
Re: [fossil-users] Changing file name and creating old file name at same time causes potential problem
On Wed, May 14, 2014 at 2:43 AM, Andy Bradford amb-fos...@bradfords.orgwrote: Indeed it didn't include foo.txt, so it silently removed foo.txt from the checkin. It picked up the rename from 03764343bf2b76127272b251db39498f61ac31c1 and it should have included the foo.txt from the same but didn't for some reason. (i'm speculating here based on prior peeks at that code...) 'mv' (for reasons i do not understand) sets vfile.origname=vfile.pathname where vfile.origname IS NULL (that caused me a bit of greif in libfossil, as i have to work around it in several places). i _suspect_ that the vfile table is ending up with two entries with the name foo.txt in origname, and that that is confusing it. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] committing wiki pages changes format parser
On Tue, May 13, 2014 at 9:27 PM, Chad Perrin c...@apotheon.net wrote: On Tue, May 13, 2014 at 09:55:10AM +0200, Stephan Beal wrote: Doh - you can't currently. The shell mode export/import was added _long_ before other formats were supported, and it's not aware of them. i've added that to the TODO list. Thanks. I look forward to that going away. Would this strategy server your purpose: - add a (-format FORMAT) option to (wiki commit). - if no format is specified, use the format from the prior version (if there is one), defaulting to fossil-wiki if no prior version is set or the prior version has no explicit format. :-? While I'm at it . . . how do I stop changes saved from the web interface from inserting a bunch of MS Windows style ^M CRLF character garbage at the end of every line when I check out a wiki file locally for editing in a text editor? That's new to me - i don't recall ever having seen that. Is there any other information I could provide that might help narrow down the source of the problem? I'm currently at kind of a loss. The local install of Fossil is 1.28 built from ports on FreeBSD. The remote install is 1.26 built from downloaded sources on a Linux-based webhosting platform (though I expect to move that to a FreeBSD VPS, with Fossil installed from ports and thus more up to date, soon). Martin G. has reproduced this on a different *ix flavour, so it seems to be independent of the platform (and the wiki bits have no platform-dependent code). i don't have a suspicion at the moment, but that particular problem is also _way_ down on my list of things to do :/. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] committing wiki pages changes format parser
On Wed, May 14, 2014 at 5:55 PM, Stephan Beal sgb...@googlemail.com wrote: Would this strategy server your purpose: - add a (-format FORMAT) option to (wiki commit). - if no format is specified, use the format from the prior version (if there is one), defaulting to fossil-wiki if no prior version is set or the prior version has no explicit format. That comes out looking something like: [stephan@host:~/tmp/x]$ f-wiki ls Time (local time)UUID Size Name 2014-05-14 18:26:05 00620a7da105 324Hosts [stephan@host:~/tmp/x]$ f-acat 00620a7da105 ... N text/plain ... [stephan@host:~/tmp/x]$ echo 'test 3' Hosts [stephan@host:~/tmp/x]$ f wiki commit Hosts Hosts --format text/x-markdown Updated wiki page Hosts. [stephan@host:~/tmp/x]$ f-wiki ls Time (local time)UUID Size Name 2014-05-14 18:27:36 d90d62fe747d 331Hosts [stephan@host:~/tmp/x]$ f-acat d90d62fe747d | grep '^N ' N text/x-markdown [stephan@host:~/tmp/x]$ echo 'test again' Hosts [stephan@host:~/tmp/x]$ f wiki commit Hosts Hosts # NOTE: no --format specified Updated wiki page Hosts. [stephan@host:~/tmp/x]$ f-wiki ls Time (local time)UUID Size Name 2014-05-14 18:28:57 a79e55d52c33 342Hosts [stephan@host:~/tmp/x]$ f-acat a79e55d52c33 | grep '^N ' N text/x-markdown i need to test this a bit more before committing, and would like to consider adding a filter which rejects any unknown mime types (but i'm not sure that's such a good idea because i have uses for non-canon mime types via the JSON API... btw, the JSON API now has a flat for setting the mime type, too). :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] committing wiki pages changes format parser
On Wed, May 14, 2014 at 6:33 PM, Stephan Beal sgb...@googlemail.com wrote: i need to test this a bit more before committing, and would like to consider adding a filter which rejects any unknown mime types (but i'm not sure that's such a good idea because i have uses for non-canon mime types via the JSON API... btw, the JSON API now has a flat for setting the mime type, too). s/flat/flag/ Okay, that's what branches are for... if you would please try out this: http://fossil-scm.org/index.html/timeline?r=wiki-keep-mimetype and see if that suits you (and doesn't break anything ;)? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Changing file name and creating old file name at same time causes potential problem
Thus said Stephan Beal on Wed, 14 May 2014 17:47:43 +0200: 'mv' (for reasons ido not understand) sets vfile.origname=vfile.pathname where vfile.origname IS NULL (that caused me a bit of greif in libfossil, as i have to work around it in several places). i _suspect_ that the vfile table is ending up with two entries with the name foo.txt in origname, and that that is confusing it. This is the first time I've looked at the merge code and it appears to be doing things correctly with respect to the MERGE/RENAME of foo.txt to foobar.txt, but it doesn't then handle the new foo.txt as a new file to be ADDED. I'm not sure if that's because the rid is missing from the fv table or if it just doesn't know how to identify it due to the name being the same. Andy -- TAI64 timestamp: 40005373b564 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Excluding [brackets] from a.../a links
I'd like for the [bracket] characters to not be part of the a.../a links in Fossil web pages, at least when the link text is an artifact ID. This change would make it easier to highlight just the artifact ID and omit the brackets so that I can paste it elsewhere without having to then delete the brackets manually. Most web browsers make it very hard to start highlighting in the middle of link text, as they choose to interpret that as dragging an object. Any thoughts? -- Andy Goth | andrew.m.goth/at/gmail/dot/com ___ 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] Excluding [brackets] from a.../a links
On Wed, May 14, 2014 at 8:38 PM, Andy Goth andrew.m.g...@gmail.com wrote: elsewhere without having to then delete the brackets manually. Most web browsers make it very hard to start highlighting in the middle of link text, as they choose to interpret that as dragging an object. Any thoughts? i think it just might look nicer, too. i'm looking at a timeline now and imagining what it would look like if the brackets we not part of the link... yeah, i can see that. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Excluding [brackets] from a.../a links
On Wed, May 14, 2014 at 2:38 PM, Andy Goth andrew.m.g...@gmail.com wrote: I'd like for the [bracket] characters to not be part of the a.../a links in Fossil web pages, at least when the link text is an artifact ID. This change would make it easier to highlight just the artifact ID and omit the brackets so that I can paste it elsewhere without having to then delete the brackets manually. Most web browsers make it very hard to start highlighting in the middle of link text, as they choose to interpret that as dragging an object. I've encountered the problem you mentioned about highlighting, but admit I'm not sure if I'd like to see the brackets go away. I almost think it would still look cleaner with them present. That said, I'd love if somebody could assemble a side-by-side image showing the difference, as I admit my curiosity is piqued as to how it would actually look. :) - joe ___ 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] Excluding [brackets] from a.../a links
Andy, to be clear, are you suggesting: a) blah blah [a href=somethingcafebabe/a] blah blah blah b) blah blah a href=somethingcafebabe/a blah blah blah ? -bch On 5/14/14, Joseph Prostko joe.pros...@gmail.com wrote: On Wed, May 14, 2014 at 2:38 PM, Andy Goth andrew.m.g...@gmail.com wrote: I'd like for the [bracket] characters to not be part of the a.../a links in Fossil web pages, at least when the link text is an artifact ID. This change would make it easier to highlight just the artifact ID and omit the brackets so that I can paste it elsewhere without having to then delete the brackets manually. Most web browsers make it very hard to start highlighting in the middle of link text, as they choose to interpret that as dragging an object. I've encountered the problem you mentioned about highlighting, but admit I'm not sure if I'd like to see the brackets go away. I almost think it would still look cleaner with them present. That said, I'd love if somebody could assemble a side-by-side image showing the difference, as I admit my curiosity is piqued as to how it would actually look. :) - joe ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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] Excluding [brackets] from a.../a links
On Wed, May 14, 2014 at 11:22 PM, B Harder brad.har...@gmail.com wrote: Andy, to be clear, are you suggesting: a) blah blah [a href=somethingcafebabe/a] blah blah blah My comments assumed this interpretation. To my eyes that looks a tiny bit cleaner, but i won't argue strongly one way or the other. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do. -- Bigby Wolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Excluding [brackets] from a.../a links
That's what I was imagining/hoping too, but I'm not sure if that was original proposal. I like the way the [ ] set off the string we care about, but then I wondered if the ease of select/copy was because the brackets were completely eliminated. -bch On 5/14/14, Stephan Beal sgb...@googlemail.com wrote: On Wed, May 14, 2014 at 11:22 PM, B Harder brad.har...@gmail.com wrote: Andy, to be clear, are you suggesting: a) blah blah [a href=somethingcafebabe/a] blah blah blah My comments assumed this interpretation. To my eyes that looks a tiny bit cleaner, but i won't argue strongly one way or the other. -- - 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 -- Brad Harder Method Logic Digital Consulting http://www.methodlogic.net/ http://twitter.com/bcharder ___ 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] Excluding [brackets] from a.../a links
Stephan Beal wrote: On Wed, May 14, 2014 at 11:22 PM, B Harder brad.har...@gmail.com mailto:brad.har...@gmail.com wrote: Andy, to be clear, are you suggesting: a) blah blah [a href=somethingcafebabe/a] blah blah blah My comments assumed this interpretation. To my eyes that looks a tiny bit cleaner, but i won't argue strongly one way or the other. This is also how I interpreted it, and also what I support doing. Copy/pasting artifact IDs has annoyed me before, as well. ___ 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] Excluding [brackets] from a.../a links
I have the same annoyance with scrape 'n paste. Would adding a space between the [ or ] and the hex string alleviate the annoyance but still provide the visual delineation? On Wed, May 14, 2014 at 2:58 PM, Joel Bruick j...@joelface.com wrote: Stephan Beal wrote: On Wed, May 14, 2014 at 11:22 PM, B Harder brad.har...@gmail.com wrote: Andy, to be clear, are you suggesting: a) blah blah [a href=somethingcafebabe/a] blah blah blah My comments assumed this interpretation. To my eyes that looks a tiny bit cleaner, but i won't argue strongly one way or the other. This is also how I interpreted it, and also what I support doing. Copy/pasting artifact IDs has annoyed me before, as well. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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] Excluding [brackets] from a.../a links
Thus said Matt Welland on Wed, 14 May 2014 16:08:50 -0700: I have the same annoyance with scrape 'n paste. Would adding a space between the [ or ] and the hex string alleviate the annoyance but still provide the visual delineation? I think the problem isn't the amount of space between the [] and the UUID, but rather that most browsers cannot handle copy selection of text that is part of an anchor tag. Adding space wouldn't make it easier because the space would still be part of the ``link.'' Placing the [] outside of the a anchor tag is what I believe is proposed to make it easier to copy/paste. Honestly, I'm surprised that modern browser makers haven't figured out that copy selection of just a portion of the anchor text is actually a desirable feature! Andy -- TAI64 timestamp: 400053740286 ___ 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] Excluding [brackets] from a.../a links
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/14/2014 2:05 PM, Joseph Prostko wrote: I've encountered the problem you mentioned about highlighting, but admit I'm not sure if I'd like to see the brackets go away. I didn't suggest removing them from the display, only making them be outside of the clickable link. Current : a href=whatever[foo]/a Proposed: [a href=whateverfoo/a] - -- Andy Goth | andrew.m.goth/at/gmail/dot/com -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTdCISAAoJELtYwrrr47Y49FgIAJM34akBSiqNcdb7/hrjBYhY VpFNTi9xxQuKBujW2/zS1imQ5aT2aTGxxWPQ5rOXmpehX68BrzY0/pe+/kmX0SPk ozN92Pm7r7/t3prWuqv1cS2pmSCALHHRWGFzgAWNRvkvChw97OVNvbhYyQVosXVh QI+f4WB61/4CZH+4eqfrVD1T9ygqWbixr/qnGdpJYZlGUV6GSnZ7qJG/20oRsMq6 cbFdHjtME4rzZGHokAuvwQ8Z9qWTCnfVtp0WeX9aOjudWwSK+f0e40VVpFOoEHAU 10JrYIRbS395pjdeNsK4aWC6WKzcS31Sf2K6ewcxhT00Y+FNZXt2GSSt634PxzY= =FuNl -END PGP SIGNATURE- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Excluding [brackets] from a.../a links
On Wed, May 14, 2014 at 10:10 PM, Andy Goth andrew.m.g...@gmail.com wrote: On 5/14/2014 2:05 PM, Joseph Prostko wrote: I've encountered the problem you mentioned about highlighting, but admit I'm not sure if I'd like to see the brackets go away. I didn't suggest removing them from the display, only making them be outside of the clickable link. Current : a href=whatever[foo]/a Proposed: [a href=whateverfoo/a] Indeed, I admit I got confused by Stephan's initial response, which actually said exactly what you suggested initially. I might have to work on my reading comprehension skills, as I think it started a cascade confusing everyone else. I definitely like your suggestion and wouldn't mind it being suggested. In fact, I think I would prefer it. - joe ___ 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] Excluding [brackets] from a.../a links
On Wed, May 14, 2014 at 10:59 PM, Joseph Prostko joe.pros...@gmail.com wrote: suggested. In fact, I think I would prefer it. suggested = implemented I think I better head to sleep before I type anything else nonsensical today. I was going to come up with a patch for this, but I think I better call it a night before I cause any more trouble. :) - joe ___ 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] Merging two leaves not on the same graph?
Thus said Jan Nijtmans on Wed, 14 May 2014 12:11:42 +0200: Anyway, I would like to execute the same plan (merge branch no-initial-commit to trunk) once more. If anyone thinks this is a bad idea (maybe because another bug prevents us to do that), I'm all ears. I did some minimal testing to confirm that the previously identified problems no longer exist. I also tried cloning the empty repository and that worked both with old and the no-initial-commit version. Of course I was unable to commit with old versions (unless the particular bug fixed by [f7d9413ccf] was triggered). I don't imagine that a newly created fossil will have 0 checkins for long. Anything else need looking at? Andy -- TAI64 timestamp: 4000537446d7 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] WAL mode vs other modes?
Hello, I recently noticed that if I hit /stat on my own repositories it shows ``delete mode'' in the Database Stats, but on www.fossil-scm.org it shows ``wal mode.'' I assume this is to leverage some of the benefits listed here: https://www.sqlite.org/draft/wal.html I suppose it can be enabled just using the sqlite interface? Can this actually improve the number of locking contentions that might exist for a given fossil? Just curious. Thanks, Andy -- TAI64 timestamp: 4000537447e5 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
