Wiki page
[checkin/b4beadb5078a03421a62f5a205cea1a52febe84b83c5189c9d271cd54a459136] by
drh
2020-04-15 13:15:08.
D 2020-04-15T13:15:08.836
L checkin/b4beadb5078a03421a62f5a205cea1a52febe84b83c5189c9d271cd54a459136
N text/x-markdown
U drh
W 4188
## Persistent Phantoms Caused By Private Branches
We were having a problem where people would work on some feature in a private
branch, then do a "fossil up trunk; fossil merge --integrate private;" to
merge the private branch into trunk. The --integrate flag was causing a
"closed" tag against the private branch to appear in the public block-chain.
This generated phantoms (artifacts whose hash is known but whose content is
unknown) which would then cause "gimme" cards to be sent in both directions
on every sync round-trip.
One solution to these extra gimme cards is to make the phantoms as private.
This was accomplished by the [sync-improvements][1] branch and subsequent
fixes on trunk culminating with check-in [b517a989d61772c2][2]. In those
patches, when the original repository that actually holds the private branch
sees a "gimme" card with a private artifact, it replies with an "igot" card
on the artifact with the private flag set. The sender of the "gimme" card
then knows that the phantom is private, marks it as such in the "private"
table of the database, and subsequent "gimme" cards are avoided.
[1]: /timeline?r=sync-improvements
[2]: /info/b517a989d61772c2
There are problems with the "sync-improvements" approach:
1. It relies on messages from the original holder of the private branch.
If the repo that holds the private branch never again participates in
a sync, the private "igot" card never gets sent, and we never learn
that the artifact is private.
2. The fact that the phantom artifact is private is stored in the
"private" table of the database. This table persists across
"fossil rebuild". But it is not part of the block-chain.
This check-in addresses the problem differently, by simply not creating
the "closed" tag in the first place.
## Related changes
Another series of edits on trunk culminating with check-in [941280ae0aa53d1d][3]
adds the /phantoms webpage and shows all public phantoms in the "Security Audit"
page. This easily identifies phantoms and allows the administrator to manually
create "private" tags against those phantoms in the block-chain, if desired.
[3]: /info/941280ae0aa53d1d
## Future enhancements
1. This check-in prints a warning message if --integrate is used on a
private branch merge, saying that the --integrate flag will be ignored
and advising the user to run a separate "fossil amend" command.
Better would be if the "fossil amend" was run automatically.
2. On the /phantoms webpage and in the display of phantoms on Security Audit
page, there ought to be a button or buttons that Admins can press that
will automatically create "private" tags on those phantoms, so that
the fact that the phantom is private becomes part of the blockchain.
3. There ought to be a relatively simply mechanism to see the private
phantoms generated by the "sync-improvement" changes and allow an
Admin to insert "private" tags for those phantoms into the blockchain.
## Private Merge Parents In P-Cards
Currently, when a private branch is merged into a public branch, the private
branch is omitted from the P-card of the manifest. I think this should change.
the P-card should reference the private merge parent. But, perhaps there
should also be a separate (public) tag artifact that designates the private
merge parent as being private, so that there will be an artifact in the public
blockchain that prevents the P-card reference from generating a persistent
phantom.
## Backlinks to Markdown
This attached wiki page is formatted in Markdown.
I am curious to see how the "backlink" handler deals with the
references to check-ins and branches found in this note. There
might be opportunities for improvement there. We'll see.
## Attach Forum Entries To Check-Ins and Branches?
This wiki pages seems like it might go better as a Forum page (albeit
a Forum page in the actual source repository, not in the separate
fossil-forum repo.) Should we extend the "associated wiki" mechanism
so that it also allows "associated forum"?
Z 82f3a71be71614060ae5150ca3f56326