Les Mikesell wrote:
> David Chapman wrote:
>>
>>> 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.
>
> Maybe I misunderstood, but I thought you were trying to apply lessons
> learned under CVS to operations using subversion, but they are very
> different beasts. CVS basically controls file revisions
> independently, so you are almost forced to use tags to identify a
> related group of files in a particular state. If you didn't tag every
> state that you wanted to be able to reproduce, I can see why you would
> have had problems that would make you think you needed better
> isolation from concurrent changes. But with subversion, any committed
> state is reproducible with just the global revision number - and if
> you find a need to branch for changes based on an earlier revision it
> is no harder than doing it from the head.
No, I was bemoaning the lack of easy branching in CVS. When I left, I
set up a Subversion repository for my own work. I would hate to go back.
Feature branches are helpful in EDA for individuals or groups who are
developing or modifying optimization algorithms; these efforts easily
take weeks. Leaving the changes outside of any version control for that
period of time is a scary thought. Once the enhancements are complete,
the feature branch would be reintegrated into trunk, tested to ensure
that QoR did not degrade in surprising ways (it happens - optimizations
can interfere with each other), and committed.
>
> > 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.
>
> I agree that there can be reasons to branch for development. I just
> don't understand why the case you describe isn't an arbitrary choice
> between branching for development while you do QA on the trunk or the
> more natural branch for QA/release while development continues on the
> trunk. Maybe I'm missing something.
The confusion is probably because I didn't mention the lengthy time
period for algorithm development (continuous integration doesn't apply
if the algorithm isn't done yet). Both feature branches and release
branches would be used in this type of flow. Once the feature branches
are all reintegrated, a release branch would be made. Bugs and QoR
issues would be resolved in the release branch (and eventually
reintegrated to trunk).
--
David Chapman dcchapman_at_earthlink.net
Chapman Consulting -- San Jose, CA
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1230892
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-26 05:39:49 CET