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] use of 'fossil close'
On 30 May 2014 18:43, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 30, 2014 at 2:29 PM, Stephan Beal sgb...@googlemail.com wrote: That's likely a misinteraction with the all setup and close. When fossil opens a repo db, it automatically records it in the global config db for 'all' purposes. The close command should (but apparently doesn't?) remove that file from the 'all' list. i'll take a look at it this evening. Can i convince you to please try this out this branch: http://fossil-scm.org/index.html/timeline?r=close-cleanup-configunhide That seems to work fine, thank you. I have merged this branch to trunk locally, and will continue to use it. If there are any things I can or should try/test here, let me know. 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] use of 'fossil close'
On Sat, May 31, 2014 at 4:01 PM, Michai Ramakers m.ramak...@gmail.com wrote: That seems to work fine, thank you. I have merged this branch to trunk locally, and will continue to use it. If there are any things I can or should try/test here, let me know. Great! i'm back from Augsburg but need to run out and do my shopping before getting back to hacking. Two tests come to mind which would be helpful: What happens to 'close' when: a) the repo is read-only b) repo is r/w but the global config is read-only What i expect to happen: a) as before my change: it will simply not remove the entry from either the repo.config table nor the confdb.global_config table. b) i am not sure what will happen here. If this does not fail loudly (if it fails gracefully) then i'm happy. Best-case here is that it behaves like before: it will remove the entry from the repo but not the global config. A quick verification test is pretty simple: echo select name from global_config; | sqlite3 REPODB | grep $PWD # == checkout dir for the repo db: echo select name from config; | sqlite3 REPODB | grep /partial/checkout/dir/path or similar. Note that you can't use 'fossil sqlite' for the first check before fossil does not open the config db by default, so you'll see: [stephan@host:~/cvs/fossil/fossil]$ echo select name from global_config; | fossil sqlite Error: near line 1: no such table: global_config [stephan@host:~/cvs/fossil/fossil]$ echo select name from global_config; | fossil sqlite -R ../fossil.fsl Error: near line 1: no such table: global_config thus the need to bypass fossil there and use sqlite3 directly. -- - 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] use of 'fossil close'
On 31 May 2014 16:26, Stephan Beal sgb...@googlemail.com wrote:
What happens to 'close' when:
a) the repo is read-only
('f.f' is the repo; 'a' and 'b' are initially open roots):
michai@main:~/fclose$ ls -l
total 136
drwxr-xr-x 2 michai users512 May 31 16:48 a
drwxr-xr-x 2 michai users512 May 31 16:48 b
-rw-r--r-- 1 michai users 58368 May 31 16:48 f.f
michai@main:~/fclose$ f all ls -c | grep fclose
/home/michai/fclose/a/
/home/michai/fclose/b/
michai@main:~/fclose$ chmod -w f.f
michai@main:~/fclose$ cd a
michai@main:~/fclose/a$ f close
michai@main:~/fclose/a$ f all ls -c | grep fclose
/home/michai/fclose/a/
/home/michai/fclose/b/
(i.e. it fails silently)
b) repo is r/w but the global config is read-only
continuing:
michai@main:~/fclose/a$ chmod u+w ../f.f
michai@main:~/fclose/a$ ls -l ../f.f
-rw-r--r-- 1 michai users 58368 May 31 16:48 ../f.f
michai@main:~/fclose/a$ cd ../b
michai@main:~/fclose/b$ f stat | grep config-db
config-db:/home/michai/.fossil
michai@main:~/fclose/b$ ls -l ~/.fossil
-rw-r--r-- 1 michai users 5120 May 31 16:51 /home/michai/.fossil
michai@main:~/fclose/b$ chmod -w ~/.fossil
michai@main:~/fclose/b$ ls -l ~/.fossil
-r--r--r-- 1 michai users 5120 May 31 16:51 /home/michai/.fossil
michai@main:~/fclose/b$ f close
configuration file /home/michai/.fossil must be writeable
michai@main:~/fclose/b$ f all ls -c | grep fclose
configuration file /home/michai/.fossil must be writeable
michai@main:~/fclose/b$ chmod u+w ~/.fossil
michai@main:~/fclose/b$ ls -l ~/.fossil
-rw-r--r-- 1 michai users 5120 May 31 16:51 /home/michai/.fossil
michai@main:~/fclose/b$ f all ls -c | grep fclose
/home/michai/fclose/a/
/home/michai/fclose/b/
michai@main:~/fclose/b$ f stat | grep config-db
config-db:/home/michai/.fossil
(i.e. fails not so silently, and repo is still open at 'b')
What i expect to happen:
a) as before my change: it will simply not remove the entry from either the
repo.config table nor the confdb.global_config table.
b) i am not sure what will happen here. If this does not fail loudly (if it
fails gracefully) then i'm happy. Best-case here is that it behaves like
before: it will remove the entry from the repo but not the global config.
I think indeed the 2nd test should close the repo, even if it can't
update the config.
A quick verification test is pretty simple:
echo select name from global_config; | sqlite3 REPODB | grep $PWD # ==
checkout dir
You probably meant GLOBCFGDB or similar instead of REPODB. Is the
above snippet conclusive or should I try this as well..?
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] use of 'fossil close'
On 31 May 2014 17:12, Michai Ramakers m.ramak...@gmail.com wrote: a) the repo is read-only ... for completeness sake: the root at 'a' was closed as per 'fossil stat' after calling 'fossil close' in that dir, when repo was r/o and global config was r/w. 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] use of 'fossil close'
On Sat, May 31, 2014 at 5:12 PM, Michai Ramakers m.ramak...@gmail.com
wrote:
('f.f' is the repo; 'a' and 'b' are initially open roots):
michai@main:~/fclose$ ls -l
total 136
drwxr-xr-x 2 michai users512 May 31 16:48 a
drwxr-xr-x 2 michai users512 May 31 16:48 b
-rw-r--r-- 1 michai users 58368 May 31 16:48 f.f
michai@main:~/fclose$ f all ls -c | grep fclose
/home/michai/fclose/a/
/home/michai/fclose/b/
michai@main:~/fclose$ chmod -w f.f
michai@main:~/fclose$ cd a
michai@main:~/fclose/a$ f close
michai@main:~/fclose/a$ f all ls -c | grep fclose
/home/michai/fclose/a/
/home/michai/fclose/b/
(i.e. it fails silently)
Good. That's correct behaviour, IMO.
b) repo is r/w but the global config is read-only
continuing:
michai@main:~/fclose/b$ f stat | grep config-db
config-db:/home/michai/.fossil
michai@main:~/fclose/b$ ls -l ~/.fossil
-r--r--r-- 1 michai users 5120 May 31 16:51 /home/michai/.fossil
michai@main:~/fclose/b$ f close
configuration file /home/michai/.fossil must be writeable
Aha. i wasn't aware of that. i explicitly remember Jan adding some support
for a non-writable... Ah, that was Windows-only, when the fossil config is
in a non-writable _directory_. Okay, so... Fossil requires that .fossil be
writeable, which means this whole test case is invalid vis-a-vis fossil's
assumptions. i.e. works as designed ;).
michai@main:~/fclose/b$ f all ls -c | grep fclose
configuration file /home/michai/.fossil must be writeable
michai@main:~/fclose/b$ chmod u+w ~/.fossil
michai@main:~/fclose/b$ ls -l ~/.fossil
-rw-r--r-- 1 michai users 5120 May 31 16:51 /home/michai/.fossil
michai@main:~/fclose/b$ f all ls -c | grep fclose
/home/michai/fclose/a/
/home/michai/fclose/b/
michai@main:~/fclose/b$ f stat | grep config-db
config-db:/home/michai/.fossil
(i.e. fails not so silently, and repo is still open at 'b')
i _think_ (see above) that's correct behaviour. My assumption that a
read-only config is legal (or not strict illegal) was apparently wrong.
I think indeed the 2nd test should close the repo, even if it can't
update the config.
i would have expected it to, actually, looking over it now, but i
apparently must look closer. The current approach does some weirdness with
the db connection (see db.c:db_unset() for the gory details), and i may
have to try another approach here (the current impl required only a tiny
change).
echo select name from global_config; | sqlite3 REPODB | grep $PWD # ==
checkout dir
You probably meant GLOBCFGDB or similar instead of REPODB. Is the
above snippet conclusive or should I try this as well..?
Your check was much better, actually - i only use 'all' with rebuild, and
wasn't aware of (ls -c).
--
- 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
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] use of 'fossil close'
On 31 May 2014 17:49, Stephan Beal sgb...@googlemail.com wrote: On Sat, May 31, 2014 at 5:12 PM, Michai Ramakers m.ramak...@gmail.com wrote: b) repo is r/w but the global config is read-only ... Okay, so... Fossil requires that .fossil be writeable, which means this whole test case is invalid vis-a-vis fossil's assumptions. i.e. works as designed ;). ... i _think_ (see above) that's correct behaviour. My assumption that a read-only config is legal (or not strict illegal) was apparently wrong. I think indeed the 2nd test should close the repo, even if it can't update the config. i would have expected it to, actually, looking over it now, but i apparently must look closer. The current approach does some weirdness with the db connection (see db.c:db_unset() for the gory details), and i may have to try another approach here (the current impl required only a tiny change). Perhaps if the config-db must be writable, this is a nonexistent use-case? (Or am I misunderstanding what you are saying?) 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] use of 'fossil close'
On Sat, May 31, 2014 at 6:11 PM, Michai Ramakers m.ramak...@gmail.com wrote: On 31 May 2014 17:49, Stephan Beal sgb...@googlemail.com wrote: On Sat, May 31, 2014 at 5:12 PM, Michai Ramakers m.ramak...@gmail.com I think indeed the 2nd test should close the repo, even if it can't update the config. i would have expected it to, actually, looking over it now, but i apparently must look closer. The current approach does some weirdness with the db connection (see db.c:db_unset() for the gory details), and i may have to try another approach here (the current impl required only a tiny change). Perhaps if the config-db must be writable, this is a nonexistent use-case? (Or am I misunderstanding what you are saying?) Correct: non-issue. Fossil assumes the global config needs to be writable (which has never been a problem, AFAIK, though i do remember someone asking about it in the past year). i might have misunderstood some of the output, but my current understanding of correct behaviour, adjusted for the assumption/assertion that the global config must be writable, is: - If the repo is read-only, it must silently fail to remove the ckout:/... entry from the repo.config table, but should remove it from confdb.global_config (~/.fossil). - If the repo is read/write, the ckout:/path/... entry should be removed from both the repo and global config. - If the global config is r/o, fossil will complain and all bets are off. That's okay and is the historical behaviour. Is that what you're seeing? If so, i'll get it into the trunk. What i want to avoid, however, is introducing any new error case which didn't exist before. -- - 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 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] use of 'fossil close'
On 31 May 2014 18:21, Stephan Beal sgb...@googlemail.com wrote: i might have misunderstood some of the output, but my current understanding of correct behaviour, adjusted for the assumption/assertion that the global config must be writable, is: - If the repo is read-only, it must silently fail to remove the ckout:/... entry from the repo.config table, but should remove it from confdb.global_config (~/.fossil). hmm no, that is not what happens. My test was a bit silly - repo perms were set 444, but owned michai.users, and executed as 'michai', sorry, let's do that again. Now I tested as user 'michai', with repo chowned root.wheel and perms 600 after opening it. If I then try to close it, it obviously complains: Fossil internal error: read permission denied for repository /home/michai/fclose/a/../f.f When I change perms/owner of the repo back to original, I see (using 'f all ls -c') that neither the repo was closed nor the checkout was removed from config-db (which was r/w all this time). So... repo-perms being r/o but uid of repo being uid of user on the one hand, and user being physically unable to write on the other hand, have different behaviour. - If the repo is read/write, the ckout:/path/... entry should be removed from both the repo and global config. yes, works - If the global config is r/o, fossil will complain and all bets are off. That's okay and is the historical behaviour. right; tried again, this time restricting perms/owner of ~/.fossil to root.wheel / 600 after opening the repo, then trying to close, then changing ~/.fossil perms/owner back to normal, all this time with repo having normal perms/owner. In this case, neither repo was closed nor checkout removed from config-db. (All this makes me think of the guy mentioning knows chmod on his CV, btw.) 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
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] use of 'fossil close'
On Sat, May 31, 2014 at 6:58 PM, Michai Ramakers m.ramak...@gmail.com wrote: My test was a bit silly - repo perms were set 444, but owned michai.users, and executed as 'michai', sorry, let's do that again. r/o should work, in the sense of it shouldn't fail, but won't do much. (For those who don't know 0444 == r--r--r--) Now I tested as user 'michai', with repo chowned root.wheel and perms 600 after opening it. If I then try to close it, it obviously complains: Fossil internal error: read permission denied for repository /home/michai/fclose/a/../f.f Yes, expected. When I change perms/owner of the repo back to original, I see (using 'f all ls -c') that neither the repo was closed nor the checkout was removed from config-db (which was r/w all this time). When you say not closed, you mean that .fslckout (or _FOSSIL_) still exists, correct? The repo is rw at this point, correct? If the repo is r/o then the whole remove the ckout part is current skipped altogether (i.e. it behaves like it did 12 hours ago, before this change). The problem there is that the config db is not always opened, and opening it just to remove this entry seems like overkill (as opening it could, hypothetically, cause or receive a locking error if other processes are in play, e.g. managing multiple repos on a server which hosts them over CGI). (All this makes me think of the guy mentioning knows chmod on his CV, btw.) ROFL! As your final test: do this once again with the sticky bit set on your repo ;) (Just kidding!) -- - 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
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 with open source code
Thus said Abilio Marques on Sat, 31 May 2014 00:12:00 -0430: Let's say I want to do this setup: Clone sqlite repo on a local server Then clone the server into several machines, with the users pushing changes Are they committing changes to trunk? Then, someday, I will want to update my sqlite base code. Again, are we talking about trunk or is your ``base'' code maintained in a local branch (I say local because I don't mean private, but rather, a branch that exists in your local server clone but will not push to sqlite proper). Andy -- TAI64 timestamp: 4000538a1c64 ___ 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] Git horror story post.
http://mikegerwitz.com/papers/git-horror-story ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
