[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.buckminster] Re: Buckminster updating / change-list generation 
Hi,

since this feature request orignates from the hudson integration, I'd like to add something to the ideas to make it usable as easy as possible within hudson.
If a user would use buckminster as 'SCM' in hudson, I'd have the plugin to fidle around with the original resolve/import command to add the parameters necessary to pipe the changelog output to a file that's well known to the hudson plugin automatically.
Now I think it's likely that a user will use more than one component request to populate the workspace. In that case I think it would be nice if there'd a property for the change oberserver that controls if the changelog file should be replaced if it is exisiting or if it should append to the end of the file. That way several component requests will end up in one accumulated change-log file that can be processed by the hudson plugin.

Best regards,
Johannes

Thomas Hallgren schrieb:
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