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.
Casper Hornstrup
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 12:21:57 2002