Fossil SCM

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 branch and subsequent fixes on trunk culminating with check-in b517a989d61772c2. 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.

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 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.

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. Fixed by check-in ae1dac83d6bc4a3e.

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"?