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
Received on Tue Jul 5 20:49:38 2005