I'm afraid this isn't working for me.
Our system is structured like this:
default.build is our bootstrapper. It sets up shared properties for all of the builds and loops through a CSV file calling the specified targets against ProjectTemplate.build for each line in the CSV file with the <nant> task. This calls each Target in a separate instance of nant against ProjectTemplate.build. If I include the Rollback.xml in ProjectTemplate.build, then it can only rollback in the scope of the current targets and the stack is useless. If I include Rollback.xml in default.build, then the stack is always lost at the end of each <nant> task.
This gets back to my earlier point that this needs to be transitory between nested calls to the <nant> task. This obviously is possible for nant.onfailure to exist and function, but there needs to be a way to build a stack between n number of calls to the <nant> task.
Now, thinking about this also makes me realize that not only does rollback need to call the targets, but they need to call the targets with the correct parameters to recreate the environment that existed when the rollback action was added to the stack. To me this implies maybe it's not going to be feasible to implement such a feature without building the transactionality directly into NAnt because the complete project state must be stored on the stack to allow the rollback action to have complete knowledge of the state at the time of pushing to the transaction stack. I understand this could be a rather large memory overhead, but we could also write an xml document in a temp file to describe the stack and modify it on the fly. Using a file to represent the stack allows the <nant> task to be spawned to a new thread or processes.
Payton Byrd Trane eBusiness QED Team Phone: 931-905-5386 Fax: 931-648-5901
Payton,
you're right, the variable-based stack unfortunately won't work across build files.
One idea that may be a partial solution is to only use the rollback stack in your parent build script, and call rollback targets in the child build files... this reduces the granularity of your rollback, but is perhaps better than nothing. If completion of a child build file (from a <nant> call) fires a build event, then you would still be able to create an extended rollback solution with multiple (nested) rollback stacks so you could provide rollback in your child build scripts, too.
Also, just a comment on your suggestion that NAnt should magically support rolling back... how many NAnt core tasks do you think it's actually feasible to automatically rollback? How do you rollback <copy>, or any other task which could overwrite or modify a file... <attrib>, <delete>, <ndoc>? What about a <cvs-update> that changes the sticky tag?
How do you specify how to rollback an <exec>? Do you have to rollback a <get>? What happens if hitting the URL triggers some effect, such as (to take an example from the java world) redeploying a servlet?
As I mentioned in my previous email, the _only_ person who knows how to roll back what's done in your script is you. The writer of the task surely doesn't.
Good luck with your system,
-- Troy
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Nant-users mailing list Nant-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
