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

[eclipse@xxxxxxxxxxx (Peter M. Murray)]

Hi Thomas, 

Some responses inline below:

Thomas Hallgren wrote:

> 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.

Shouldn't be a problem.

> 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 ?

NodeQuery.useWorkspace() returns true if
a) getComponentQuery().useWorkspace(getComponentRequest()) // as before
AND
b) the context's conflictResolution is either KEEP or FAIL

It returns false if the conflictResolution is UPDATE or REPLACE

> > - (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'll check on the GenericSession constructor - currently nothing special 
is being done for that case, so I assume it would fail.

> 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.

Currently the Hudson integration runs buckminster in a separate VM - thus 
the process return code being a convenient boolean communication.  Parsing 
the output would be another route - or generating some kind of output file 
to parse.  I can imagine that a return-code boolean indicator might be 
useful for calling the update-probe from a shell script as well.  

> > - 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.

That would be cool! Then I could totally buckminsterize my dependency 
network for CI with Hudson!  

> 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.

Yes - I didn't use the MaterializationStatistics class at this point 
without further conference with you.  I implemented a very simple 
IChangeLogger interface which gets setup on the MaterializationContext by 
the import command.  There are Null and XML implementations.  

One thought is that the MaterializationStatistics.m_updated field track a 
list of "ComponentChange" objects each of which tracks timestamp, author, 
comments and an (optional?) list of changed paths (each of which is an 
action (Add, modify, delete, replace) and a file path).  This would track 
the update information and could be serialized afterward by the import 
process.  Does that sound right to you, Thomas?

> Regards,
> Thomas Hallgren