David Chapman wrote:
>> If you each make more than one change, shouldn't the point be to find
>> how each specific change affects performance more than the ownership
>> of the code?
> Electronic Design Automation (EDA) software is a series of heuristic
> optimizations applied to non-linear, discontinuous functions. An
> experimental optimization might make some results better and some
> results worse. If, for example, an evaluation of a change over 50
> designs resulted in an average 0.5% improvement with no design degrading
> by more than 0.2%, the change looked good and would probably be
> accepted. Merging other changes during the course of the experiment
> would increase the noise and make the analyses harder. I had to learn
> this the hard way.
OK, but how does this relate to the difference between running your
changes/tests on a tag or specific revision while the trunk advances or
testing trunk/head but forcing it to stop advancing while development
moves to isolated branches? I don't see a big difference. You still
have to decide what points you want to test. You still have to deal
with conflicting changes.
>> I don't understand. Are you saying you actually broke CVS with a
>> commit or that you couldn't do what you want with a known revision?
>> Or that since you didn't tag, you didn't know which revision to get?
> Finding compile errors was relatively straightforward, but still
> required a call to the developer. Finding QoR degradations required
> actually running test suites.
If a workspace compiled and a tag was made from that workspace after
committing, it should be reproducible. If that's not how you were doing
it, I'd expect random things to happen. With subversion you can get the
same effect by specifying a revision number since they are global to the
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-26 01:02:13 CET