lør, 2002-08-03 kl. 19:07 skrev David Waite:
>
>
> 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
Would this not make it more difficult than necesarry for the developer?
I mean, the developer would then have to commit to a branch that would
be dead after the commit, right? So, after the commit, the developer
would have to switch the working copy to the HEAD branch to get other
updates. In essence, the process would be like this:
* Create a new branch and switch the working copy to it.
* Implement something on the new branch.
* Commit the patch to the new branch - and the regression framework
would then do it's thing and notify the developer by mail
(or a mailing list) of the results.
* If all okay, switch back to the HEAD branch to continue development.
* If not okay, fix and recommit.
Or did I miss something?
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 20:42:47 2002