Hi Ethan,
Sorry for the delay, answers are in-line...
Thank you,
Clay
On Thu, 26 Mar 2009, Ethan Quach wrote:
> Clay,
>
> Clay Baenziger wrote:
>> Hi Ethan,
>> With regards to bug 7383. I see issues surrounding this bug as:
>> * Being able to ensure an AI client gets a manifest with keywords
>> which it supports (i.e. server running build Y, client running
>> build X, x<y)
>> * Being able to identify what build (of our bits) an AI client is
>> running
>
> Can you elaborate on how you see the second bullet is related? That
> seems to be more an issue of the installer bits being compatible with
> bits that are laid down. I sent out a separate proposal for that
> earlier this week. Feel free to comment on that.
Ethan, I see having the build available to determine manifests being a
useful thing for system configuration and perhaps even packages to install
too. For example, one might not want to install a package on an older
build where there's a security or performance issue.
>>
>> To achieve these two ends:
>> * The schema could define what changeset (of slim_source) the
>> feature being defined was added. (Perhaps just a changeset=###
>> attribute that can be added to features in the schema.) Then,
>> publish_manifest will store what the minimum changeset necessary
>> for that schema in the criteria database as a criteria.
>
> I think you're confusing the changeset ID with the revision number.
> What you're describing above requires a sequential ordering, but
> changeset IDs are not sequentially ordered, they are just 40 digit
> hex unique identifiers.
>
> The revision number is ordered, but they would be unreliable for this
> usage because you can't rely on them to be the same over time. i.e.
> revision number 545 isn't always going to describe changeset X.
>
> See this URL for descriptions of these Mercurial terms
> http://www.selenic.com/mercurial/wiki/index.cgi/FAQ#head-64d21ec75f556ed21f840436727a82655fdfb5ac
>
Yes, you're right, I meant revision number. Hrm, I see it mentioned that
revision numbers are not stable across multiple repository copies but off
our one development repo they should remain stable from: "A changeset is
identified uniquely by a changeset ID. In a single repository, you can
identify it using a revision number." --
http://www.selenic.com/mercurial/wiki/index.cgi/ChangeSet
>> * The client can send which changeset of slim_source it was built
>> off of in the AI server<->client criteria exchange.
>
> Exactly my point. Once you record the revision number off into the
> built image, you can't reliably compare it back to the revision number
> in the manifest because the former or latter's revision number could
> have been gotten after a shift.
Yes, there is a problem, for example, when we move from our development
repo to ON. We could instead use a tags when available and record a tag
and revision number falling back if no tag or some such.
>> * Then all that is necessary to ensure the client gets an
>> appropriate manifest is to have the AI webserver treat the
>> changeset criteria as just any other criteria -- no work
>> necessary.
>
> I think you're on the right track with this, but instead of using
> the repository revision numbers, why not just cook up our own ordered
> numbers every time we change/add features to the manifest? What's
> wrong with 1, 2, 3, ...
I see requiring human intervention to be a bad idea since it's limited
to when someone updates the version number (so not as generalized and
prone to forgetting).
>
> thanks,
> -ethan
>
>
>>
>> I see this as requiring fairly little implementation (~5 days with
>> testing). Let me know what's might be missed by such an approach or how
>> else versioning could be done though.
>> Thank you,
>> Clay
>
