Revert fails in branchless checkouts
(1) By sebyte on 2019-11-20 08:30:44 [source]
Add a file in a checkout directory that was opened empty, and that addition cannot be reverted. See Fossil shell transcript below. (Ordinary shell commands appear bracketed).
fossil> init foo.fossil
project-id: 944328da9b985e176f3d10df8f3a96fc9d4d3d37
server-id: a2e58dddd9c2141bbd8feb5dc8cc1d57ed1863cd
admin-user: sebyte (initial password is "NCbyHVmE5w")
fossil> [ mkdir foo ]
fossil> [ cd ~/workspace/foo/ ]
fossil> open /home/sebyte/workspace/foo.fossil --empty
project-name: <unnamed>
repository: /home/sebyte/workspace/foo.fossil
local-root: /home/sebyte/workspace/foo/
config-db: /home/sebyte/.fossil
project-code: 944328da9b985e176f3d10df8f3a96fc9d4d3d37
check-ins: 1
fossil> [ echo foo > bar ]
fossil> add bar
ADDED bar
fossil> revert
invalid checkout artifact ID: 0
fossil> version
This is fossil version 2.10 [74aac0ed3d] 2019-09-13 22:53:09 UTC
Note the error: invalid checkout artifact ID: 0.
(2) By Stephan Beal (stephan) on 2019-11-20 09:35:05 in reply to 1 [link] [source]
That is definitely a bug, but here's a workaround for you: if you add a file and then rm it before committing, the end effect is the same as reverting it (the process behind it is considerably different, though).
(3) By Richard Hipp (drh) on 2019-11-20 12:32:33 in reply to 1 [link] [source]
I am tempted to fix this simply removing the --empty option to "fossil open". Why is that option even needed? Why should it be retained?
(4) By Stephan Beal (stephan) on 2019-11-20 12:50:33 in reply to 3 [link] [source]
IIRC (which may not be the case), the idea was that it allows people to maintain completely independent development lines in a single repo without having to use tricks like using reconstruct to shoehorn entirely unrelated lineages into the repo.
To me that seems like a completely-off-the-reservation use case, but apparently some people like to do that. i'm completely ambivalent as to whether or not is stays.
(5) By Warren Young (wyoung) on 2019-11-20 14:35:34 in reply to 4 [link] [source]
I was having an off-forum conversation with someone who was trying to convert multiple Git repos into a single Fossil repo, which got us talking about a repo with multiple blockchain roots. Something like this feature would be needed for that, yes?
I ended up convincing him to just go with --repolist or use of a front-end HTTP server to knit the separate repos together, but it could still happen, right?
(7) By sebyte on 2019-11-20 15:08:53 in reply to 4 [link] [source]
[...] it allows people to maintain completely independent development lines in a single repo [...]
Exactly. IMHO, a very useful feature.
(6) By sebyte on 2019-11-20 14:59:38 in reply to 3 [link] [source]
I am tempted to fix this simply removing the --empty option to "fossil open".
Please don't!
Why is that option even needed? Why should it be retained?
IMHO, being able to maintain completely independent development trees, as opposed to development branches, is one of Fossil's killer features.
I have a dozen or so independent Emacs projects on the go, which I am busy moving to a single Fossil repo.
(8) By TomaszDrozdz on 2019-11-25 10:49:52 in reply to 3 [link] [source]
And also there was topic like that:
https://www.fossil-scm.org/forum/forumpost/01ce39af35
(9) By sebyte on 2020-04-02 13:36:05 in reply to 3 [link] [source]
I'm aware I'm probably the only one who keeps getting bitten by this ...
fossil> revert
invalid checkout artifact ID: 0
fossil> version
This is fossil version 2.11 [6ec931a13d] 2020-03-29 14:04:47 UTC
... but in any case, here's a gentle reminder that this bug still needs fixing.
(10) By Stephan Beal (stephan) on 2020-04-02 13:47:11 in reply to 9 [link] [source]
To be fair, what you're doing here was never an intended feature, which makes its classification as a "bug" debatable. It's a side effect of the data model which some users feel compelled to exploit (and admittedly has interesting uses, even if they're "far out there").
Revert asks fossil to restore the content to its previous known/SCM-controlled state, and there is none. You cannot revert if there's nothing to revert to, which is exactly what's happening in your case.
(13) By sebyte on 2020-04-02 19:15:17 in reply to 10 [link] [source]
To be fair, what you're doing here was never an intended feature, which makes its classification as a "bug" debatable.
Understood.
It's a side effect of the data model which some users feel compelled to exploit (and admittedly has interesting uses, even if they're "far out there").
A collection of small utilies, unrelated other than by language, each with their own development tree in a single repo? What's there not to like?
Revert asks fossil to restore the content to its previous known/SCM-controlled state, and there is none.
Understood.
You cannot revert if there's nothing to revert to, which is exactly what's happening in your case.
It's certainly a corner case, but can't it be detected and a simple 'unadd' operation be performed?
(11) By anonymous on 2020-04-02 18:40:40 in reply to 9 [link] [source]
I'm not sure I understand what's your expectation of the correct behavior in this case.
Remove the added file, so that 'fossil status' shows nothing? Delete the added but not committed file from the directory? Print a warning message?
(12) By Richard Hipp (drh) on 2020-04-02 18:58:33 in reply to 1 [link] [source]
Please try again with the latest trunk, after check-in 9aca02b73c2f4eee.
(14) By sebyte on 2020-04-02 19:26:42 in reply to 12 [link] [source]
fossil> init foo.fossil
project-id: 00475846184d24c07edebe710115b1830a4cce19
server-id: b59fafdfdf445c492a7a394752f4833ba824af36
admin-user: sebyte (initial password is "xoVw3tCszu")
fossil> [ mkdir foo ]
fossil> [ cd ~/workspace/foo/ ]
fossil> open /home/sebyte/workspace/foo.fossil --empty
project-name: <unnamed>
repository: /home/sebyte/workspace/foo.fossil
local-root: /home/sebyte/workspace/foo/
config-db: /home/sebyte/.fossil
project-code: 00475846184d24c07edebe710115b1830a4cce19
check-ins: 1
fossil> [ echo foo > foo ]
fossil> add foo
ADDED foo
fossil> revert
UNMANAGE foo
Perfect! Thank you.