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.
> 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 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
> 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).
Changes in the workflow process are generally needed to change from CVS
to subversion (or probably anything else) - especially if you depend on
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-26 03:36:28 CET