On 8/3/05, ed.wittmann@fiserv.com <ed.wittmann@fiserv.com> wrote:
> It's the confusion about this and lack of a perceived structure to
> branching and tagging that is leaving large-scale projects and neophyte
> users wanting more - hence the need for a layer on top of Subversion.
>
> People are looking for a CM system, and Subversion is not a CM system - it
> is a source versioning database system. That's it.
I'm no neophyte. I've been doing CM for over 20 years. I've worked
with over a dozen various version control systems including one I
hacked together with a bunch of shell scripts that merely used basic
Unix commands like "cp" and "mv". In all of these system, there was
the concept that branching and tagging were more than just copying
files from one directory to another. There was a concept that the
branch or tag was somehow related to the trunk, and that the system
should be smart enough to understand this.
Merge and diff command should be able to simply take the name of the
branch or tag. The user should not have to figure out where the
physical tag or branch is actually stored, then type in the whole
directory name. Checking out from a branch should only require the
name of the branch and not where that branch might actually be stored.
The system should be smart enough not to let the user treat a tag as a
regular directory. It should be almost impossible to change a tag by
simply doing a checkout and commit.
In the end, I don't care if Subversion stores tags and branches in
pseudo-directories. I simply want my version control system to
understand that if I say "compare this file to this branch or tag", it
can quickly find the branch or tag and do the comparison. It shouldn't
be my job to track down what I'm looking for.
The system should be smart enough to know that if I say "merge this
branch or tag with my working directory", it should be able to find
the branch or tag, figure out what needs to be merged, and does the
merging. I shouldn't have to figure out where the branch or tag is
actually located or what portions of the branch were previously merged
into my current working copy.
The system should be smart enough to know that tags are different from
branches in one main respect: Branches are versioned while tags are
snapshots. I shouldn't be able to "checkout" a tag, make changes, and
then commit those changes back into my archive without a second
thought. In RCS and CVS, you can't change a tag without giving the
command a special -F parameter. In ClearCase, you must give the
mklabel command a "-replace" parameter. Plus, you can lock the tag to
prevent any changes to it.
>
> I've been evaluating CA's Harvest product, and ClearCase. I can tell you
> that underneath all the functionality is a source versioning system - the
> value-add these products provide is a CM layer on top that regulates and
> adds meta-information to versions, and regulates user interaction with the
> versioning system.
I dont' know about CA's Harvest. It's probably one of the few CM/VCS
that I haven't used. However, I've been a ClearCase administrator for
almost 15 years, and I don't consider what is called Base ClearCase a
CM system. It is merely a Version Control System. Yes, it is an
extremely high end system with tons of bells and whistles, but in the
end, it merely does version control. To do CM, you have to build a
layer on top of it.
IBM/Rational did this with a layer on top of ClearCase called UCM.
Compare ClearCase UCM and Base ClearCase, and you'll see the
difference between CM and Version Control. In ClearCase, users still
work with branches, labels, source archive storage, etc. Under
ClearCase UCM, users are kept away from the underlying basics and use
concepts such as "tasks", "streams", "baselines", "changesets",
"projects", and "components".
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 3 19:49:02 2005