SQLite Forum

Updating clone of sqlite repository stuck in 493a2594
Login

Updating clone of sqlite repository stuck in 493a2594

(1) By Domingo (mingodad) on 2020-09-07 07:52:59 [link] [source]

Hello Richard !

I'm following sqlite development daily for years and before there was occasional problems when you let's call it "rebased" the trunk and I was left stuck with a dead branch, but now looking at the timeline it doesn't seem that I'm in a dead branch but somehow every time I do "fossil update" I'm stuck on this checkout 493a2594 .

How to fix this ?

There is a way for fossil to recognize situations like the described above and issue a warning/recommendation to fix it ?

====

fossil update
Autosync:  https://www3.sqlite.org/cgi/src
Round-trips: 1   Artifacts sent: 0  received: 0
Pull done, sent: 1308  received: 991  ip: 64.225.41.2
-------------------------------------------------------------------------------
checkout:     493a25949b9a6d0be82169b597133e491d8be4f4 2020-08-24 10:52:52 UTC
tags:         trunk
comment:      Correctly handle expressions like "x IS (not) true/false" within the rhs of IN() expressions. Fix for
              [f3ff1472]. (user: dan)
changes:      None. Already up-to-date
mingo@mingo-X550VX:~/dev/dadbiz++/third-party/dad/sqlite3$ fossil status
repository: /home/mingo/dev/dadbiz++/third-party/dad/sqlite.fossil
local-root:   /home/mingo/dev/dadbiz++/third-party/dad/sqlite3/
config-db:    /home/mingo/.fossil
checkout:     493a25949b9a6d0be82169b597133e491d8be4f4 2020-08-24 10:52:52 UTC
parent:       5f58dd3a19605b6f49b4364fa29892502eff35f1 2020-08-20 16:25:26 UTC
tags:         trunk
comment:      Correctly handle expressions like "x IS (not) true/false" within the rhs of IN() expressions. Fix for
              [f3ff1472]. (user: dan)

====

Cheers !

(2) By Warren Young (wyoung) on 2020-09-07 09:54:34 in reply to 1 [source]

The problem isn’t due to “rebasing,” which you can’t do in Fossil anyway. (On purpose.)

Your current problem is that www3 is stuck. Compare https://www.sqlite.org/src/timeline and https://www3.sqlite.org/src/timeline.

The fix is to switch the clone URL:

  $ fossil remote https://sqlite.org/src/

I suspect your past problems were due to post-facto branch retagging, which may look superficially like rebasing, but isn’t. It’s rare enough that I wouldn’t change a manual workflow, since it’s easy to cope. Say:

  $ fossil up trunk

If you have an automated update mechanism, just use that command instead of making the branch implicit.

Briefly, the problem is that Fossil doesn’t remember the current branch name, it remembers the current commit ID. When that commit gets relabeled, it stays on that newly named branch, rather than send you off to what it perceives to be a different branch.

Further discussion on this topic is better taken up on the Fossil forum, where we did in fact cover it recently, though I’m having trouble finding the thread at the moment. (The relevant keywords are too common, so they pull up tons of irrelevant threads.)

(3) By Warren Young (wyoung) on 2020-09-07 14:00:11 in reply to 2 [link] [source]

...www3 is stuck. Compare...

That problem's been cleared since I composed the prior message.

...we did in fact cover it recently, though I’m having trouble finding the thread at the moment...

Here it is.