|
转贴: clearcase和svn的比较:
http://bitsko.slc.ut.us/blog/clearcase-svn.html
Ken MacLeod
ClearCase and Subversion
6 comments | Mar 13, 2005 | permalink
Introduction
This is an ongoing article, I'll be adding to it as I learn more. [Updated 2Apr2005: added more unique features.] [Updated 2Oct2005: added mis-features; minor updates; Remko Seelig and Dan M. answer some lingering questions.]
This article contrasts ClearCase UCM and Subversion (SVN). It exists primarily as a place for me to clarify my thoughts when discussing ClearCase. Software configuration management is one of my specialties. I've been using ClearCase for about a year now at work and continue to use Subversion and CVS at home and on open source projects. I've also used Perforce , Aegis , PVCS , RCS, and SCCS.
Background
From the ClearCase WikiPedia entry ,
Rational ClearCase is a software tool for revision control (configuration management, SCM etc) of source code and other software development assets. It originally derived from a product of Apollo Computers: DSEE (Domain Software Engineering Environment), which was ported to Unix and further developed by Atria Software after Hewlett-Packard bought Apollo. Atria later merged with Pure Software to form PureAtria. That firm merged with Rational Software, which was purchased by IBM. IBM continues to develop and market ClearCase.
In or around ClearCase version 4, ClearCase adopted Rational's Unified Change Management (UCM) process as its recommended "out of the box" experience. "Base ClearCase" is used to refer to the original usage. UCM is a process that can be applied with any tool, but ClearCase adopts the terminology and includes wizards to assist in setting up repositories in the UCM recommended way (ie. joining projects, creating projects).
ClearCase marketing and documentation promote UCM as simpler than Base ClearCase because it encourages a single process. Base ClearCase is often referred to as "very flexible", requiring "lots of scripts and triggers to implement a process", where UCM automates much of this "out of the box". However, I think in this case "very flexible" is a euphemism for "unnecessarily complex". Subversion appears to be every bit as capable in terms of flexibility and its ability to support the UCM model, yet is much simpler out of the box.
In this regard, Perforce and Base ClearCase are similar in that they require a lot of unnecessary user configuration up-front when setting up workspaces and extra work in submitting changes. In other words, UCM is automating work that shouldn't have needed automating in the first place.
The three and a half types of version control tools
1) The first tools, RCS and SCCS, worked on individual files. You checked out and in individual files.
2) Tools like CVS and ClearCase work on directories of files, but still have much of a "per-file" approach to working. In CVS, it's common and recommended to commit related changes in one step. In ClearCase, it's common to commit files independently and then, for example, use UCM's activities or deliveries to commit related changes.
2.5) Perforce and Subversion really do work on directories of files. In these tools, it is not only recommended to commit related changes together, but the tools can track changes to the directory tree as independent, sequential changes.
3) BitKeeper, Arch and Darcs are "changeset oriented" tools. While technically, any sequential change is a changeset, these tools excel at non-sequential changesets, as is very common in decentralized development, such as the Linux kernel, where changesets against independent streams of development are passed among developers.
See On Arch and Subversion for a more detailed description of the snapshot and changeset models of version control tools.
Unique ClearCase features
Multi-Version File System (MVFS)
ClearCase "dynamic views" are made available to the user through a virtual filesystem. MVFS enables multiple developers using the same stream to see each other's changes as soon as they are checked-in (for better or worse, more on that later), it also allows for build avoidance (sharing derived objects among multiple users), and auditing.
Version tree browser
This graphical tool shows the branch and merging history of a file or a component as a whole. However, UCM's emphasis on per-release projects, multiple integration streams, and per-developer streams tends to produce spaghetti graphs instead. The TortoiseSVN client for SVN has this feature, but SVN itself does not yet track inter-branch merges so it limits its usefulness. Merges in ClearCase that aren't performed using deliveries are not tracked.
Multi-site
ClearCase multi-site provides automatic replication of repositories, which can speed access for very large components. When ClearCase is used to distribute build artifacts (tarballs, release images), it makes keeping all sites in sync automatic.
Unique Subversion features
Branches and labels in the filesystem
SVN exposes branches and tags directly in the repository filesystem tree. Thus, there are no branching, baselining, or labeling commands in SVN, nor is it necessary to use options to indicate which branch or label you are referring to when merging, diffing, or browsing. (Note: SVN calls their repository the "filesystem", not to be confused with ClearCase's MVFS, which is literally mounted on your development system.)
ViewSVN and ‘svn diff'
You can browse an entire Subversion repository, backwards and forwards in time. You can diff any two branches or revisions by path or number, respectively.
In ClearCase, you must create a view on a stream before viewing any of that stream's content, you must create two views to be able to diff them. Viewing a prior baseline in ClearCase requires creating a child stream, and its associated view, on the older baseline. It's also possible to create a view and then change the "view configuration" (a very advanced feature for UCM users), but would be faster if you need to step through several baselines.
Web-enabled, remote development
SVN works very well for distributed development. It scales much further with remote access before having to implement replication. SVN uses standard Internet protocols for repository access, simplifying remote development.
Unique ClearCase mis-features
Slows down with too many activities/baselines
ClearCase severly slows down when a project has too many activities/baselines. This precludes the most common and simplest form of codeline development used in other revision control tools: mainline as latest and greatest. In other tools, development is performed against the mainline ('trunk' in SVN) and branches are created off the mainline for release maintenance. Fixes and updates made on maintenance branches do a one-way merge back to the latest and greatest.
ClearCase recommends that latest and greatest development occur on a release project, and then release projects merged to a docking mainline. The docking mainline is intended to prevent regressions, but in practice the two-step merges (to mainline, to current release project) is still prone to regressions.
[See Streamed Lines: Branching Patterns for Parallel Software Development for details on codelines, branching, etc.]
Multi-site delivery requires local development stream and remote login
ClearCase's emphasis on dynamic views requires a local repository mirror to support local development streams at multiple sites. Delivering to sites mastered elsewhere requires a login at the mastering site with appropriate remote-GUI support. Remote delivery is also fragile (mostly due to where and when streams get locked and how those locks are recovered).
Unique Subversion mis-features
Merges are not tracked by the tool
If you have, for example, maintenance release branches it would be nice to be able to see, in the tool, when changes were merged. There are also some cases where a diff tool can make use of knowing when files have been merged before. SVN and CVS users rely on change comments to indicate merges. Note, however, that SVN and CVS projects don't typically use per-developer branches (streams) so their merge histories are correspondingly simpler than ClearCase merge histories.
Labeling, branching, and filenames
Labeling
Labeling in CVS and baselines in ClearCase UCM are straightforward and traditional, after a label or baseline is applied you will know that for any given label you will know each revision of a file that has that label or is in that baseline. The same is true for Perforce, except that creating a label requires filling out a form.
Subversion takes a little different approach. Because branching is cheap (and easy) in Subversion, they use the same mechanism. The only difference between a branch and a label in Subversion is policy: you don't make changes in the label tree. The greatest benefit here is that the entire facet of labeling commands and flags go away. You create a working copy of a labeled snapshot just like creating a working copy of the mainline or any branch.
Branching
Branching in ClearCase UCM is done using "streams" and "projects". UCM recommends, and defaults to when using the "join project" wizard, of creating per-developer streams (branches). In the default model, making changes available to others (integrating) always requires two steps, check-in and delivery. IBM/Rational recommends using "waterfall" branches for releases, that then get "docked" to a mainline to prevent losing changes or permanent diversion, using a "project" as the container for each release and the mainline. The primary reason for a "docking mainline" rather than "latest and greatest mainline" is performance, ClearCase UCM slows down on projects with many baselines.
Branching in Subversion, and also in Perforce, occurs in the repository tree. You "svn copy" a directory to a new location in the repository to make a branch (Perforce uses "p4 integrate"). Branches in Subversion are cheap and easy, allowing a project to use as many or as few as their process would need. Subversion folks recommend the following repository structure for most initial projects, but it's entirely convention:
/myproject/branches/ /myproject/tags/ /myproject/trunk/ foo.c bar.c Makefile
The 'trunk' is for latest and greatest development, 'tags' are for labeled snapshots, and 'branches' for named branches where additional work occurs. If you commonly have per-developer streams or feature branches independent of releases, you could use a structure that includes 'user' or 'releases'.
Although technically possible, it is usually a user error to create a working area from '/myproject' because you will get multiple copies of every file from the trunk, each tag, and each branch. You typically create a working copy from a lower level in the repository structure.
SVN branches are "lightweight" in their usage, requiring very little ceremony to use ('svn copy'). ClearCase has two different, heavier branching techniques: creating projects (very high ceremony) and streams.
File version naming
CVS was originally based on RCS, and both RCS and SCCS use perturbed¹ version numbers for branch file names, like 1.1.2.1.1.1 (based on the branching source and depth). You can request a specific branch and version of a file by specifying its perturbed revision number or a label.
In Subversion and Perforce, the branch name is an arbitrary part of the file name, it's path from the root of the repository to the file. The version number of each file is a global, sequential transaction number. You can request a specific branch and version of a file by specifying it's path at given transaction number (or date, and in Perforce, by label).
In ClearCase, you use "extended naming" to request a specific branch and version, like 'foo.c@@/main/somebranch/1'. However, UCM complicates this almost to the point of unusability, because the extended names concatenate for each stream. If a file, created in the integration stream, was modified in a developer stream (and therefore was branched to that stream) it would be something like:
foo.c@@/main/project_integration_stream/developer_stream/2
Basic work cycles
Subversion
When you first join a project in Subversion, you run 'svn checkout' to create a working copy. Subversion uses the "copy-modify-merge" model of working areas, so every file and directory is writable and the developer is required to merge changes from the repository before committing their own changes. When finished with a project, the developer simply removes the working area.
(See Eric Sink's Source Control HowTo for more detail on the copy-modify-merge and lock-modify-unlock models. Eric calls them edit-merge-commit and checkout-edit-checkin, respectively.)
A typical Subversion session begins with 'svn update' to receive any new changes from the repository. Changes are made by editing files and using the Subversion commands add, delete, copy, and move. Current status is obtained using the commands status, diff, and revert. When the developer is ready to commit, they will again run 'svn update' to merge changes from the repository, resolving any conflicts, and then committing their work.
ClearCase the UCM Recommended Way
When you first join a project in ClearCase, you use the ClearCase Project Explorer to join a project. The "join project" wizard will create a view on the integration stream, create a development stream, and create a view on the development stream. ClearCase dynamic views only support the "lock-modify-unlock" model of working areas, so all files are read-only and directories must be checked-out before adding, moving, or removing files from version control. When finished with a project, the developer uses the ClearCase Explorer or ClearCase Project Explorer to remove their views. The development stream is a permanent part of the project and is never removed.
A ClearCase session begins by rebasing the development stream from the integration stream (in a dynamic view, these updates are visible immediately in the view) and setting an "activity" (naming the changeset) for the session. Even though each developer has their own development stream (branch), they are still required to check-out each file and directory before they make changes. The ClearCase Windows GUI will automatically check-out and in directories in several cases when files are added, moved, or deleted in version control. The developer can check-in files into their development stream at any time to checkpoint their work. Current status can be viewed in the ClearCase Explorer or from the command line. When a developer is ready to deliver their changes, they must check-in any outstanding check-outs and initiate delivery to the integration stream. Any merge conflicts encountered during the delivery are resolved in the integration view.
Remko Seelig expands on merges,
Merge conflicts are resolved in the stream that is marked as target, e.g. if you deliver TO integration, it will be merged in integration. If you rebase TO your developer's stream, it's merged in the developer's stream.
In UCM, you can define policies that allow or prohibit deliveries with checkouts. You can also prohibit deliveries of streams that have not been rebased to the recommended baseline yet. The reason for that is that it's recommended to lock a stream before delivery: if a developer's delivery to integration would result in many merge conflicts, it may take some time for him to complete it. This will affect others because they won't be able to deliver their changes and to get other updates. e.g. it will generally slow down development. If you would rebase first, all other changes will be merged into your stream, you can resolve merge conflicts locally (your own stream) and deliver afterwards, minimizing merge conflicts / delivery time.
ClearCase UCM a little simplified
A project's developers can choose not to use independent development streams and instead all create a working view on the integration stream.
In this model, every session always starts as "updated" because dynamic views always reflect the current version state of the repository. An activity for the session is created. Developers check-out files and directories as needed, reserved or unreserved, and check-in their changes. [Dan M. answers the questions, "how are unreserved check-out conflicts resolved?"] When someone checks in their unreserved checkout before you check yours in, you are required to merge into it. A merge arrow is drawn from your version to theirs.
The biggest drawback to dynamic views on a single stream is that all developer's views are affected immediately whenever a developer checks in their changes.
ClearCase UCM with snapshot views
A project's developers can choose not to use independent development streams and instead create snapshot views on the integration stream. Snapshot views use the host's filesystem (network or local) for the working area.
A session begins with 'cleartool update to receive any changes from the integration stream. An activity for the session is created. Developers check-out files and directories as needed, reserved or unreserved, and check-in their changes. [when are merge conflicts resolved?]
This model is not well supported by ClearCase and is discouraged, sadly.
A monologue about dynamic and snapshot views in ClearCase and their support. - Cecil Morris
References
* UCM for Zealots: Moving from Base Install to UCM ClearCase
* The power of Unified Change Management
* Perforce: Comparison with ClearCase
1. Thanks to Perforce's CVS comparison for that eloquent description of RCS and SCCS branch numbering.
This article come from: http://www.scmbbs.com，
The full content see: http://www.scmbbs.com/en/cctp/2007/11/cctp1.php ©CopyRight belong to xuejiang andthe (SCMbbs.com)together;
Origin requested on transmited.
|