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 <didier.trosset@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
Received on Tue Jul 5 21:28:29 2005