Casper Hornstrup wrote:
>lør, 2002-08-03 kl. 01:53 skrev Greg Hudson:
>
>
>>Saved transactions are a possible post-1.0 Subversion feature,
>>definitely. The hard part would be the case where auto-merging can no
>>longer be done on the saved transaction, so that it can't be committed;
>>do you have to recreate the transaction, or is there some way you could
>>manually merge an existing transaction?
>>
>>
>
>So, is delayed transactions planned for Subversion? If so, I have an
>idea for another use for them. If the state of the transaction
>(commit/rollback) can be controlled from an external program or script,
>then it would be possible to prevent regressions in the repository. I'm
>developing an open source OS that has the potential to be compiled for a
>large number of targets. As the number of targets increase, it would be
>harder to prevent regressions or even simple compile errors on targets
>where the patch has not been tested. If there is a large number of
>targets, then testing a (small or large) patch on all targets will take
>too much time. So why not integrate a regression framework with
>subversion? Then, when a commit is attempted, the regression framework
>checks out a copy with the attempted change, compiles it, and runs any
>tests and if all is okay, reports back to subversion asking it to commit
>the transaction, otherwise it tells subversion to rollback the
>transaction.
>
>
IMHO, it would be much more useful to have these commits go into
branches rather than be transactions. Your integration environment could
take a branch, merge it into the head revision and compile/test on all
platforms. If it passes, it gets committed with the changes from the
branch. If not, the developer has the list of failures and can then
correct and resubmit.
-David Waite
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 19:07:51 2002