You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gabor Szabo <sz...@gmail.com> on 2005/07/04 11:01:37 UTC
Subversion vs. Clear Case
A potential client is evaluating Subversion vs Clear Case.
Someone in their organization wrote up a comparison in Hebrew
and asked me to look over the text. Instead of just giving feedback
on my own I decided (with their agreement) to translate the document
and ask the opinion of the wider CM community.
I'd reall appreciate (on their behalf as well) feedback to this document.
http://www.pti.co.il/clearcase_vs_subversion.html
In the source of the above file there are a number of comments I made.
You can comment on them as well.
thanks in advance
Gabor
ps.
I asked the same question on CM CrossRoads 2 days ago.
If you are interested reading the responses, here is the link:
http://www.cmcrossroads.com/ubbthreads/showflat.php?Number=46780
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by David James <ja...@gmail.com>.
Gabor Szabo wrote:
> http://www.pti.co.il/clearcase_vs_subversion.html
Hi Gabor,
Under "Integration with Development Tools", you mention that ClearCase
offers good integration with Windows Explorer. You may also want to
mention here that Subversion supports the same features via
TortoiseSVN. I see that TortoiseSVN is mentioned later under the
"Clients" section, but some people may miss this.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Gabor Szabo <sz...@gmail.com>.
On 7/4/05, Ulrich Eckhardt <ec...@satorlaser.com> wrote:
> Gabor Szabo wrote:
> > http://www.pti.co.il/clearcase_vs_subversion.html
>
> Not only checkout and checkin require repository (network) access, but also
> history browsing. Not sure if that changes with SVK, no idea of Clear Case.
With SVK you can have full repository mirror on your local machine
meaning you have all the history at hand, off-line, up to the last
time you synced.
Gabor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
Gabor Szabo wrote:
> http://www.pti.co.il/clearcase_vs_subversion.html
Not only checkout and checkin require repository (network) access, but also
history browsing. Not sure if that changes with SVK, no idea of Clear Case.
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Brad Appleton <br...@gmail.com>.
>>>- Dynamic views
ClearCase implements a Virtual file system providing a vie winto
multiple versions (a.k.a. MVFS - the multi-version file system).
What that means ... well, if anyone was ever a user of Sun's Network
Software Environment (NSE) which implemented the "Translucent
File-System" it was somewhat similar.
Each workspace (copy) is essentially a "mount point" for an instance of
the file system. A Clearcase "view" identifies a storage area/directory
(to hold locally created/generated files and files checked-out for
editing) and a set of version-selection rules (that decide which
version(s) of which files will be visible in the workspace). The
version-selection rules are called a "configuration specification" or
"config-spec" (abbreviated as "cspec")
If you use "dynamic" version selection rules such as /main/LATEST (or
anything that selects "LATEST" of any branch) then anytime someone else
does a checkin of that branch, your view is automagically and virtually
instantaneously updated with the new version of that file (unless you
already had it checked-out for editing).
That makes the "update" command obsolete in CVS/SVN. You dont need to
initially "populate" the workspace because readonly copies of everything
automatically appear when you create the workspace. And you dont need to
do an "update" to sync with the latest state of the branch because it
happens automatically (this can be a really good idea, or a really bad idea)
Furthermore, ClearCase's MVFS "extends" the filepath namespace with
version-extended path names. A normal file-path looks like it would on
the Unix command-line. So if I say "/top/src/hdrs/foobar.h" I will see
the version of foo.h that is selected by my config-spec
But if I use the version-extended namespace, I can say
/top/src/hdrs/foorbar.h@@/main/10 and it will refer to version 10 on
branch "/main" of the file. I can use any valiud "version selection
rule" after the "@@", such as a label (foobar.h@@/RELEASE-12) or an
attribute tag (foobar.h@@{PROMOTION_LEVEL="Baselined"} or if I just use
"@@" at the end (foobar.h@@) then the result is a directory containing
all versisn of that file visible in the version of that directory
>>>- Good branch/merge support (a lot better than e.g. Subversion)
Clearcase uses SCCS-style interleaved deltas (a.k.a. "inline deltas")
and upto 32-way diff/merge (e.g. comparing one base version against 31
different contributor versions). It tracks merges in the version-tree
and knows which versions contribuetd to which other versions and which
chunks of code from which deltas were already merged.
It can also support some algebraic merge operations such as a
subtractive merge (subtracting only one delta from a set of deltas that
were since merged into the file), or an additive sum (specifying exact
the set of deltas to include/exclude for a given file)
As far as branching, ClearCase is almost too powerful/flexible. There
are branch-types (basically the name of the branch) and there are
branch-instances (an instance of creating the named branch for a given
file). So I can easily use just the branch type (branch name) to
represent all the files and versions that were checked-out/in onto that
branch. Or I can refer to just one instance of the branch for a
particular file.
This means that, if I chose to do so, I could have different branching
topolgoies (structures) for different files and the same branch type. I
might have file1@@/main/foo/bar/3 and file2@@/main/bar/foo/2 and
file3@@/main/bar/4). Granted, most people dont do this, they attempt to
use more or less the same branching structure across all files! HOWEVER,
in ClearCase I only need to create versions for a branch if and only iff
I change the file on that branch. If I dont have to checkout the file
for editing in my view, there is no need to create an instance of my
branch for that file. So branches ocntain ONLY the files that needed to
change - not the whole repo)
>>>- ClearMake
Since ClearCase uses an MVFS, it can intercept all read/write calls to
access file versions during a build. This allows Clearcase to audit the
build, and detect every version of every file that was used to
build/generate another file or make-target. PLUS it knowns more than
just the file and version, it knows the command-line that was used to
create it.
This means for starters that if youre using ClearMake, you dont have to
maintain source file dependencies, CC will "learn" those when it does
its first build in your workspace. It also means that its smart enough
to know the impact of changing a build/compile command-line flag and
which targets are dependent upon it and need to be rebuilt.
Plus it automatically captures a configuration-record (config-rec) for
each built-target (a.k.a. "derived object") during the build. The
config-rec captures the "recipe" (command-line invocation(s)) used to
generated that target, and the full version-extended pathname of each
contributing source-file.
ClearCase also tracks a "cache" of built objects (with parameters that
can be fine-tuned) so that, if I need to build a target, it can look in
the cache to see a built-copy of it already exists with the exact same
contributing source versions and build-options and create a virtual
file-system link to the already built file instead of actually having to
build it (this is called "wink in")
The price for all of this (besides the big price-tag of Clearcase) is
that the multi-version file-system implemented by Clearcase is very
network resource intensive. It takes a lot more time and effort and
people to administer and configure.
And if you dont know what you are doing or dont plan it very well, some
of those things that would otherwise improve performance (such as
wink-in, and never having to "get/checkout" readonly copies of files)
can sometimes cost more network i/o cycles and bandwidth than theuy
would otherwise save.
--
Brad Appleton <br...@bradapp.net> www.bradapp.net
Software CM Patterns (www.scmpatterns.com)
Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Tor Ringstad <to...@tandberg.net>.
> Sounds a bit like using Subversion with davfs
Yes, it does. And believe me, being very much a ClearCase
affectionado, I've been following projects like davfs and svnfs
closely. There is, however, a lot more to ClearCase dynamic views than
these projects try to encompass.
> I'd argue that Subversion's *branching* can't be bettered. [...] The
> problem is in merge support
Yes, I totally agree to this.
- Tor Ringstad -
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Russ Brown <pi...@gmail.com>.
Tor Ringstad wrote:
>>>- Dynamic views
>>>- Good branch/merge support (a lot better than e.g. Subversion)
>>>- ClearMake
>>
>>I'd appreciate if you could explain a bit more what each of those
>>are (or in case of branch/merge) how are their better than that of
>>SVN.
>
>
> I'm not going to be able to give a good explanation here, each bullet
> is really a huge topic.
>
> 1) Dynamic views
>
> I think a good way to see a "dynamic view" is as a "dynamic working
> copy", transparently implemented as a regular file system. Handling
> working copies in this way has some very deep implications, and as far
> as I know this is an absolutely unique feature in CC. One particular
> consequence is no explicit checkout. "Working copies" (views) are
> created instantaneously and use no disk space.
>
Sounds a bit like using Subversion with davfs: that allows you to mount
a subversion repository to a local path, and if you enable autocommit on
the server side it will transparently commit any changes for you. I'm
using it myself for personal file (it's not suitable for source
management though).
> 2) Branch/merge support
>
> CC supports multiple merges between branches and merge of directory
> changes (move/rename), Subversion does not.
>
> 3) ClearMake
>
> Some keywords are dependency tracking and build avoidance (wink-in).
>
>
>>Could any of those achived by using SVK or some other 3rd party
>>tool?
>
>
> SVK might have better branch/merge support, but I'm not sure. I'm not
> aware of any other 3rd party tools that might help you achieve this.
>
I'd argue that Subversion's *branching* can't be bettered. It's an O(1)
operation which takes up practically no space. Branches can be stored in
whatever folder structure you fancy. I really don't see how it can be
bettered, though I'm open to arguments as to its shortcomings.
The problem is in merge support (different to branching). SVK *does*
have better merge support than Subversion. Merging between branches is
done without having to refer to revision numbers at all: svk takes care
of the merge-tracking for you. Commands like pull and push make it
childsplay to keep a branch in sync with the trunk (pull) and to merge
changes onto the trunk (push).
>
>>Are there plans in SVN to include those features ?
>
>
> Better branch/merge support is a stated "medium term" goal in
> Subversion, as per their web page.
>
>
> - Tor Ringstad -
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Tor Ringstad <to...@tandberg.net>.
> > - Dynamic views
> > - Good branch/merge support (a lot better than e.g. Subversion)
> > - ClearMake
>
> I'd appreciate if you could explain a bit more what each of those
> are (or in case of branch/merge) how are their better than that of
> SVN.
I'm not going to be able to give a good explanation here, each bullet
is really a huge topic.
1) Dynamic views
I think a good way to see a "dynamic view" is as a "dynamic working
copy", transparently implemented as a regular file system. Handling
working copies in this way has some very deep implications, and as far
as I know this is an absolutely unique feature in CC. One particular
consequence is no explicit checkout. "Working copies" (views) are
created instantaneously and use no disk space.
2) Branch/merge support
CC supports multiple merges between branches and merge of directory
changes (move/rename), Subversion does not.
3) ClearMake
Some keywords are dependency tracking and build avoidance (wink-in).
> Could any of those achived by using SVK or some other 3rd party
> tool?
SVK might have better branch/merge support, but I'm not sure. I'm not
aware of any other 3rd party tools that might help you achieve this.
> Are there plans in SVN to include those features ?
Better branch/merge support is a stated "medium term" goal in
Subversion, as per their web page.
- Tor Ringstad -
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Bob Proulx <bo...@proulx.com>.
Didier Trosset wrote:
> Dynamic Views ...
>
> From my point of view, I guess things happened this way: One day, a
[...very interesting discussion...]
> halted by a 15 minutes compilation.
I also think that much slower compilation machines than we have today
played a roll in the design. And flavored by also having a bunch of
identically configured machines. If someone else on the network has
already compiled that file, usually the one committing, then "why
compile it again" and so the dynamic view with the version filesystem
caused it to appear immediately already compiled. If your project
takes hours to compile then this has the potential to save a huge
amount of time.
But today's computers are much faster. One of the large projects I
work on used to take several hours to compile but is now down to ten
minutes for a complete project rebuild. Saving the compilation time
of a single object is not as critical today as it was then. This
causes a different optimization in build system design today. And
sharing compiled objects means that you must ensure identical systems
which is another problem.
> Don't know if my story hit the point. But what I guess is that ClearCase
> has been started from the idea of having dynamic views. Then everything
> else in ClearCase has been developped to circumvent this weird idea of
> dynamic views.
Very plausible.
Bob
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Chris Wein <cw...@mobilygen.com>.
ClearCase is definitely a deluxe VCS but with a big price tag. As a
very experienced CC user, there are only a few features that I really,
really miss that would make SVN essentially equivalent. Given that SVN
is never going to get dynamic views, clearmake is out but beyond that
its...
- Rock-solid merge tracking and merging
- ct lsvtree - A graphical representation of a file's branch and merge
history
- ct find - Similar to the standard Unix find except it has predicates
which evaluate useful bits of info clearcase meta data such as branches
etc.
Since SVN is under active development, I can actually see this
happening, maybe in late 06? :-)
Chris
On Tue, 2005-07-05 at 14:47 -0400, David Weintraub wrote:
> On 7/5/05, Didier Trosset <di...@acqiris.com> wrote:
> > Dynamic Views ...
> >
> > From my point of view, I guess things happened this way: One day, a
> > guy had an idea of having a version control system where the directories
> > would be updated automagically when anyone commits. He thought it was a
> > really great idea, so he decided to create a VCS with this feature.
>
> ClearCase developed as a way to get rid of the concept of a "working
> directory". There is no need for local storage (back in the days when
> a 20 meg hard drive was standard storage). There is no need for
> syncing your directory with the repository or wondering where you put
> your working directory. You worked in what looked like the storage
> archive. It is a powerful concept that is hard to understand unless
> you've developed in a dynamic view.
>
> > For this feature to work, he quickly realized that it was mandatory for
> > his VCS to have only one user changing a file at a time. So he restricts
> > the use to the lock-modify-unlok way of use. He thought this was a great
> > idea as it avoids merges, that's a good point.
>
> Apparently, you've never worked with ClearCase. ClearCase was probably
> the first version control system that did away with mandatory locking.
> Two users can checkout and modify the same file because they're
> working in two separate views. User A never sees User B's changes in
> that file even when User B checks in his version of the file.
>
> User A will never even realize that a new version of the file was
> checked in until he does a check in. At that time, ClearCase will warn
> User A that he must merge his changes into User B's version. Very much
> what Subversion does.
>
> > But then he discovered that dynamic views were creating a real mess. You
> > know, you're debugging a small chunk of code, changing one line, and
> > someone else commits other large stuff, and your debugging session is
> > halted by a 15 minutes compilation.
>
> Never seen this in my years of working with ClearCase. When you
> compile using ClearMake or ClearAudit, ClearCase freezes your
> ConfigSpec, so you don't see newer changes taking place while you
> compile. The only problem I could see is that the code in your view
> keeps changing when a new program gets checked in, and the changes in
> the new code breaks your code. In that case, you could add a "-time"
> parameter to your ConfigSpec to freeze your view of the latest code
> without creating a branch.
>
> > So he imagined the development branches. Each developper working in its
> > own branch, not bothered by others. And it's working great. But as each
> > developper has its own branch, there's no more need to lock-unlock
> > files, but he has to, because of dynamic views.
>
> What you're describing is what the local ClearCase administrators
> themselves developed in the field and started to become popular by the
> time Version 3.0 of ClearCase came out.
>
> It is called the continuous improvement method of development. Your
> "integration branch" (which was /main) not only contained good code,
> but the code on it was constantly imrpoving -- each version of each
> file was better, more feature ladened, and bug free, than the last.
>
> In theory, if your boss comes running out of his office and screams
> "We need to ship a new release this very second!", you could take
> whatever code was the latest on the "integration branch", spool it to
> a CD, and hand it to him knowing it was the greatest piece of software
> that the world has ever seen.. This type of technique was described
> back in the mid 90's in O'Reilly's "Applying RCS and SCCS".
>
> However, in RCS and SCCS, continual improvement development was quite
> hard to implement. Branching was difficult to track in any meaningful
> way. Plus, merging the changes from one branch to another was a big
> pain. You only used branches in RCS and SCCS when necessary.
>
> In ClearCase, branches were named and each to track. They were very
> cheap too in terms of space and ClearCase did an excellent job in
> manging them. Top this off with an excellent merge facility, and you
> made it simple to implement a continuous improvement development
> scheme.
>
> > Later, when developpers want to make their programs working together,
> > they have to publish the code to one single place. And here comes the
> > big merge. So merges haven't been avoided, they've just been delayed!
>
> Again, in ClearCase, there is no fear of merging since it goes so
> smoothly, and this is something that Subversion needs to learn from
> ClearCase.
>
> If you really don't like merging, you don't use branches and you make
> locking checkouts manditory. That way, it's just like SCCS, RCS, or
> CVS. If you don't want to lock files, then you make unlocking
> checkouts manditory. In this case, it's just like working with
> Subversion.
>
> There are problems with ClearCase: It is big, network intensive,
> extremely propriatary, and hard to learn. Dynamic views are slow, but
> static views eliminate most of the major advantages ClearCase enjoyed
> over other Version Control Systems.
>
> However, ClearCase was not a thrown together hack, but a well thought
> out development system that allowed a wide range of development
> techniques.
>
> --
> David Weintraub
> qazwart@gmail.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Frank Gruman <fg...@verizon.net>.
I think the whole scope of what everyone has typed out here so far is
that ClearCase offers some features and functions that Subversion does
not. Are these critical features to your development environment?
I would think that ClearCase would have some sort of demo that you could
work through in your 'normal' development environment to see what you
need. Subversion doesn't necessarily have a demo, but it costs nothing
but an hour or two to install and be up and running.
My company has a development office in FL that uses ClearCase. My team
uses Subversion. We both like what we have, and it suits both of our needs.
Bottom line - you get what you pay for with ClearCase. You get a
helluva lot more than what you pay for with Subversion.
my .02
Regards,
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Dirk Schenkewitz <sc...@docomolab-euro.com>.
David Weintraub wrote:
> ...
> Again, in ClearCase, there is no fear of merging since it goes so
> smoothly, and this is something that Subversion needs to learn from
> ClearCase.
You can either let CC make a trial to merge all by itself and report
those files where it found conflicts or you can do the merging all
by yourself. Then you get a nice graphical presentation of the files
and can move lines from here to there.
AFAIR, it is some years ago that I worked with CC.
Btw, I found 'meld' (http://meld.sourceforge.net/) to be very con-
venient for hand-merging. Just a side note, I have no experience
with merging with subversion up to now.
Dirk
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by David Weintraub <qa...@gmail.com>.
On 7/5/05, Didier Trosset <di...@acqiris.com> wrote:
> Dynamic Views ...
>
> From my point of view, I guess things happened this way: One day, a
> guy had an idea of having a version control system where the directories
> would be updated automagically when anyone commits. He thought it was a
> really great idea, so he decided to create a VCS with this feature.
ClearCase developed as a way to get rid of the concept of a "working
directory". There is no need for local storage (back in the days when
a 20 meg hard drive was standard storage). There is no need for
syncing your directory with the repository or wondering where you put
your working directory. You worked in what looked like the storage
archive. It is a powerful concept that is hard to understand unless
you've developed in a dynamic view.
> For this feature to work, he quickly realized that it was mandatory for
> his VCS to have only one user changing a file at a time. So he restricts
> the use to the lock-modify-unlok way of use. He thought this was a great
> idea as it avoids merges, that's a good point.
Apparently, you've never worked with ClearCase. ClearCase was probably
the first version control system that did away with mandatory locking.
Two users can checkout and modify the same file because they're
working in two separate views. User A never sees User B's changes in
that file even when User B checks in his version of the file.
User A will never even realize that a new version of the file was
checked in until he does a check in. At that time, ClearCase will warn
User A that he must merge his changes into User B's version. Very much
what Subversion does.
> But then he discovered that dynamic views were creating a real mess. You
> know, you're debugging a small chunk of code, changing one line, and
> someone else commits other large stuff, and your debugging session is
> halted by a 15 minutes compilation.
Never seen this in my years of working with ClearCase. When you
compile using ClearMake or ClearAudit, ClearCase freezes your
ConfigSpec, so you don't see newer changes taking place while you
compile. The only problem I could see is that the code in your view
keeps changing when a new program gets checked in, and the changes in
the new code breaks your code. In that case, you could add a "-time"
parameter to your ConfigSpec to freeze your view of the latest code
without creating a branch.
> So he imagined the development branches. Each developper working in its
> own branch, not bothered by others. And it's working great. But as each
> developper has its own branch, there's no more need to lock-unlock
> files, but he has to, because of dynamic views.
What you're describing is what the local ClearCase administrators
themselves developed in the field and started to become popular by the
time Version 3.0 of ClearCase came out.
It is called the continuous improvement method of development. Your
"integration branch" (which was /main) not only contained good code,
but the code on it was constantly imrpoving -- each version of each
file was better, more feature ladened, and bug free, than the last.
In theory, if your boss comes running out of his office and screams
"We need to ship a new release this very second!", you could take
whatever code was the latest on the "integration branch", spool it to
a CD, and hand it to him knowing it was the greatest piece of software
that the world has ever seen.. This type of technique was described
back in the mid 90's in O'Reilly's "Applying RCS and SCCS".
However, in RCS and SCCS, continual improvement development was quite
hard to implement. Branching was difficult to track in any meaningful
way. Plus, merging the changes from one branch to another was a big
pain. You only used branches in RCS and SCCS when necessary.
In ClearCase, branches were named and each to track. They were very
cheap too in terms of space and ClearCase did an excellent job in
manging them. Top this off with an excellent merge facility, and you
made it simple to implement a continuous improvement development
scheme.
> Later, when developpers want to make their programs working together,
> they have to publish the code to one single place. And here comes the
> big merge. So merges haven't been avoided, they've just been delayed!
Again, in ClearCase, there is no fear of merging since it goes so
smoothly, and this is something that Subversion needs to learn from
ClearCase.
If you really don't like merging, you don't use branches and you make
locking checkouts manditory. That way, it's just like SCCS, RCS, or
CVS. If you don't want to lock files, then you make unlocking
checkouts manditory. In this case, it's just like working with
Subversion.
There are problems with ClearCase: It is big, network intensive,
extremely propriatary, and hard to learn. Dynamic views are slow, but
static views eliminate most of the major advantages ClearCase enjoyed
over other Version Control Systems.
However, ClearCase was not a thrown together hack, but a well thought
out development system that allowed a wide range of development
techniques.
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Tor Ringstad <to...@tandberg.net>.
> But what I guess is that ClearCase has been started from the idea of
> having dynamic views. Then everything else in ClearCase has been
> developped to circumvent this weird idea of dynamic views.
It might well be that CC was started from the idea about dynamic
views, but I certainly don't see that as a source for endless
problems. Rather, I see it as a brilliant and powerful idea that
allows the tool to solve certain problems in very interesting ways.
> where the directories would be updated automagically when anyone
> commits.
Only if that is what you want. You have full control of when other
peoples updates should become visible in your own view.
> it was mandatory for his VCS to have only one user changing a file
> at a time. So he restricts the use to the lock-modify-unlok way of
> use.
There's both restricted and unrestricted checkouts, so there's no need
to lock anything if you don't want to.
As for the rest of your story, if it is based on real experience with
CC, I can just imagine that you must have been bitten badly by the
"bad process" syndrome.
- Tor Ringstad -
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Didier Trosset <di...@acqiris.com>.
Gabor Szabo wrote:
> On 7/5/05, Tor Ringstad <to...@tandberg.net> wrote:
>
>>In my experience, the following are some of the features in ClearCase
>>that really puts that tool in a different league than the rest of the
>>pack:
>>
>>- Dynamic views
Dynamic Views ...
From my point of view, I guess things happened this way: One day, a
guy had an idea of having a version control system where the directories
would be updated automagically when anyone commits. He thought it was a
really great idea, so he decided to create a VCS with this feature.
For this feature to work, he quickly realized that it was mandatory for
his VCS to have only one user changing a file at a time. So he restricts
the use to the lock-modify-unlok way of use. He thought this was a great
idea as it avoids merges, that's a good point.
But then he discovered that dynamic views were creating a real mess. You
know, you're debugging a small chunk of code, changing one line, and
someone else commits other large stuff, and your debugging session is
halted by a 15 minutes compilation.
So he imagined the development branches. Each developper working in its
own branch, not bothered by others. And it's working great. But as each
developper has its own branch, there's no more need to lock-unlock
files, but he has to, because of dynamic views.
Later, when developpers want to make their programs working together,
they have to publish the code to one single place. And here comes the
big merge. So merges haven't been avoided, they've just been delayed!
After that, he realizes that each developper having its own branch, that
makes a lot of branches! And he decided to have a tool to ease the use
of all those branches. There comes UCM...
Don't know if my story hit the point. But what I guess is that ClearCase
has been started from the idea of having dynamic views. Then everything
else in ClearCase has been developped to circumvent this weird idea of
dynamic views.
Didier
>>- Good branch/merge support (a lot better than e.g. Subversion)
>>- ClearMake
>
>
> Tod, as someone who does not know CC (remember, I only translated the doc),
> I'd appreciate if you could explain a bit more what each of those are
> (or in case of branch/merge) how are their better than that of SVN.
>
> Could any of those achived by using SVK or some other 3rd party tool ?
> Are there plans in SVN to include those features ?
>
> thanks
> Gabor
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
Didier Trosset-Moreau
Acqiris <www.acqiris.com>
Geneva, Switzerland
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Gabor Szabo <sz...@gmail.com>.
On 7/5/05, Tor Ringstad <to...@tandberg.net> wrote:
> In my experience, the following are some of the features in ClearCase
> that really puts that tool in a different league than the rest of the
> pack:
>
> - Dynamic views
> - Good branch/merge support (a lot better than e.g. Subversion)
> - ClearMake
Tod, as someone who does not know CC (remember, I only translated the doc),
I'd appreciate if you could explain a bit more what each of those are
(or in case of branch/merge) how are their better than that of SVN.
Could any of those achived by using SVK or some other 3rd party tool ?
Are there plans in SVN to include those features ?
thanks
Gabor
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by Tor Ringstad <to...@tandberg.net>.
Even though this one of the better side-by-side comparisons of
ClearCase and Subversion I'v seen, I don't think the big difference
between the tools comes across very clearly.
In my experience, the following are some of the features in ClearCase
that really puts that tool in a different league than the rest of the
pack:
- Dynamic views
- Good branch/merge support (a lot better than e.g. Subversion)
- ClearMake
If you don't appreciate *any* of these, you probably won't appreciate
the cost of ClearCase either.
- Tor Ringstad -
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion vs. Clear Case
Posted by David Weintraub <qa...@gmail.com>.
I have been a ClearCase administrator since version 1.2 was out back
when the company behind it was called Atria. That was before it merged
with Pure, got bought by Rational which was gobbled up by IBM.
ClearCase's biggest advantage were dynamic views. Dynamic views
completely changed the way you look at CM. With ClearCase, there was
no "working directory". You worked in the archive, you saw all the
files in the archive, you could compile, use the standard Unix tools,
do source code analysis, etc. The only thing you couldn't do was edit
a file until you did a checkout.
Dynamic views had all sorts of neat tricks. For example, you could
"cd" into a history tree of a given file by appending "@@" at the end
of the name. This allowed you to search all versions of a file for a
particular change.
When ClearCase switched to static (aka snapshot) views, the magic was
gone. Instead, you had all the headaches of having a separate working
directory with all the disadvantages of creating configspecs. Yes,
dynamic views still exist, but they are slower so most people use
static views.
Static views don't use the ConfigRecord build avoidance (this is where
if someone else built an object with the same configSpec and the same
base files, ClearCase would "winkin" the built object into your view
instead of actually doing the build). This might be a hidden blessing
because ClearCase's build avoidance has problems with Ant and some
implementations of C++.
Although Static views lose most of the advantages of dynamic views in
ClearCase, they still need to talk to the server when doing such
things as a checkout. You can get around this problem by "hijacking" a
file (by changing it from "read only" to "read/write") but fixing
hijacked files can be messy.
The biggest headache in ClearCase is the ConfigSpec. This is the
specification you use to explain exactly what you want to see in your
view. It is a pain the the lower anatomical region and you usually do
everything in your power to make sure users don't set their own views.
A single incorrect ConfigSpec can cause unbelievable damage to a
project.
ClearCase's big advantage is its triggers. A trigger is like a hook in
Subversion, except you could have triggers for almost any action in
ClearCase. Triggers could fire before an action took place or after it
took place. Unfortunately, triggers are slow. Even worse, they run on
the local machine. That means you have to design your trigger script
to run on all possible client configurations and install the right
version of any scripting language you depend upon. That pretty much
rules out using ClearCase on the user's home systems for remote work.
ClearCase's UCM was an attempt to establish a solid development method
on top of ClearCase. The idea is excellent, and the newer versions of
UCM are much better than the older version that was buggy, slow, and
prone to breakage. However, UCM is extremely complex and trying to
untangle a simple development mistake can take the better part of the
afternoon to fix.
ClearCase's Windows implementation uses Windows Explorer much like
TortoiseSVN does. There is also a separate ClearCase explorer that can
be used which can show more details. The ClearCase Unix implementation
is much more primative and most Unix users prefer the command line
interface anyway. If you use ClearCase UCM, you do not use the Windows
Explorer GUI. Instead, you use the special ClearCase UCM GUI.
Here's where I see ClearCase's big advantages over Subversion:
* Triggers are much more detailed and powerful than Subversion's
hooks. ClearCase has the ability to allow for triggers to query users
for additional information while they run.
* Merging: ClearCase's GUI merging facility (in both Unix and Windows)
is very simple to use. ClearCase doesn't allow "cherry picking" which
is not the greatest of practices anyway. ClearCase marks the merge
with a type of record called a "hyperlink". Because of this, ClearCase
knows what versions of a file were previously merged into the working
copy. I've rarely seen a ClearCase merge go bad.
* ClearCase is much better at tracking file and directory changes than
Subversion. ClearCase understands file renames and moves and a request
for history on a particular file can be easily traced both ways.
* ClearCase query facilities are much better. You can easily find when
a merge was done, who did a particular change, when a particular
attribute (what Subversion calls a property) was placed on a file,
etc. With Subversion, you have to depend upon the log file output and
do the parsing yourself.
* Branching: ClearCase branches are true branches and not simply
directories as in Subversion. Because of this, merging, diffing, and
viewing a file's history is very simple. Like Subversion, ClearCase
branches are "cheap" and invoked by name instead of using a numbering
scheme like RCS or SCCS. Most developers do all of their work on their
own branches, then merge their code onto the main branch once they've
completed their work. Infact, UCM institutes this practice of side
branch development.
Here are ClearCase's biggest disadvantages:
* Triggers: A trigger has to be able to run on the client in order for
it to work. That means you have to maintain and install a whole slew
of software on your various client machines. About 50% of the trigger
problems are the results of the trigger script failing because the
client machine is not running the correct version of the software.
* ConfigSpecs: A pain in the rear and probably the biggest reason why
UCM was created. One developer with a single bad line in their
ConfigSpec can cause a ton of grief.
* Resource Hog: When configuring a ClearCase system, you simply say
"What's the biggest, most costly system I can think of?", and then
double it. There is no way in the world to underestimate the size of
what you need with ClearCase. We ClearCase administrators use to joke:
* New high speed 1gigabit Ethernet network: $1,500,000
* New Server for VOB and view storage plus needed RAID array: $300,000
* NetApps server: $90,000
* Comvault backup device: $250,000
* The fact that ClearCase is so complex and impossible to understand
that the whole project would ground to a halt without you, so you have
job security for life: Priceless.
I see Subversion as being a bit green. The fact that branching and
labeling aren't built in concepts, but implemented as directories is
probably the biggest problem with Subversion right now. Because of
this, simple things like taking the diff of a file or doing a merge
can be quite complex.
Merging is also another issue in Subversion. Subversion doesn't track
what versions were already included in a merge and finding this
information can be difficult. Especially if users don't setup their
log messages the right way. Subversion also doesn't do directory
merging which is a problem for a package that tracks changes in the
directory structure.
Subversion still doesn't quite track directory or file name changes
since it considers moves and renames a "delete and add" (although
because of this, doesn't suffer from ClearCase's Evil Twins problem).
Other Subversion problems include being unable to remove unneeded
versions of files from the archive. If someone accidentally adds a
file in the archive with information that shouldn't be shared, there
is no way to easily remove it from the archive. If a site versions
binary data, they cannot remove older versions that are no longer
needed. Thus causing the size of the archive to waste space.
Still, Subversion has a lot going for it:
* It is available on a lot more platforms than ClearCase
* It is easy to use and install -- especially on client machines.
* Network security: Subversion can use https or svn+ssh which make it
safe to use remotely. ClearCase has to be used via VPN to be truly
secure and some setups of VPN filter ClearCase packets out.
* Subversion is much faster and leaner.
* Subversion makes a clear distinction between the client and server.
An administrator only has to worry about the Subversion server
installation and not how the clients are setup.
* The price is right.
I might not want to install Subversion on a site with several dozen
developers churning away at a single project, but those types of
projects are few and far between. Most projects now consist of fewer
than a dozen developers doing rapid development. For such a small
project, ClearCase is a big headache since it requires large overhead.
Yes, I realize that the Subversion project itself and other open
source projects such as Apache are in fact large projects with dozens
if not hundreds of developers successfully using Subversion as their
version control system. However, the open source community is a bit
different from a corporate environment. Besides, ClearCase is hell to
setup for a massive remote development effort. That's why there's
ClearCase MultiSite.
ClearCase is still the preferred package for very large development
shops because it allows for such centralized control and IT shops love
it because it gives them power to overlord all development efforts.
But, after administering ClearCase for 15 years, I am not convinced
that it is the right package for most development efforts anymore.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org