Why is --no-open no longer the default when cloning?
(1) By Andy Bradford (andybradford) on 2021-05-14 03:55:24 [link] [source]
I must admit to have somehow missed some of the recent changes, so I'm coming really late to this discussion, but I'm not enamored of this change: https://www.fossil-scm.org/home/info/a8d7878789da6e33 I never clone the fossil in a location where I want it to be opened. What's the rationale for this breaking change (it breaks years of Fossil usage of keeping clone and open as separate)? Would a patch to store the preference to always default to --no-open as a global setting be acceptable? I know we don't like to have a plethora of settings in Fossil, but breaking years of perfectly acceptable and sensible behavior in Fossil just to be more like Git is a hard pill to swallow. I'll either have to start tracking which version of Fossil I might be using, or write a wrapper now instead of having the flexibility I have come to expect from Fossil. Thanks, Andy
(2) By Andy Bradford (andybradford) on 2021-05-14 04:07:36 in reply to 1 [source]
> I'll either have to start tracking which version of Fossil I might be > using, or write a wrapper now instead of having the flexibility I have > come to expect from Fossil. So apparently as long as I give a name for the clone, it avoids the new behavior, so maybe a new setting isn't exactly necessary as long as I always give it a local repository name (which is backwards compatible); e.g. this averts the open: fossil clone URL clone.fossil However, it does look like there is some kind of a bug with the new behavior: $ fossil clone /tmp/new.fossil Repository cloned into ./new.fossil Rebuilding repository meta-data... 100.0% complete... Extra delta compression... Vacuuming the database... project-id: 7a4212349c322fd6c9c037c0b352314d0301b6f1 server-id: 7d0403efc267bc5927b3af2f0cc6741ef8ca07d9 admin-user: amb (password is "xs6y2p4ti5") opening the new ./new.fossil repository in directory ./new... SQLITE_ERROR(1): no such table: global_config in "SELECT value FROM global_config WHERE name=$n" Database error: SQL error (1,1: no such table: global_config) while running [SELECT value FROM global_config WHERE name=$n] Which, I see was reported a couple months ago, but never solved [1]. Does the new method of open work for anyone on any OS? I'm on OpenBSD. Thanks, Andy [1] https://www.fossil-scm.org/forum/forumpost/c11e4d93f1db0058a801e9042210b2b98a3d10f830b24b5356057751135de90e
(3.1) By sean (jungleboogie) on 2021-05-14 14:02:08 edited from 3.0 in reply to 2 [link] [source]
Hi,
I first did this:
$ fossil clone https://www.sqlite.org/althttpd --workdir althttpd
I use the --workdir option in clone, since I keep all my .fossil files in one directory and the contents of them in a subdirectory.
Then this:
$ fossil clone althttpd.fossil /tmp/new.fossil
Repository cloned into /tmp/new.fossil
Rebuilding repository meta-data...
100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: dad3bbea7a3216ce9737d7c003d6e07646ceb3d7
server-id: 842a0c10aa5ce63d3d2038e55336d45cb904c94f
admin-user: ember (password is "v3fhjWCXsB")
Is this similar to what you did?
$ sysctl kern.version && fossil version
kern.version=OpenBSD 6.9-current (GENERIC.MP) #17: Wed May 12 11:14:50 MDT 2021
deraadt@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
This is fossil version 2.15 [2d59385d35] 2021-05-10 01:56:58 UTC
Edit...
Using the script in the above forum post, I receive the same message from Fossil. ```
(4) By Andy Bradford (andybradford) on 2021-05-14 14:04:33 in reply to 3.0 [link] [source]
> I use the --workdir option in clone I tend to prefer keeping clone and open as distinct commands. > $ fossil clone althttpd.fossil /tmp/new.fossil > ... > > Is this similar to what you did? Not quite. Try this instead: fossil clone https://www.sqlite.org/althttpd mkdir another cd another fossil clone ../althttpd.fossil In looking at your steps, it becomes apparent that this problem might only exist when cloning file:// URLs, and not remote URLs. Thanks, Andy
(5) By sean (jungleboogie) on 2021-05-14 14:10:42 in reply to 4 [link] [source]
Thanks for the help in reviewing my steps to your steps.
In looking at your steps, it becomes apparent that this problem might only exist when cloning file:// URLs, and not remote URLs.
Yes, I think that's exactly it.
$ mkdir test
optiplex$ cd test/
optiplex$ fossil clone https://www.sqlite.org/althttpd
Round-trips: 2 Artifacts sent: 0 received: 66
Clone done, sent: 537 received: 56511 ip: 45.33.6.223
Rebuilding repository meta-data...
100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: dad3bbea7a3216ce9737d7c003d6e07646ceb3d7
server-id: a442ce762a7b6ed283807825ec05156b63cfb209
admin-user: ember (password is "TDJhpFPo3G")
opening the new ./althttpd.fossil repository in directory ./althttpd...
$ cd /tmp/
$ fossil clone /home/ember/test/althttpd.fossil
...
opening the new ./althttpd.fossil repository in directory ./althttpd...
SQLITE_ERROR(1): no such table: global_config in "SELECT value FROM global_config WHERE name=$n"
Database error: SQL error (1,1: no such table: global_config) while running [SELECT value FROM global_config WHERE name=$n]
(6) By Andy Bradford (andybradford) on 2021-05-14 17:16:03 in reply to 2 [link] [source]
It looks like this error condition was introduced with this commit: https://www.fossil-scm.org/home/info/f044cf2a91b5906f I'm not sure, yet which of the changes is the culprit, but I suspect some of the changes in db.c. Andy
(7) By sean (jungleboogie) on 2021-05-14 17:30:35 in reply to 6 [link] [source]
Yes, something in db.c. I took the previous version of db.c and replaced it with that commitID of Fossil and same test above opened the Fossil repo.
This is fossil version 2.14 [f044cf2a91] 2020-11-21 19:46:36 UTC
(8) By Richard Hipp (drh) on 2021-05-14 18:54:24 in reply to 2 [link] [source]
Please try again with check-in ebd604f8c7c57e77 or later.
(9) By sean (jungleboogie) on 2021-05-14 19:15:20 in reply to 8 [link] [source]
Confirmed fixed for me.
This is fossil version 2.15 [ebd604f8c7] 2021-05-14 18:52:37 UTC
(10) By Andy Bradford (andybradford) on 2021-05-15 15:10:33 in reply to 8 [link] [source]
> Please try again with check-in ebd604f8c7c57e77 or later. Thanks for the fix. I started looking at fixing it yesterday, but didn't have enough time and was actually going in an entirely different direction than your simple fix to exec a new process. I was trying to figure out why the config database wasn't attached (or was otherwise missing). Thanks, Andy