Rework the alias interface to support the following new features:
bk alias -h # shows what aliases are "here"
new automagic aliases: HERE and THERE in addition to ALL and DEFAULT which are now reserved in all cases (DeFaULt)
plug revisions into aliases so that when we clone -r we get the correct version of the aliasdb (as of the rev we're cloning).
— Implementation Details
-
Some times you want the tip of the aliasdb as of the tip of the cset file, others the tip of the sfile, and yet others the gfile.
E.g. clone -r<cset> needs it as of @cset file bk alias add|remove|etc need to muck with the tip of the aliasdb file
we punted on gfile because we have the bk alias command and it doesn't leave the gfile edited so if the user is messing by hand with the gfile, it's their problem. (lm3di).
-
The present bit went in because we used to skip stuff that wasn’t present, but with the present bit we can catch errors where components are missing early on, at alias expansion time.
STUFF THAT’S NOT DONE OR NEEDS TO BE CHECKED
-
what happens when you unpopulate gcc and gcc was part of the devtools alias? What does it do to the component’s list?
-
When both sides modify and there is a conflict what happens?
The plan is to have the pull of the product merge the alias file. The sending side will send its ensemble list. Everything needed will be on the local side. The ensemble list on-the-wire format needs to be nailed down.
-
Where do you expand the alias? here or there? Both
one idea is:
-
the receiver passes the tip key of the aliases file and an md5sum of each alias expansion for each alias it’s asking for.
the sender can then see if it's an update-only pull with respect to aliases and whether any of the aliases changed.
if it's not, we're hosed. come up with something... or * the first product clone also includes the clone sfio in addition to the meta data sent. That will allow the local side to have a complete view of the world when making a decision of what to clone and what to pull. Push is easier because of no conflict.