[news.eclipse.tools.buckminster] Re: Buckminster updating / change-list

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Peter,
This sounds very interesting and the improvements that you suggest make a lot of sense. I have some suggestions that 
might help make it even easier and perhaps keep the API changes to a minimum.

In general, I think the reader should be able to detect the difference between a check-out and and update automatically. 
For CVS/SVN we can almost provoke this behavior today by adding an advisor node to the CQUERY that prevent that a 
resolution takes place against the workspace. The problem is that check-outs will still be performed instead of updates.

Buckminster already contains some code that makes a halfhearted attempt to manage what should happen when things already 
exists (see org.eclipse.buckminster.core.mspec.ConflictResolution). It's not currently used by the workspace 
materializer but that could easily change. Valid values are FAIL, KEEP, REPLACE, or UPDATE

We also have a way to collect statistics about the materialization (see 
org.eclipse.buckminster.core.materializer.MaterializationStatistics). It's only used by the "filesystem" and the 
deprecated "site.mirror" materializer at present but it would serve us well for this purpose.

So what about this:

* We add a default ConflictResolution attribute to the resolution/materialization context (the RMContext)

* This attribute should default to KEEP but we add a command line option to control it to the import command and to the UI

* We make the resolver sensitive to this attribute in the following way:
KEEP - Do what it does today. I.e. resolve from the workspace/target platform (and be happy with what's there)
UPDATE - Don't resolve from the workspace/target platform. Always do an external resolution, then automatically update 
instead of check-out if the component is already present. If it's not, do a normal check-out
REPLACE - Don't resolve from the workspace/target platform. Do an external resolution, then force a check-out (the 
behavior we get with an advisor node that prevents workspace resolution).
FAIL - Fail hard if the component already exists at its destination.

* Use the MaterializationStatistics for all types of materializers. Using the IUpdateDeltaObserver that you suggested to 
populate it might be a good approach for the workspace materializer when SVN/CVS type of readers. The p2 materializer 
however, does not normally use use a reader to perform its updates. Instead, it uses the p2 engine to run a collect phase.

* Add a command line option to import that will cause the content of the MaterializationStatistics to be reported

I like the idea of a quick-as-possible probe and a dry run. I can see how the latter would be implemented.

Regards,
Thomas Hallgren


Peter M. Murray wrote:
> 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