The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Source Control Tension

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Greg Vaughn

Posts: 55
Nickname: gvaughn
Registered: May, 2003

Greg Vaughn is a naturally introspective and extemporaneous developer primarily using Java.
Source Control Tension Posted: Mar 30, 2004 11:28 PM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by Greg Vaughn.
Original Post: Source Control Tension
Feed Title: Potential Differences
Feed URL: http://gigavolt.net/blog/development/index.rss
Feed Description: Greg Vaughn on Agile methodologies, Java, OS X, whatever piques my interest!
Latest Agile Buzz Posts
Latest Agile Buzz Posts by Greg Vaughn
Latest Posts From Potential Differences

Advertisement

After reading Glenn’s blog on Six of One, a Half Dozen of the Other I started thinking about source control systems as another example of these opposing tensions. As Glenn notes, this is tied into Martin Fowler’s directing vs. enabling attitudes.

On the one hand you’ve got the more traditional style of source control such as PVCS that uses an exclusive check-out model. Only one person is allowed to modify a file at once. It’s a safe pessimistic locking model (directing). On the other hand there’s systems such as CVS that allow multiple users to edit the same file at the same time. It’s an optimistic locking model (enabling). Yes, there can be merge problems. That alone keeps some people from using them.

I’ve used both forms of source control. Merge errors can and do happen with optimistic locking, but they’re not usually a problem. You’re notified right away and the fix is usually obvious. On the other hand, when I’ve used pessimistic locking systems, I’m often having to go talk to other developers to ask when they can check a file in because I also need to make an edit to it. In the meantime my flow is broken and I have a choice to work on something else until they can check in, or work around the source control system to make edits on a local version. Then I’ll have to remember what I changed and re-create it later when I can check the file out.

This draws a nice parallel to the perennial favorite blogging topic of static vs. dynamic typing. Static typing is like an exclusive locking source control system. It is safer, but it can get in your way — how frequently is open to debate, but I say it often does. Dynamic typing plus unit tests is like an optimistic locking source control system. It doesn’t get in your way and you can go faster, but it will sometimes have problems that your unit tests should catch right away and allow you to fix.

This brings into question Glenn’s whole premise that neither side is really right — it’s just about tradeoffs. I feel much more comfortable saying that optimistic locking in a source control system is categorically better than pessimistic locking than I am saying that dynamic typing is categorically better than static typing, but why? Is it a limit in the metaphor or in the industry’s experience with dynamic typing? Also, is there a corelation between fans of static typing and fans of pessimistic locking?

Read: Source Control Tension

Topic: CeBIT Previous Topic   Next Topic Topic: Dead in the water

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use