| [news.eclipse.tools.buckminster] Re: Buckminster updating / change-list generation |
Peter M. Murray wrote:
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
Got it :-)
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.
True. I think you and Johannes are best suited to come up with a solution for this. Whatever you decide will be OK.
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?
Yes. That sound just right.
- thomas