Home » Archived » Buckminster » Buckminster updating / change-list generation
| Buckminster updating / change-list generation [message #468199] |
Tue, 04 August 2009 13:41  |
 Peter M. Murray
Messages: 24
Registered: July 2009 |
Junior Member |
|
|
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
|
|
| |
| Re: Buckminster updating / change-list generation [message #468298 is a reply to message #468199] |
Tue, 04 August 2009 22:56  |
Henrik Lindberg
Messages: 2509
Registered: July 2009 |
Senior Member |
|
|
I don't quite get the use case.
What exactly is it you want to keep track of?
Is it the delta between "what you have in your workspace", and "what you
will have if you run a query"? A sort of "team synchronization" but done
by Buckmisnter so it involves everything in the query, not just the
source code repositories...
Or, is this intended as a mechanism to update a workspace for the
purpose of making it faster to only update it instead of re-creating it?
Regards
- hnrik
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
>
|
|
|
| Re: Buckminster updating / change-list generation [message #468303 is a reply to message #468298] |
Wed, 05 August 2009 00:40 |
Peter M. Murray
Messages: 24
Registered: July 2009 |
Junior Member |
|
|
Hi Henrik,
Hudson has a concept of an SCM module which is responsible for:
* checking out the project's specified source
* polling and reporting (yes or no) if the sources required have changed
since the checkout (or last update)
* updating the sources and (optionally)reporting a log of changes,
comments, users, etc if available
Buckminster as it stands is great for the first responsibility, but
doesn't have any functionality for the latter two.
It seems to me that most of the Buckminster readers (CVS, SVN, p2 sites,
urls) can provide these additional functionalities if desired (at least
the updating and polling, in some cases without change-log)
We could then extend the current Buckminster/Hudson integration to include
an SCM module for seamless CI integration. You'd just specify the
Buckminster for the SCM, type in the cquery URL, then specify a
Buckminster build-step to perform whatever build operation you desire.
Right now, I have Hudson check out my Subversion sources (which
unfortunately requires that they share a common root folder and then use a
"local" Buckminster source to wire-up my sources for building. This means
I have to manually sync my Hudson configuration with the dependencies in
my plugin projects.
Only Buckminster has enough context to perform these operations without
hard-wiring dependencies etc.
Does that explain the use-case?
Cheers,
pete
|
|
|
| Re: Buckminster updating / change-list generation [message #468334 is a reply to message #468199] |
Wed, 05 August 2009 07:16 |
|
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.MaterializationSta tistics). 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
>
|
|
|
| Re: Buckminster updating / change-list generation [message #468347 is a reply to message #468334] |
Wed, 05 August 2009 08:15 |
Johannes Utzig
Messages: 329
Registered: July 2009 |
Senior Member |
|
|
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.MaterializationSta tistics).
> 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
>>
|
|
| | | | | |
| Re: Buckminster updating / change-list generation [message #478675 is a reply to message #468457] |
Thu, 06 August 2009 11:24 |
|
Peter M. Murray wrote:
> Hi Thomas,
>
> I'm struggling with understanding that UPDATE/REPLACE should suppress
> both workspace and target platform resolution. I have cqueries that
> ultimately want to find target platform components for resolution. The
> cquery is not materializing those elements (e.g. equinox plugins). If
> UPDATE suppresses finding them at all, wouldn't the resolution fail in
> that case?
>
Right. Something is wrong with that idea :-). We cannot suppress target platform resolution since we don't know how the
TP was originally populated. Not in it's present shape.
The correct way to resolve this is probably to change how the p2 materializer configures the target platform definition.
Currently, we just use a "Directory" container and put everything there. This could be more sophisticated so that we
generate one or several "Software Site" containers that uses a slicer by default. A "Software Site" knows its origin and
knows how to perform an update. It would also give the user a better experience when accessing the TP definition in the
UI. Not sure how to go about listening to the update events though.
Perhaps you should defer the TP update for now?
Regards,
Thomas Hallgren
|
|
| |
| Re: Buckminster updating / change-list generation [message #478705 is a reply to message #478680] |
Thu, 06 August 2009 13:17 |
|
Wow!
This sounds great Peter. Some comments inline. I do understand that what you have is a prototype and as such I think
this sounds really good.
Peter M. Murray wrote:
> Hi Thomas,
>
> I have a working prototype in my workspace of what we've been
> discussing. Here's how it's functioning now:
>
> 1) -U indicates to the import command to perform an update. -O
> specifies the log file output
OK.
> 2) The import command scribbles on the cquery to add an advisor node
> which indicates useWorkspace=false for everything
> 3) The SVN reader always updates (switches, really, in case the url has
> changed) if there is an existing svn checkout in the destination location.
> 4) The SVN reader generates log events to an observer
>
Is this implemented in the generic part of the SVN reader (i.e. the part used for both Subclipse and Subversive)?
What is needed to get the same type of events from CVS? Is that easy to achieve?
> I used #2 instead of the ConflictResolution for two reasons:
> - Minimize code changes to prototype (e.g. constructor bloat on the
> RMContext subtypes)
Couldn't you just add a setter/getter for this attribute to the RMContext? The initial value would be KEEP.
> - More importantly - I had to do something to make the target platform
> resolution step not look at the workspace. Since I wasn't sure how best
> to do that, I put the check & filters right in the findBest* methods by
> asking the cquery.useWorkspace(). Those methods don't have an RMContext
> available
>
I think they do actually. The IVersionFinder has a getQuery() method. It returns the NodeQuery which in turn has a
getContext() method.
> This really was an attempt to feel out the edges of the task more than
> implement a "right" approach - so we can totally rework it. It really
> hinges on what is the right fix for the useWorkspace issue. I've posted
> a mininimal script to reproduce this issue in a separate posting.
>
I'll have a look at that when I'm back from vacation (Monday).
Regards,
Thomas Hallgren
|
|
| | | |
| Re: Buckminster updating / change-list generation [message #478972 is a reply to message #478947] |
Fri, 07 August 2009 17:41 |
|
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
|
|
|
| Re: Buckminster updating / change-list generation [message #478973 is a reply to message #478972] |
Fri, 07 August 2009 18:06 |
Peter M. Murray
Messages: 24
Registered: July 2009 |
Junior Member |
|
|
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
|
|
|
| Re: Buckminster updating / change-list generation [message #478976 is a reply to message #478973] |
Fri, 07 August 2009 18:17 |
|
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
|
|
|
Goto Forum:
Current Time: Fri Apr 19 09:57:50 GMT 2024
Powered by FUDForum. Page generated in 0.03147 seconds |
] 
Search
Help
Register
Login
Home
