May/June 2018 issue of acmqueue The May/June issue of acmqueue is out now



Development

  Download PDF version of this article PDF

ITEM not available

acmqueue

Originally published in Queue vol. 7, no. 7
see this item in the ACM Digital Library


Tweet



Related:

Jez Humble - Continuous Delivery Sounds Great, but Will It Work Here?
It's not magic, it just requires continuous, daily improvement at all levels.


Nicole Forsgren, Mik Kersten - DevOps Metrics
Your biggest mistake might be collecting the wrong data.


Alvaro Videla - Metaphors We Compute By
Code is a story that explains how to solve a particular problem.


Ivar Jacobson, Ian Spence, Pan-Wei Ng - Is There a Single Method for the Internet of Things?
Essence can keep software development for the IoT from becoming unwieldy.



Comments

(newest first)

Dan Savilonis | Fri, 28 Aug 2009 16:28:23 UTC

"Mercurial and Subversion work well over HTTP and with SSL (Secure Sockets Layer), but Git is unusably slow over HTTP. "

This statement is questionable. Subversion is often unusably slow over the WAN. Git is slower over http than its native protocol, but this ignores the fact that your entire repository is locally available. I find git to be quite usable over http. The initial clone is the only intolerably slow operation.


Henryk Gerlach | Wed, 26 Aug 2009 11:44:10 UTC

@greggman

Locking is a communication problem, not a VCS one. You can always copy some locked file modify it and complain, that you created a fork, that can not easily be merged.

Any system without constant online connection can not provide proper locking. On the other hand, you could write extensions to DVCS that use some central locking server to implement locking and it would work fine, as long, as all clients can talk to the locking server.

See http://markmail.org/message/v7q6ujlrgj2vw56l for some discussion


gordon wrigley | Wed, 26 Aug 2009 11:20:58 UTC

It is also worth noting the existence of products like Alien Brain which fill the niche of revision control for art assets.


paul kramer | Wed, 26 Aug 2009 06:21:01 UTC

my opinion is that depending on the software life cycle branch/merge model, coupled with the release model, layering of the product architecture, outsourcing, offshoring, and partnerships... a best fit source code control system would be selected. having worked in distributed operating system development teams and distributed product development teams, I find the scm tools that best fit those types of distributed teams are git and bitkeeper like tools. distributed scms are best suited for granular source trees, that is not a weakness of the scm tool. if the source tree is not granular, then everything is monolithic, slow and complex... including: build systems, integration cycles, development cycles, test cycles. having said that, in 29 years in software development, I've never seen centralized approaches ever produce responsive results. scm tools that are centralized (cvs, subversion, perforce, clearcase) require overhead and specialized knowledge to administrate. in todays markets developers need to be empowered to operate independently, tools like git, bitkeeper, mercurial, and others along these lines will perform much better in terms of productivity. for teams that require large repositories of images, movies etc... i.e game development that is mentioned in other postings, i've not had experience in those environments, and can see that is quite a challenge, and it would be interesting to observer the workflows to see where performance could be improved


gordon wrigley | Wed, 26 Aug 2009 05:35:43 UTC

Subversion has particularly poor support for branching and merging, if you look at a centralized version system with better support for this, (for example Clearcase with UCM), what you'll find is that the private branch based work flow you describe under "What Behaviors Does a Distributed Tool Change" not only becomes more common but becomes the standard work flow.

The key seems to be not so much "the privacy of a branch on a developer's laptop, coupled with the instantaneous responsiveness of the distributed tools" (although I'm sure they contribute) but rather the tool support to allow merges with no conflicts (or only trivial ones that can be handled automatically), to be performed as a single click operation. When merging is easy people start to work in a pattern that includes many small merges.

It is interesting that a lot of the criticism of centralized version control is based on the misguided view that branching and merging can never be done easily in a centralized system. This view is held by many people whose only experience of centralized version systems has been with CVS and Subversion and is echoed even in the comments of such notable figures as Linus. Where as in reality support for distributed work flow and support for private branch based work flow are mostly independent and rather than them being related it is just that Subversion and CVS fail to support either.


greggman | Wed, 26 Aug 2009 02:05:12 UTC

I'm glad this article brought up the fact that game development needs are different than most other software projects. It didn't point out how neither Subversion, Git nor Mercurial are good for this task. The article pointed out that neither git or mercurial are useful for this task because of the lack of locking which is needed for binary files, especially on large teams with 70+ artsist all trying to edit assets. But even subversion has issues. Last time I checked, Perforce was > 4x faster at syncing from scratch than Subversion and of course much faster when syncing incrementally.

This is important because one thing the article got wrong, today's top games don't have gigs of assets, they have TERABYTES of assets. The last game I worked on (360/PS3) had appox 5 terabytes of source assets and that does NOT include video. The game before that (PSP) had only 20gig but during the last 3 months of the project, syncing in subversion took 45-60minutes and had to be done several times a day to get all the various designers latest levels. If we had used subversion for the 360/PS3 game assets we would not have shipped.


Matt Doar | Fri, 21 Aug 2009 23:24:25 UTC

Good summary. I'll also say that the section about patch in "Mercurial: The Definitive Guide" is one of the clearest explanations I've read anywhere. In fact, I'd recommend that book as a good basis for anyone thinking about revision control systems in general.

~Matt


Leave this field empty

Post a Comment:







© 2018 ACM, Inc. All Rights Reserved.