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

[Thomas Hallgren <thomas@xxxxxxx>]

Hi Peter,
This sounds very positive. I think you should open a bugzilla where you can describe your efforts and also attach 
patches that we can look at. My guess is that your contribution will be considered non trivial so I must prepare for IP 
approval from the Eclipse EMO before your work can be accepted into our code-base. No big deal really, but it means that 
you must assert that you are the author behind it all and that your employer has no objections to the fact that you 
contribute your work to us under EPL.

Some comments and questions inline.

Peter M. Murray wrote:
> Current status update on Buckminster update / polling prototype 
> functionality:
>
> - implemented the update using the ConflictResolution attribute on the 
> RMContext.
> - the NodeQuery.useWorkspace() method now checks for advisornodes as 
> well as checking the RMContext for ConflictResolution.KEEP or 
> ConflictResolution.FAIL.

And ConflictResolution.UPDATE ?

> - (hack?) fixed the problem of useWorkspace not functioning by checking 
> NodeQuery.useWorkspace() in the getBest*() static methods on 
> EclipsePlatformReaderType and filtering response accordingly.

Sounds OK to me.

> - Subversive Reader implementation now checks and if subversion 
> management directory exists and performs a switch rather than a checkout 
> (could push up some logic to generic svn superclass for both Subversive 
> and Subclipse)

If the meta-data is the same, that would be great. The addition of this check is good news. I'm surprised no one has 
complained about it not being done earlier. This also relates to the issue of qualifier replacement in combination with 
local reader that has been brought up by both Carsten Reckord and Chase Wolfinger on this newsgroup earlier.

What happens if the switch isn't possible due to lack of needed credentials? Does it check if a repository has been 
set-up in the workspace (like it does in the GenericSession constructor) and make use of its credentials?

I think it's OK to fail the update with an exception unless a switch can be performed.


> Polling prototype implementation:
> - added -p/--poll argument to import to perform a noop query if an 
> update is needed
> - added two booleans to RM context to support this
> -- m_poll - indicates if this RM cycle is a polling cycle
> -- m_needsUpdate - indicates if one or more readers registered that it 
> needs to update
> - import command logs INFO with result and process return code = 999 if 
> needs update (is this the best way to communicate that state?)

A non zero return code usually means failure. If hudson has some protocol for this then I propose we use that.

> - implemented for Subversive the polling functionality
>
> Possible improvements:
> - stop the polling as first reader encounters desired update
> - others?
This is plenty for now. Next steps will undoubtedly involve CVS but perhaps we can get more people involved once the 
needed API changes has crystallized.

I'm also thinking about how we can improve the target platform story so that we can include P2 updates to it here.

You don't mention how the update observer collects/reports events. Have you done anything with 
MaterializationStatistics? I looked at that class and realized that in order to collect it must be complemented with a 
list of files or something. It only collects component identifiers in its current shape.

Regards,
Thomas Hallgren