On Wed, Jun 10, 2009 at 8:37 AM, David Weintraub <qazwart_at_gmail.com> wrote:
> 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.
>
great read david, thanks for sharing.
> As long as you don't do updates or commits, you can easily work with
> Subversion off line.
>
the only thing about this is, offline work w/ svn means work w/o committing;
which encourages the most horrid of practices. basically contrived
techniques that vary from dev to dev but mostly amount to managing copies of
directories w/ diff names on them... which basically gets you to the point
of - why are you bothering to use a vcs in the first place..
good to hear more practical examples. admittedly, ive not had the
opportunity to use dvcs much so far, as adoption is only now starting to
ramp up. im sure there will be pain points in the distributed flows that i
just have yet to discover.. and start complaining about - lol.
-nathan
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2360992
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-10 18:39:15 CEST