Hi,
> >
> >I don't want to start a Holy War, but CVS is great for tracking changes
at
> >the file and directory level, but it lacks built-in support for getting
> >"meta-data" on the changes, i.e., to answer queries like "what files were
> >changed for bugfix 17, when and by whom?"
> >
> What about "cvs -qn up -r bugfix16"?
>
Exactly my point - you have to define a label "bugfix16", and adhere to that
naming convention. What if someone creates a label "BugFix18"? The system
does not enforce any policy - you need the discipline to adhere to naming
conventions, and the luck to avoid typos...
> >and "what bugfixes made it into release 3.4?".
> >
> That depends on your setup. If you kept a good log in the history, there
> is no reason to not be able to answer that (and CVS can be configured to
> require you to do so).
Again, I agree that this is *possible* in CVS, but it depends on the
goodwill, self-discipline, and luck of all the programmers involved.
>
> > Also, it has no explicit idea of a development cycle (coding, unit test,
integration, release, maintenance).
> >
> Please explain.
>
Explicit knowledge of the development process makes it easier to handle the
files/revisions associated with changes. For example, if I fixed some files
so that they pass my unit tests, but didn't pass integration tests yet, the
changes should be visible to another programmer, but not to the release
builder, say. Again, I'm not saying that you can't do these kind of tricks
with CVS, but a commercial configuration management tool makes this easier,
and enforces the policy/process that you've defined.
> >
> I don't think it makes sense to try and compare CVS with Rational Rose.
> It's like asking whether Mozilla is better than kreversi.
>
Violent agreement here.
Rony
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
