Re: Sparse Directories vs Externals

Les Mikesell wrote:
> 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.
First of all, I did not set up the CVS system or its policies. As I
mentioned, tags were created nightly for reproducibility purposes. Tags
for ordinary commits were not created, period.

Branches for releases were done only once a week or so (company-wide); I
saw only one or two developer-specific branches for my group in the time
I was there. Basically, branches were not available to us. I would
have liked them so that I didn't have to rely on my hard drive staying
alive (few developer machines were archived on a regular basis because
there would be terabytes of build products and test runs per night).

The long period of time required to run pre-commit regressions led to
problems, as I mentioned. If branches were cheap as in Subversion we
could have committed, tested, and merged once we were satisfied with the
results, but branches were not generally available.

>
>>> 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 repository.
>

Again, I did not set up the CVS system and tags were made only once per
day. That was the way it was done.

I really don't see the point of criticizing a CVS development
environment on a Subversion mailing list. There are Software
Engineering reasons why developer branches are sometimes better than an
"all on trunk" or continuous integration development methodology, and I
have tried to explain them. The long validation time before or after a
commit is always going to lead to synchronization problems, which we
dealt with. Cheap branches could have made it easier (especially with
proper merging and reintegration practices) and safer (since the
developer's workspace would no longer be the golden copy) to develop new
optimizations.

I don't know whether the company is still using CVS; I do know that
several years ago they broke one commercial product when they tried to
switch (I don't remember which one and couldn't tell you anyway due to
an agreement the vendor insisted on when they refunded the money paid).

-- 
    David Chapman         dcchapman_at_earthlink.net
    Chapman Consulting -- San Jose, CA
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1229927
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].