I haven't had experience on a DVCS in a commercial setting. However, I had
been a ClearCase administrator, and the standard way to use ClearCase works
in many ways like a DVCS in the way the workflows operates.
In ClearCase, you can give each developer their own branch. When a developer
wants to do work, they checkout the code from the "trunk" (called /main in
ClearCase), and onto their branch.
Like a DVCS, developers work in isolation. That is, developers make all the
changes they want, and it doesn't affect the other developers. Once a
developer finishes a set of changes, they merge their code back onto the
"trunk". You could even assign a particular person who owns the trunk, and
that person would have to power to accept or reject your changes.
In a certain sense, this is the same workflow when a developer has their own
version of a respoitory in a DVCS.
In my experience working with ClearCase, we had constant issues with getting
developers to deliver their changes and with merging once those changes were
delivered. Working in issolation, the developers would make changes that
affected what other devleopers were doing. Since my first jobs as a CM
involved ClearCase, I naturally assumed this is the way development
operates. Everyday, there was some sort of crisis with merging or broken
builds. Everyday, I would see what was checked into the /main branch and
then hounded developers about deliverying code.
One day, I got a job where they used CVS instead of ClearCase. They were
thinking of moving to ClearCase, so they wanted someone with ClearCase
expertise.
I looked at CVS, and realized it had severe problems: Branching was much
trickier. In CVS, you had to branch all the files together where in
ClearCase you branched files ona needed case-by-case basis. That took time.
This forced everyone to work off of trunk. A dozen developers working all on
the same codebase? That seemed like an absolute disaster. These people
needed to be moved to ClearCase as quickly as possible!
In my first week, I noticed something very strange: There were no problems
with builds or with developers breaking the build. I knew the developers
were changing the code, but why was everything running so smoothly?
It took me a couple of weeks to realize what as happening. Since the
developers all work on the same branch, they had to constantly think about
how their work affected the other developers. They talked to each other
about the changes they were making. They made their changes in small
increments. They worked together and made sure everyone knew what was going
on.
This was a great relevation to me. By isolating the developers' work on
separate branches, we isolated the developers from each other. They could
work without worrying what their changes might do to their fellow
developers. They no longer needed to talk to each other.
In fact, the developers hated delivery code changes because that's when
everyone gets mad. In order to avoid code deliveries, the developers broke
off big chucks of changes. That way, when someone asked about their changes,
they were still busy with them. Of course, the delay in deliverying their
changes only made the inevidable merge worse.
DVCS worry me because I can see the same effect going on: Developers working
on their own without worrying how their changes might affect other
developers.
In a commercial environmment where you have third party imposed deadlines,
you want to force your developers to work together. You want them to deliver
small incremental improvements as quickly as possible. Yes, you could
enforce this with a DVCS by simply having everyone work on the same
repository. But then, it's not really a DVCS.
As long as you don't do updates or commits, you can easily work with
Subversion off line. In fact, Subversion traded diskspace for the ability to
work mainly off line from your repository.
A better mechanism for remote sites with slow access would be proxy
repositories that constantly synchronize with each other. Subversion doesn't
have a built in mechanism to do this. Yes, it is very possible to do with a
little hacking, but Subversion wasn't meant for this type of setup.
However, it is something that could be easily added onto Subversion without
making major changes in its architecture.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360938
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-10 16:38:30 CEST