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


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


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?)
- implemented for Subversive the polling functionality


Possible improvements:
- stop the polling as first reader encounters desired update
- others?

I've also taken a pass at the Hudson end, Johannes. I've introduced an SCM implementation that knows how to run buckminster to poll one or more cqueries and use the update to perform incremental updates with change log reporting.

Now that the prototype seems to be up and running - any suggestions on improving the architecture / implementation?

Cheers,

pete