Fossil Forum

Why is --no-open no longer the default when cloning?
Login

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