Greetings folks,
I'm relatively new to Buckminster, but enthusiastic! Please excuse me
if I don't wield the vocabulary properly or don't grok some of the
concepts.
I've read in this newsgroup various postings about extending Buckminster
to allow for updating an existing workspace (presumably via a cquery)
and generating change-lists as a side effect. Such a functionality
would be useful for CI framework integration - the goal being to
maintain a workspace and bump it to the latest code, recording changes,
comments, authors, etc, then rebuild and run tests. In my case,
integration with Hudson is most immediate, but I imagine that other CI
frameworks would benefit from similar functionality.
Would something like the following make sense:
* add IComponentReader.update(IPath location, Resolution resolution,
MaterializationContext ctx, IUpdateDeltaObserver observer,
IProgressMonitor monitor)
* add IComponentReader.canUpdate(); ??
* create IUpdateDeltaObserver which will get update events based on what
is being updated.
* create UpdateJob that is designed to update a materialized workspace
and record update events into a file based on configuration params
* create UpdateCommand that is wired to buckminster update <cquery> with
appropriate options to control placement, naming etc. of the change-list
xml output
* Optional extensions
** allow for a quick-as-possible (early bail on first change detected)
probe if an update would change something
(IComponentReader.needsUpdate() and an additional command?)
** allow for an option to run the update, gather the deltas, but not
actually do anything (additional boolean arg to IComponentReader.update?)
Questions:
* Would this be a reasonable pattern for all readers? I suppose, to
start, some readers could update silently or noop & log on the update??
* Is the Reader the proper level of abstraction for differentiating the
update functionality?
* Would it be better to offer the update as a set of parameters to the
materialization Job/Command rather than a separate command entirely
(enforce identical resolution and other workflow phases)?
* Is this the right direction?
If it's cool with the powers that be, I'd be happy to roll up my sleeves
once a direction is agreed upon.
Cheers,
pete