Re: [fossil-users] working checkout does not match what would have ended up in the repository
2014-05-30 22:25 GMT+02:00 Stephan Beal sgb...@googlemail.com: On Fri, May 30, 2014 at 10:15 PM, Stephan Beal sgb...@googlemail.com wrote: H. It seems fossil no longer has an option to create the initial checkin, and i can't figure out how to create one without libfossil: There are currently 3 ways to create a repository with initial checkin: 1) fossil new foo.fossil --date-override now 2) fossil new foo.fossil 3) fossil new foo.fossil --empty fossil commit -m my initial commit The latter has the advantage that any comment can be specified, and doing fossil add beforehand allows the first commit to be non-empty. 2014-05-31 19:07 GMT+02:00 Joel Bruick j...@joelface.com: I hope so. The commit I backed out seems to serve no purpose besides messing up vfile_aggregate_checksum_disk() . Instead, all added files were being included in the checksum, which was causing it to not match the repository checksum. You are absolutely right! Thank you for fixing this! This commit was an ill-thought to fix the checksum mismatch, but the real fix for the problem was done later: [http://fossil-scm.org/index.html/info/f7d9413ccf] Did a little testing, and everything appears to work fine now. For what it's worth, count me among those who would like to see this feature remain, even if it isn't the default. I would also prefer --empty being the default in fossil new: Whether there is an initial empty commit or not, all operations should function the same after all. It would mean that there only two ways left to create a repository with an initial empty commit, in stead of currently 3. It is unfortunate that some corner-cases were discovered violating that, but that's life. I understand the frustration that a new feature unveils longstanding 'bugs' (which were impossible to trigger before, so whether they are bugs can be disputed). 2014-05-31 21:40 GMT+02:00 Stephan Beal sgb...@googlemail.com: Thank you very much to Michai for the report and the other devs for the testing, patching, and verification. Seconded. And thanks very much to Stefan for taking this while I had a long free weekend. I hope many people will test fossil new --empty whenever they create a new repository. 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] working checkout does not match what would have ended up in the repository
On 31 May 2014 21:40, Stephan Beal sgb...@googlemail.com wrote: On Sat, May 31, 2014 at 4:33 PM, Stephan Beal sgb...@googlemail.com wrote: Once i'm back from shopping i'll work on a patch which reverts to ... i've implemented the above. It looks something like: ... Thanks a lot. As you already suggested, initial checkin now being the default again, the initial-checkinless feature will probably receive precious little testing, let alone from new users. /obvious Michai ___ 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] working checkout does not match what would have ended up in the repository
On Sun, Jun 1, 2014 at 9:26 AM, Michai Ramakers m.ramak...@gmail.com wrote: Thanks a lot. As you already suggested, initial checkin now being the default again, the initial-checkinless feature will probably receive precious little testing, let alone from new users. /obvious It will from me, because libfossil doesn't require an initial commit (which is where this feature idea originally derived from). :) When libf got to the point that it was possible to create commits, i realized that the initial empty commit is (and here's the summary Brad posted about...) is not a technical requirement, but a historical decision which led to downstream assumptions which break once the initial checkin is missing. In short, the first checkin seeds the blob table with a starting point from which all further work can derive, and much code has historically assumed that that seed is in place. That assumption was correct until the removal of the initial commit. The case you saw was directly related to that, and there may still be an open corner case or two, but none that i'm aware of. For libfossil, as a library, (less so for fossil, as an app) it's important (philosophically, not technically) that the client be able to specify their own initial commit, in the same way that an empty sqlite3 (as a library) doesn't add any client-visible tables/data other than the internal-use sqlite_master table. Cryptic side-notes and trivia about repos with no initial commit: - historically, the first blob (aka rid 1) was always the initial empty commit (the seed), but.. - In a wiki-only repo, the first blob will likely be a wiki page. Likewise for ticket-only repos - the first blob will be a ticket. Likewise for Events. - Insofar as i can determine, it is impossible to add CONTROL artifacts to an empty repo (because such artifacts are there to add tags to other artifacts, which the repo does not have at this point), with the exception of creating one which adds tags which refer only to the control artifact itself (which would be kind of useless). In libf one can add arbitrary tags to a checkin as part of that commit, but fossil's CLI only supports adding a specific subset of tags to the checkin's manifest (branch + bgcolor). In both libf and fossil, tags can be added post facto to arbitrary checkins. -- - 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] working checkout does not match what would have ended up in the repository
On 31 May 2014 02:14, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Michai Ramakers on Fri, 30 May 2014 21:06:36 +0200: michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e Looks like this is due to the recent addition of the empty initial checkin in [cac91b6cd17ab746]: $ fossil bisect bad bisect complete 2 BAD 2014-05-30 18:12:29 52d242a73be2d7d6 3 BAD 2014-05-24 06:27:01 a74d100a121219b8 4 BAD 2014-05-22 04:39:11 941ead2f9ad6f9ca 5 BAD 2014-05-19 09:56:31 c543079b87ce4b6c 6 BAD 2014-05-19 09:16:20 c060947196baef2d 7 BAD 2014-05-19 07:38:04 cac91b6cd17ab746 8 CURRENT 2014-05-19 07:38:04 cac91b6cd17ab746 1 GOOD2014-05-14 16:05:34 ec44f61a831e4225 It's easy enough to reproduce. Create a new empty repository. Add 2 files but only try to checkin 1 of them. Ok, that reproduces very well here! I have been trying here as well, creating repo, adding file, varying things, but to no avail. Sure enough, checking in all added files at once for the original repo worked like a charm. Michai ___ 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] working checkout does not match what would have ended up in the repository
On Fri, May 30, 2014 at 8:14 PM, Andy Bradford amb-fos...@bradfords.org wrote: Looks like this is due to the recent addition of the empty initial checkin in [cac91b6cd17ab746]: Can somebody please explain to me what this change accomplishes, other that introduce needless bugs, which it seems to excel at? What problem does it solve? Why shouldn't we back it out? $ fossil bisect bad bisect complete 2 BAD 2014-05-30 18:12:29 52d242a73be2d7d6 3 BAD 2014-05-24 06:27:01 a74d100a121219b8 4 BAD 2014-05-22 04:39:11 941ead2f9ad6f9ca 5 BAD 2014-05-19 09:56:31 c543079b87ce4b6c 6 BAD 2014-05-19 09:16:20 c060947196baef2d 7 BAD 2014-05-19 07:38:04 cac91b6cd17ab746 8 CURRENT 2014-05-19 07:38:04 cac91b6cd17ab746 1 GOOD2014-05-14 16:05:34 ec44f61a831e4225 It's easy enough to reproduce. Create a new empty repository. Add 2 files but only try to checkin 1 of them. Andy -- TAI64 timestamp: 400053891f13 ___ 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
Re: [fossil-users] working checkout does not match what would have ended up in the repository
Thus said Stephan Beal on Sat, 31 May 2014 16:33:48 +0200: i would personally like to see it kept (mainly for future compatibility with libfossil, which doesn't require an initial checkin ;), but not as the default. The default should stay as it historically has been - creating the hard-coded empty commit. I too like the thought of not having the initial empty commit and it would be nice if this could be kept as the default, but clearly it keeps uncovering bugs. Regarding the error, if I understand the R-card, it seems like the manifest checksum is wrong: $ f ci -n -m one file C one D 2014-05-31T15:23:59.669 F file 2464bdd2457e7e5aba5e76138b6bbb31416bc894 R bd4b079b9dbaf9228c7174fc4675292e T *branch * trunk T *sym-trunk * U amb Z 6ea4a424289a2290fc3c7ca21cbce50c New_Version: 810b64b2111708eeff9de81ec7d105acac158644 working checkout does not match what would have ended up in the repository: bd4b079b9dbaf9228c7174fc4675292e versus a6e841f6bb9977dcec2b00731fe026f4 According to fileformat.wiki, the R-card is computed thusly: $ printf 'file 6\n31081\n' | md5 a6e841f6bb9977dcec2b00731fe026f4 So it would seem that whatever generated the R-card for the manifest got it wrong. Andy -- TAI64 timestamp: 40005389fc09 ___ 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] working checkout does not match what would have ended up in the repository
On Sat, May 31, 2014 at 5:57 PM, Andy Bradford amb-fos...@bradfords.org
wrote:
Regarding the error, if I understand the R-card, it seems like the
manifest checksum is wrong:
$ f ci -n -m one file
F file 2464bdd2457e7e5aba5e76138b6bbb31416bc894
R bd4b079b9dbaf9228c7174fc4675292e
You can actually...
According to fileformat.wiki, the R-card is computed thusly:
$ printf 'file 6\n31081\n' | md5
a6e841f6bb9977dcec2b00731fe026f4
Oh, you did! i was going to suggest looking at that example of a
quick/dirty way to calculate an R-card. But that's not the whole
calculation: you need that line plus the contents of the file. That's why
calculating the R-card is so expensive. See the very, very bottom of:
http://www.fossil-scm.org/index.html/doc/tip/www/fileformat.wiki
Section 9:
# head MF
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
C Make\sthe\sclearsign\sPGP\ssigning\sdefault\sto\soff.
D 2010-02-23T15:33:14
F BUILD.txt 4f7988767e4e48b29f7eddd0e2cdea4555b9161c
F COPYRIGHT-GPL2.txt 06877624ea5c77efe3b7e39b0f909eda6e25a4ec
...
# grep '^R ' MF
R c0788982781981c96a0d81465fec7192
# for i in $(awk '/^F /{print $2}' MF); do \
echo $i $(stat -c '%s' $i); \
cat $i; \
done | md5sum
c0788982781981c96a0d81465fec7192 -
--
- 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] working checkout does not match what would have ended up in the repository
On Sat, May 31, 2014 at 4:33 PM, Stephan Beal sgb...@googlemail.com wrote: On Sat, May 31, 2014 at 1:21 PM, Richard Hipp d...@sqlite.org wrote: Can somebody please explain to me what this change accomplishes, other that introduce needless bugs, which it seems to excel at? What problem does it solve? Why shouldn't we back it out? It doesn't solve a problem so much as open up a minor new feature (the ability to have all commit messages in one's preferred language). i would personally like to see it kept (mainly for future compatibility with libfossil, which doesn't require an initial checkin ;), but not as the default. The default should stay as it historically has been - creating the hard-coded empty commit. Once i'm back from shopping i'll work on a patch which reverts to the previous default behaviour and adds a new flag for those who want to create/play with an empty repo (which still likely has open corner cases involving RID 0). Am i wrong, or did Joel's patch just correct the problem: [stephan@host:~/tmp/x]$ f version This is fossil version 1.29 [1a0179abd7] 2014-05-31 16:37:06 UTC [stephan@host:~/tmp]$ f new x.fsl project-id: 5cd681cb6333f12df80261259e2ddaa456e82742 server-id: ecc9e33b0d4502a2fcc278943a92c6e6888c39f9 admin-user: stephan (initial password is 9b688a) [stephan@host:~/tmp]$ cd x [stephan@host:~/tmp/x]$ f open ../x.fsl project-name: unnamed repository: /home/stephan/tmp/x/../x.fsl local-root: /home/stephan/tmp/x/ config-db:/home/stephan/.fossil project-code: 5cd681cb6333f12df80261259e2ddaa456e82742 checkins: 0 [stephan@host:~/tmp/x]$ for i in a b c; do echo $i $i $i $i $i $i $i $i; done [stephan@host:~/tmp/x]$ l total 44 drwxr-xr-x 2 stephan stephan 4096 May 31 18:47 . drwxr-xr-x 29 stephan users 20480 May 31 18:46 .. -rw-r--r-- 1 stephan stephan14 May 31 18:47 a -rw-r--r-- 1 stephan stephan14 May 31 18:47 b -rw-r--r-- 1 stephan stephan14 May 31 18:47 c -rw-r--r-- 1 stephan stephan 7168 May 31 18:47 .fslckout [stephan@host:~/tmp/x]$ f add a b ADDED a ADDED b [stephan@host:~/tmp/x]$ f com -m egg New_Version: cfb13af168b89e7dfd87dea91c0b831113daf9e0 [stephan@host:~/tmp/x]$ f-ls File list from manifest version 'current' [cfb13af168b8] (RID 3)... UUID P Name 9f2f5f07e932 - a 4e8501912e57 - b [stephan@host:~/tmp/x]$ fst repository-db: /home/stephan/tmp/x.fsl checkout-root: /home/stephan/tmp/x/ checkout-version:cfb13af168b89e7dfd87dea91c0b831113daf9e0 2014-05-31 18:47:37 local (RID 3) user:stephan tags:trunk comment: egg No local changes. :-? -- - 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] working checkout does not match what would have ended up in the repository
On Sat, May 31, 2014 at 6:49 PM, Stephan Beal sgb...@googlemail.com wrote: Am i wrong, or did Joel's patch just correct the problem: For completeness: [stephan@host:~/tmp/x]$ f-acat rid:3 C egg D 2014-05-31T16:47:37.137 F a 9f2f5f07e9326b68b448f9b452a14f63cfadc27c F b 4e8501912e5755546dd0029fe6f248ac6579f2d7 R 2630d0dc71eaa0886e01c234652950df T *branch * trunk T *sym-trunk * U stephan Z a20b80e08c2a8f570e468bb3b4a1c2a2 Nonetheless, i will work on a patch which restores the historical behaviour but adds a flag to the new/init command (--empty?). -- - 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] working checkout does not match what would have ended up in the repository
Stephan Beal wrote: Am i wrong, or did Joel's patch just correct the problem: I hope so. The commit I backed out seems to serve no purpose besides messing up vfile_aggregate_checksum_disk(). Specifically, this part from the function's documentation: ** Newly added files that are not contained in the repository are ** omitted from the checksum if they are not in Global.aCommitFile[]. Instead, all added files were being included in the checksum, which was causing it to not match the repository checksum. For what it's worth, count me among those who would like to see this feature remain, even if it isn't the default. ___ 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] working checkout does not match what would have ended up in the repository
Thus said Stephan Beal on Sat, 31 May 2014 18:49:09 +0200: Am i wrong, or did Joel's patch just correct the problem: Yes, it does appear to correct it: $ ../fossil ver This is fossil version 1.29 [1a0179abd7] 2014-05-31 16:37:06 UTC $ ../fossil info | grep checkins checkins: 0 $ jot -w 'file.%02d' 10 | xargs touch $ ../fossil addremove ADDED file.01 ... added 10 files, deleted 0 files $ ../fossil ci -m test file.01 New_Version: 313c0b705c2d68c3f8e306a36c10ae5c54969b7d Andy -- TAI64 timestamp: 4000538a1988 ___ 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] working checkout does not match what would have ended up in the repository
On 31 May 2014 18:49, Stephan Beal sgb...@googlemail.com wrote: Am i wrong, or did Joel's patch just correct the problem: seems to work here too, with some simple examples. Michai ___ 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] working checkout does not match what would have ended up in the repository
On Sat, May 31, 2014 at 4:33 PM, Stephan Beal sgb...@googlemail.com wrote: Once i'm back from shopping i'll work on a patch which reverts to the previous default behaviour and adds a new flag for those who want to create/play with an empty repo (which still likely has open corner cases involving RID 0). i've implemented the above. It looks something like: Case 1) default == historical behaviour: [stephan@host:~/tmp]$ f new x.fsl project-id: 1b2f0049cacc5543c0bd94f5391a5f37da654557 server-id: a9b94c73c764b0272b625506cd1caf9ec3c4cb4e admin-user: stephan (initial password is 4035d7) [stephan@host:~/tmp]$ f-timeline -R x.fsl checkin [97d18b724311] @ 2014-05-31 21:23:05 by [stephan] branch [trunk] initial empty check-in Case 2) the -empty flag: [stephan@host:~/tmp]$ f new -empty x2.fsl project-id: 64a5cf561773a6198e398219b92b0e7e945831b5 server-id: 1187e5c5a40a03b60f18fb8338f7b4c902b6cedc admin-user: stephan (initial password is 142012) [stephan@host:~/tmp]$ f-timeline -R x2.fsl (no output, i.e. no initial checkin) Case 3) using -date-override, which necessarily forces an initial checkin: [stephan@host:~/tmp]$ f new x3.fsl -date-override '2010-01-01T01:02:03' project-id: d72ec679e5112ce32849ef54a4f16cc48d952455 server-id: 84f6221e355eff37c7edadce3f153cc900825dea admin-user: stephan (initial password is 331321) [stephan@host:~/tmp]$ f-timeline -R x3.fsl checkin [e63f7616798d] @ 2010-01-01 02:02:03 by [stephan] branch [trunk] initial empty check-in Hmmm (unrelated)... timestamp doesn't take into account summer time diff. CET is currently GMT+2. Ah, right... UTC approximately equals GMT w/o winter/summer time changes (IIRC). http://www.fossil-scm.org/index.html/info/3b66804d3f10f9ba23d7f83170b77306905a32e9 Thank you very much to Michai for the report and the other devs for the testing, patching, and verification. And Happy Fossiling, of course! -- - 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] working checkout does not match what would have ended up in the repository
On Sat, May 31, 2014 at 9:40 PM, Stephan Beal sgb...@googlemail.com wrote: [stephan@host:~/tmp]$ f-timeline -R x3.fsl checkin [e63f7616798d] @ 2010-01-01 02:02:03 by [stephan] branch [trunk] initial empty check-in Hmmm (unrelated)... timestamp doesn't take into account summer time diff. CET is currently GMT+2. Ah, right... UTC approximately equals GMT w/o winter/summer time changes (IIRC). That was caused by a short circuit somewhere between my keyboard and chair: [stephan@host:~/tmp]$ f-timeline -R x3.fsl -utc checkin [e63f7616798d] @ 2010-01-01 01:02:03 by [stephan] branch [trunk] initial empty check-in -- - 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] working checkout does not match what would have ended up in the repository
Stephan - i'm on mobile ATM so will be brief, but you and I did discussed this offline weeks ago whereby I thought we agreed that changing the text of the initial commit to something symbolic (.?) or inoffensive Latin (seed , origin) really would fit the bill without rejigging core fossil operations. If you beat me to it, feel free to post the gist of our conversation. I am (and have been) with drh on this: it's sort of silly, and causing much more grief than its worth. At best this should be in a no_origin (or whatever one calls this feature) branch, and hopefully a non-default option if it moves to trunk. On May 31, 2014 7:33 AM, Stephan Beal sgb...@googlemail.com wrote: On Sat, May 31, 2014 at 1:21 PM, Richard Hipp d...@sqlite.org wrote: Can somebody please explain to me what this change accomplishes, other that introduce needless bugs, which it seems to excel at? What problem does it solve? Why shouldn't we back it out? It doesn't solve a problem so much as open up a minor new feature (the ability to have all commit messages in one's preferred language). i would personally like to see it kept (mainly for future compatibility with libfossil, which doesn't require an initial checkin ;), but not as the default. The default should stay as it historically has been - creating the hard-coded empty commit. Once i'm back from shopping i'll work on a patch which reverts to the previous default behaviour and adds a new flag for those who want to create/play with an empty repo (which still likely has open corner cases involving RID 0). -- - 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] working checkout does not match what would have ended up in the repository
Also briefly from the tablet (in bed)... the current impl maintains the historical behaviour by default, while making the new behaviour available via a flag (-empty, though feel free to suggest a name). Will look through my chat logs tomorrow - our discussion was there, i think. (sent from a mobile device - please excuse brevity, typos, and top-posting) - stephan beal http://wanderinghorse.net On Jun 1, 2014 2:11 AM, B Harder brad.har...@gmail.com wrote: Stephan - i'm on mobile ATM so will be brief, but you and I did discussed this offline weeks ago whereby I thought we agreed that changing the text of the initial commit to something symbolic (.?) or inoffensive Latin (seed , origin) really would fit the bill without rejigging core fossil operations. If you beat me to it, feel free to post the gist of our conversation. I am (and have been) with drh on this: it's sort of silly, and causing much more grief than its worth. At best this should be in a no_origin (or whatever one calls this feature) branch, and hopefully a non-default option if it moves to trunk. On May 31, 2014 7:33 AM, Stephan Beal sgb...@googlemail.com wrote: On Sat, May 31, 2014 at 1:21 PM, Richard Hipp d...@sqlite.org wrote: Can somebody please explain to me what this change accomplishes, other that introduce needless bugs, which it seems to excel at? What problem does it solve? Why shouldn't we back it out? It doesn't solve a problem so much as open up a minor new feature (the ability to have all commit messages in one's preferred language). i would personally like to see it kept (mainly for future compatibility with libfossil, which doesn't require an initial checkin ;), but not as the default. The default should stay as it historically has been - creating the hard-coded empty commit. Once i'm back from shopping i'll work on a patch which reverts to the previous default behaviour and adds a new flag for those who want to create/play with an empty repo (which still likely has open corner cases involving RID 0). -- - 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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] working checkout does not match what would have ended up in the repository
Hello, some weirdness I have not seen before: michai@main:~/proj/081/adm$ f changes ADDED time_spent.txt ADDED ../comm/20140530_sent_to_ec/indicator-B_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-B_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator-Edge_Cuts.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator.drl ADDED ../sch/indicator-B_Cu.pho ADDED ../sch/indicator-B_Mask.pho ADDED ../sch/indicator-Edge_Cuts.pho ADDED ../sch/indicator-F_Cu.pho ADDED ../sch/indicator-F_Mask.pho ADDED ../sch/indicator-cache.lib ADDED ../sch/indicator.bak ADDED ../sch/indicator.cmp ADDED ../sch/indicator.drl ADDED ../sch/indicator.kicad_pcb ADDED ../sch/indicator.kicad_pcb-bak ADDED ../sch/indicator.net ADDED ../sch/indicator.pro ADDED ../sch/indicator.sch michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e The file 'adm/time_spent.txt' is 163 bytes. (Googling for the error-message turned up a previous post, where file size was the cause.) Most if not all of the other files give the same error-message. Any idea how to debug this? I am using fossil version 1.29 [87130593e4] 2014-05-26. Michai ___ 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] working checkout does not match what would have ended up in the repository
and... michai@main:~/proj/081$ f timeline +++ no more data (0) +++ This is a brand new repo; indeed there are no checkins. Michai On 30 May 2014 21:06, Michai Ramakers m.ramak...@gmail.com wrote: Hello, some weirdness I have not seen before: michai@main:~/proj/081/adm$ f changes ADDED time_spent.txt ADDED ../comm/20140530_sent_to_ec/indicator-B_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-B_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator-Edge_Cuts.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator.drl ADDED ../sch/indicator-B_Cu.pho ADDED ../sch/indicator-B_Mask.pho ADDED ../sch/indicator-Edge_Cuts.pho ADDED ../sch/indicator-F_Cu.pho ADDED ../sch/indicator-F_Mask.pho ADDED ../sch/indicator-cache.lib ADDED ../sch/indicator.bak ADDED ../sch/indicator.cmp ADDED ../sch/indicator.drl ADDED ../sch/indicator.kicad_pcb ADDED ../sch/indicator.kicad_pcb-bak ADDED ../sch/indicator.net ADDED ../sch/indicator.pro ADDED ../sch/indicator.sch michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e The file 'adm/time_spent.txt' is 163 bytes. (Googling for the error-message turned up a previous post, where file size was the cause.) Most if not all of the other files give the same error-message. Any idea how to debug this? I am using fossil version 1.29 [87130593e4] 2014-05-26. Michai ___ 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] working checkout does not match what would have ended up in the repository
Is the offending file a symbolic link? On Fri, May 30, 2014 at 3:11 PM, Michai Ramakers m.ramak...@gmail.com wrote: and... michai@main:~/proj/081$ f timeline +++ no more data (0) +++ This is a brand new repo; indeed there are no checkins. Michai On 30 May 2014 21:06, Michai Ramakers m.ramak...@gmail.com wrote: Hello, some weirdness I have not seen before: michai@main:~/proj/081/adm$ f changes ADDED time_spent.txt ADDED ../comm/20140530_sent_to_ec/indicator-B_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-B_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator-Edge_Cuts.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Cu.pho ADDED ../comm/20140530_sent_to_ec/indicator-F_Mask.pho ADDED ../comm/20140530_sent_to_ec/indicator.drl ADDED ../sch/indicator-B_Cu.pho ADDED ../sch/indicator-B_Mask.pho ADDED ../sch/indicator-Edge_Cuts.pho ADDED ../sch/indicator-F_Cu.pho ADDED ../sch/indicator-F_Mask.pho ADDED ../sch/indicator-cache.lib ADDED ../sch/indicator.bak ADDED ../sch/indicator.cmp ADDED ../sch/indicator.drl ADDED ../sch/indicator.kicad_pcb ADDED ../sch/indicator.kicad_pcb-bak ADDED ../sch/indicator.net ADDED ../sch/indicator.pro ADDED ../sch/indicator.sch michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e The file 'adm/time_spent.txt' is 163 bytes. (Googling for the error-message turned up a previous post, where file size was the cause.) Most if not all of the other files give the same error-message. Any idea how to debug this? I am using fossil version 1.29 [87130593e4] 2014-05-26. Michai ___ 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
Re: [fossil-users] working checkout does not match what would have ended up in the repository
On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? no: -rw-r--r-- 1 michai users 163 May 30 20:42 time_spent.txt nor are there any symlinks in the path leading to the file or repo. If interested: the repo is about 53 kB; I could mail it for analysis. Michai ___ 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] working checkout does not match what would have ended up in the repository
On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? I don't think it's the contents of this or the other files causing this: michai@main:~/proj/081$ echo kiwi kiwi michai@main:~/proj/081$ f add kiwi ADDED kiwi michai@main:~/proj/081$ f ci -m 'fossil bughunt test' kiwi New_Version: 5cc2d83c0b2621e0c5fc4ebd72caf8dd7c0d3b5e working checkout does not match what would have ended up in the repository: 3e24a53b4cca8ff8caa51c21d04c7705 versus 7bff63ee19686815f2ccd4a072a0c4be Michai ___ 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] working checkout does not match what would have ended up in the repository
On Fri, May 30, 2014 at 3:23 PM, Michai Ramakers m.ramak...@gmail.com wrote: On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? I don't think it's the contents of this or the other files causing this: michai@main:~/proj/081$ echo kiwi kiwi michai@main:~/proj/081$ f add kiwi ADDED kiwi michai@main:~/proj/081$ f ci -m 'fossil bughunt test' kiwi New_Version: 5cc2d83c0b2621e0c5fc4ebd72caf8dd7c0d3b5e working checkout does not match what would have ended up in the repository: 3e24a53b4cca8ff8caa51c21d04c7705 versus 7bff63ee19686815f2ccd4a072a0c4be The proximal cause of the error message is the pre-commit sanity checks that Fossil runs on each check-in. (See http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki for details.) Fossil is looking at the files it is about to commit, and comparing them to the files on disk, and seeing that they do not match. Hence, it aborts the check-in. I do not know what is the root cause of this mismatch, however. Could it be that some other process or thread is changing files in your check-out in the background, as you are trying to commit? -- 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] working checkout does not match what would have ended up in the repository
On 30 May 2014 21:27, Richard Hipp d...@sqlite.org wrote: The proximal cause of the error message is the pre-commit sanity checks that Fossil runs on each check-in. (See http://www.fossil-scm.org/fossil/doc/tip/www/selfcheck.wiki for details.) Fossil is looking at the files it is about to commit, and comparing them to the files on disk, and seeing that they do not match. Hence, it aborts the check-in. I do not know what is the root cause of this mismatch, however. Could it be that some other process or thread is changing files in your check-out in the background, as you are trying to commit? I checked, but there doesn't seem to be anything. If I open in another dir a copy of this repo and try to add a new dummy-file, everything Just Works(tm). I can leave this as-is for a little while, in case there are any other ideas. Michai ___ 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] working checkout does not match what would have ended up in the repository
On Fri, May 30, 2014 at 9:11 PM, Michai Ramakers m.ramak...@gmail.com wrote: michai@main:~/proj/081$ f timeline +++ no more data (0) +++ This is a brand new repo; indeed there are no checkins. *cough* this looks _exactly_ like a bug we had recently involving the rid 0 (no checkins) case. i don't remember the details and i'm about to head off to bed. Maybe someone who remembers this happening about 2-3 weeks back can look into 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] working checkout does not match what would have ended up in the repository
On Fri, May 30, 2014 at 9:23 PM, Michai Ramakers m.ramak...@gmail.com wrote: On 30 May 2014 21:13, Richard Hipp d...@sqlite.org wrote: Is the offending file a symbolic link? I don't think it's the contents of this or the other files causing this: michai@main:~/proj/081$ echo kiwi kiwi michai@main:~/proj/081$ f add kiwi ADDED kiwi michai@main:~/proj/081$ f ci -m 'fossil bughunt test' kiwi New_Version: 5cc2d83c0b2621e0c5fc4ebd72caf8dd7c0d3b5e working checkout does not match what would have ended up in the Is this repo _completely_ empty (no initial checkin)? If so, please recreate it with an initial empty checkin and i'll bet my left leg the problem goes away. If it is _not_ a completely empty repo then i'm at a loss. -- - 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] working checkout does not match what would have ended up in the repository
On 30 May 2014 22:25, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 30, 2014 at 10:15 PM, Stephan Beal sgb...@googlemail.com wrote: Is this repo _completely_ empty (no initial checkin)? If so, please recreate it with an initial empty checkin and i'll bet my left leg the problem goes away. If it is _not_ a completely empty repo then i'm at a loss. H. It seems fossil no longer has an option to create the initial checkin, and i can't figure out how to create one without libfossil: ... I have been reading libfossil progress here, but haven't actually used it yet or played with it. What you say might just be very related - come to think of it, I think this is the 1st repo I create after updating to a recent fossil binary. (I remember seeing the initial checkin changes in the timeline - I think all other repos here are created with older fossil-binaries.) That is worth checking out, thank you. Michai ___ 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] working checkout does not match what would have ended up in the repository
Thus said Michai Ramakers on Fri, 30 May 2014 21:06:36 +0200: michai@main:~/proj/081/adm$ f ci -m 'added note about spent time' time_spent.txt New_Version: 187aa4a7c8b1377ddf05b1d979afe89adeff8dc0 working checkout does not match what would have ended up in the repository: 9b324cf4c9c5ba14727236a0b5157124 versus d4171aa91bd3a0adff045709b2d1be9e Looks like this is due to the recent addition of the empty initial checkin in [cac91b6cd17ab746]: $ fossil bisect bad bisect complete 2 BAD 2014-05-30 18:12:29 52d242a73be2d7d6 3 BAD 2014-05-24 06:27:01 a74d100a121219b8 4 BAD 2014-05-22 04:39:11 941ead2f9ad6f9ca 5 BAD 2014-05-19 09:56:31 c543079b87ce4b6c 6 BAD 2014-05-19 09:16:20 c060947196baef2d 7 BAD 2014-05-19 07:38:04 cac91b6cd17ab746 8 CURRENT 2014-05-19 07:38:04 cac91b6cd17ab746 1 GOOD2014-05-14 16:05:34 ec44f61a831e4225 It's easy enough to reproduce. Create a new empty repository. Add 2 files but only try to checkin 1 of them. Andy -- TAI64 timestamp: 400053891f13 ___ 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] working checkout does not match what would have ended up in the repository
Thus said Stephan Beal on Fri, 30 May 2014 22:25:30 +0200: H. It seems fossil no longer has an option to create the initial checkin. It does using the --date-override option: fossil new --date-override '2014-05-30 00:00:00' test.fossil Will create a new fossil with an initial empty checkin on that date. This does look like one of those corner cases that got missed. Andy -- TAI64 timestamp: 400053892045 ___ 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] working checkout does not match what would have ended up in the repository
On Mon, 19 Nov, Richard Hipp wrote: Fossil compresses files using zlib (and delta compression if other similar files are available) and stores the result as an SQLite BLOB. The maximum size of an SQLite BLOB is 1GiB. So, unless the 4GiB file compresses well, it is not a candidate for being stored in an Fossil repository. As it was a textual log file with *LOTS* of repeating sections, I assume it would compress very good, so ... You might have run into an integer overflow situation rather than an oversized BLOB. You should have gotten a better error message if there had been an SQLite failure. ... I rather assume it's this integer overflow rather than the size itself. But in the end the result is the same: It's not possible to add this file to fossil, right? Greetings, Stefan -- Stefan Bellon ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] working checkout does not match what would have ended up in the repository
Hi all, following up with my other question regarding backslashes in filenames, I now just removed that file in question and wanted to proceed with my svn-fossil conversion: $ cd svn_working_copy $ fossil init myproject.fossil $ fossil open --keep myproject.fossil $ fossil addremove [...] added 37594 files, deleted 0 files $ fossil commit -m initial check-in New_Version: 9a156182450cc34c029fa7188a52ca9353c14525 fossil: working checkout does not match what would have ended up in the repository: 1f33a09ee09f1b7119df98602220236e versus e0cc08adcababdb04165688a01e702fc I even tried with $ fossil status --sha1sum before committing. Same result. How can I track down what's the issue here? Greetings, Stefan -- Stefan Bellon ___ 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] working checkout does not match what would have ended up in the repository
On Mon, Nov 19, 2012 at 6:40 AM, Stefan Bellon sbel...@sbellon.de wrote: Hi all, following up with my other question regarding backslashes in filenames, I now just removed that file in question and wanted to proceed with my svn-fossil conversion: $ cd svn_working_copy $ fossil init myproject.fossil $ fossil open --keep myproject.fossil $ fossil addremove [...] added 37594 files, deleted 0 files $ fossil commit -m initial check-in New_Version: 9a156182450cc34c029fa7188a52ca9353c14525 fossil: working checkout does not match what would have ended up in the repository: 1f33a09ee09f1b7119df98602220236e versus e0cc08adcababdb04165688a01e702fc I even tried with $ fossil status --sha1sum before committing. Same result. How can I track down what's the issue here? Can you figure out which of the 37594 added files is causing the problem? Greetings, Stefan -- Stefan Bellon ___ 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
Re: [fossil-users] working checkout does not match what would have ended up in the repository
On Mon, 19 Nov, Richard Hipp wrote: Can you figure out which of the 37594 added files is causing the problem? I would have hoped fossil can tell me using some --verbose option. If not, I'll try to binary search for the offending file. Greetings, Stefan -- Stefan Bellon ___ 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] working checkout does not match what would have ended up in the repository
On Mon, Nov 19, 2012 at 7:41 AM, Stefan Bellon sbel...@sbellon.de wrote: On Mon, 19 Nov, Richard Hipp wrote: Can you figure out which of the 37594 added files is causing the problem? I would have hoped fossil can tell me using some --verbose option. If not, I'll try to binary search for the offending file. It is suppose to give additional information. The code is here: http://www.fossil-scm.org/fossil/artifact/fc72d682c1?ln=615-671 Clearly I've overlooked something. If you can give me some idea of what is missing, I'll fix it. Greetings, Stefan -- Stefan Bellon ___ 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
Re: [fossil-users] working checkout does not match what would have ended up in the repository
On Mon, 19 Nov, Richard Hipp wrote: Clearly I've overlooked something. If you can give me some idea of what is missing, I'll fix it. I found out what is causing this: I had a log file of over 4 GB size (4376612120 bytes to be precise) in one of the sub directories. Removing that file made the whole thing work. So, does this mean fossil has a maximum file size and files larger than that cannot be committed? Greetings, Stefan -- Stefan Bellon ___ 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] working checkout does not match what would have ended up in the repository
On Mon, Nov 19, 2012 at 9:22 AM, Stefan Bellon sbel...@sbellon.de wrote: On Mon, 19 Nov, Richard Hipp wrote: Clearly I've overlooked something. If you can give me some idea of what is missing, I'll fix it. I found out what is causing this: I had a log file of over 4 GB size (4376612120 bytes to be precise) in one of the sub directories. Removing that file made the whole thing work. So, does this mean fossil has a maximum file size and files larger than that cannot be committed? Fossil compresses files using zlib (and delta compression if other similar files are available) and stores the result as an SQLite BLOB. The maximum size of an SQLite BLOB is 1GiB. So, unless the 4GiB file compresses well, it is not a candidate for being stored in an Fossil repository. You might have run into an integer overflow situation rather than an oversized BLOB. You should have gotten a better error message if there had been an SQLite failure. Greetings, Stefan -- Stefan Bellon ___ 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
