1、运行 nant

一旦安装了 Nant，运行是很简单的，仅仅是输入 nant。输入 nant –help 能够得到用法信息。

1) 指定 build 文件

没有指定文件时，NAnt 会在当前文件夹中寻找.build 文件，例如 NAnt.build。如果找到了，NAnt 就把它作为 build 文件使用。如果找到了一个以上的文件，你需要使用-buildfile 选项（用法见下面）指定一个文件。

如果你使用-find 选项，NAnt 会到父目录中寻找 build 文件，如此继续，直至到达根目录。使用命令行选项-buildfile:file 可以使 NAnt 使用其它的 build 文件。

2) 指定对象

你可以指定一个或多个将要被执行的对象。当忽略时，标签的 default 属性指定的对象将被使用。

如果工程有描述存在，Projecthelp 将把它打印出来，紧跟在描述后面的是工程的对象列表。

3) 设置属性

使用-D:property=value 撤销 build 文件中指定的属性，其中 property 是属性的名称，value 是属性的值。

4) 例子

Nant：在当前目录中使用 *.build 结尾的 xml 文件运行 nant，使用缺省对象。

NAnt -buildfile:..\ProjectName.build：使用父目录下的 ProjectName.build 文件，，使用缺省对象。

Nant clean：在当前目录使用 build 文件运行 nant，使用名称为 clean 对象。

NAnt -D:debug=false clean dist：使用当前目录中缺省的 build 文件运行 nant， 当设置 debug 为 false 的时候，先使用 clean 对象，然后使用 dist 对象。

NAnt 是一个基于 .NET 的生成工具，与当前版本的 Visual Studio .NET 不同，它使得为您的项目创建生成过程变得非常容易。当您拥有大量从事单个项目的开发人员时，您不能依赖于从单个用户的座位进行生成。您也不希望必须定期手动生成该项目。您更愿意创建每天晚上运行的自动生成过程。NAnt 使您可以生成解决方案、复制文件、运行 NUnit 测试、发送电子邮件，等等。遗憾的是，NAnt 缺少漂亮的图形界面，但它的确具有可以指定应该在生成过程中完成哪些任务的控制台应用程序和 XML 文件。注意，MSBuild（属于 Visual Studio 2005 的新的生成平台）为每种健壮的生成方案进行了准备，并且由基于 XML 的项目文件以类似的方式驱动。

1、系统需求

使用 Nant，需要具备以下一种 CRL：

· Microsoft .NET Framework 1.0

· Microsoft .NET Framework 1.1

· Microsoft .NET Framework 2.0 Beta 1

· Mono 1.0.x

依赖的库文件

Nant 使用了许多开源的第三方组件库，nant 的最近版本中包含了这些组件，在安装 nant 时不需要做额外的工作。有关这些组件的更多信息请参考以下链接：

NUnit - Required for unit testing

NDoc - Required for documentation generation

SharpZipLib - Required for the zip and unzip tasks

2、安装

无论是源代码还是编译好的二进制文件，Nant 都是可以使用的。编译好的二进制文件是建立工程所需要的，包括构建 tasks, types 和 functions。

从二进制文件安装：

1) 下载 nant-bin.zip 或 nant-bin.tar.gz

2) 从机器上删除以前的旧版本

3) 解压缩下载的压缩文件到你期望安装 NAnt 的地方

4) 根据你的机器环境，构建一个脚本文件来运行 Nant：

Ø 在.NET 下运行 Nant：

新建一个批处理文件，如 nant.bat，在里面加入如下内容，注意把红色部分换成自己机器上的 Nant 的安装路径，然后运行这个批处理文件即可：

@echo off

"C:\Program Files\NAnt\bin\NAnt.exe" %*

Ø 在 Mono 下运行 Nant：

Windows 环境：同.NET

Linux / Cygwin：在你的文件系统的适当位置创建一个名称为 nant 的文件（例如/usr/local/bin），在文件中加入以下内容：

#!/bin/sh

exec mono /usr/local/nant/bin/NAnt.exe "$@"

确保 nant 有运行的权限，如：chmod a+x /usr/local/bin/nant

5) 打开命令行窗口，把目录切换到装有 nant 的文件夹，执行 nant –help，如果安装正确，你就会看到以命令行选项显示的使用信息。

6) （选做）下载、安装 NAnt-contrib 或其他第三方扩展程序。

从源代码进行安装：

1) 下载 nant-src.zip 或 nant-src.tar.gz

2) 从机器上删除以前的旧版本

3) 解压缩下载的压缩文件到你期望安装 NAnt 的地方

4) 打开命令行提示符窗口，把目录切换到你把文件解压缩到的地方

5) 根据你的机器环境，编译 Nant：

Ø 在.NET 下：

n GNU Make

make install MONO= MCS=csc prefix=installation-path

例如： make install MONO= MCS=csc prefix="C:\Program Files"

n NMake

nmake -f Makefile.nmake install prefix=installation-path

例如： nmake -f Makefile.nmake install prefix="C:\Program Files"

Ø 在 Mono 下：

§ GNU Make

make install prefix=installation-path

eg. make install prefix="C:\Program Files"

§ NMake

nmake -f Makefile.nmake install MONO=mono CSC=mcs prefix=installation-path

eg. nmake -f Makefile.nmake install MONO=mono CSC=mcs prefix=/usr/local/

这会生成一个 bootstrap 版本的 nant，然后使用它生成、安装 full 版本的 nant：installation-path/NAnt

6) 打开命令行窗口，把目录切换到装有 nant 的文件夹，执行 nant –help，如果安装正确，你就会看到以命令行选项显示的使用信息。

7) （选做）下载、安装 NAnt-contrib 或其他第三方扩展程序。

3、运行例子程序

打开命令行窗口，把目录切换到装有 nant 的文件夹，输入以下命令行并执行，注意红色部分换成自己的例子程序的路径：

Nant –buildfile:..\examples\examples.build

成功会显示编译信息。

学习型的 mm~

额...瓜的,

多谢美女支持呀.

19pages 简单明了,适合初学者.

[url]http://www.8848software.com/scmchina/cvs-starteam/cvs_vs_starteam/starteam-faq.html/url][

版本控制领域的 2-8 原则

10 comments - Post a comment

Ben Collins-Sussman 在他的 Blog 里写了 Version Control and “the 80%”，这是一个有趣的故事，他认为 Subversion 只是改变了 80%” 非专业的” 程序员，而 20%” 专业的” 程序员早已经投入到哪些分布式的版本控制。

其实 Subversion 之所以要流行，是因为它简单，任何” 非专业的” 程序员，甚至是只会用 VS 的 IDE 编程的程序员，都可以很快地学会使用 Subversion，而那些” 专业的” 版本控制工具通常是没有界面的 ，复杂的，但也是功能强大的工具，不管怎么样，我还没怎么用过 GIT 之类的工具，不过也许应该开始准备一下了。 [url]http://rocksun.cn/?p=85/url][

[...] 26, 2007 · No Comments Via Jeff Atwood, I found Ben Collins-Sussman discussion of two types of programmers. What uttercrap. They took a gray issue and are trying to make it black and white. There are not two types or fourteen types. There are an infinite amount of programmers. [...] Aninimous says on November 26th, 2007 at 5:38 pm:

By that measure, we wouldn’t have either Linux or *BSD today, to name just two. evanx says on November 27th, 2007 at 4:51 am:

i wouldn’t say that many of the 20% people (working in banks etcetera) have never used version control - they all do, in my experience, they use an IDE with SCM plugin. Also i wouldn’t say they all use Microsoft only - there is a large percentage using Java/Eclipse, especially in banks, government, etcetera, mostly for web app server development. iBanjo » Blog Archive » Version Control and the… Long Gradated Scale says on November 27th, 2007 at 3:39 pm:

[...] My previous post about version control and the 80% deserves a follow-up post, mainly because it caused such an uproar, and because I don’t want people to think I’m an ignorant narcissist. Some people agreed with my post, but a huge number of people took offense at my gross generalizations. I’ve seen endless comments on my post (as well as the supporting post by Jeff Atwood) where people are either trying to decide if they’re in the “80%” or in the “20%”, or are calling foul on the pompous assertion that everyone fits into those two categories. [...] sven says on November 27th, 2007 at 3:43 pm:

They use whatever tools Microsoft hands down to them — usally VS.NET if they’re doing C++, or maybe a GUI IDE like Eclipse or IntelliJ for Java development.

You must be one of those crazy bitches that uses strictly vi for your editor. Things like Intellisense/Content Assist are more helpful than you think. Ben Collins-Sussman says on November 27th, 2007 at 3:47 pm:

sven: I use emacs, actually. And yes, emacs has something quite similar to Intellisense too. I never type whole symbol-names out. Are you in the 80% or the 20% of programmers? « Jim 2.0’s Blog says on November 27th, 2007 at 11:53 pm:

[...] Jeff’s article is based on Ben Collins-Sussman’s article written about a week earlier. Ben writes: The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. The 80% folks make up the bulk of the software development industry. They’re not stupid; they’re merely vocational. [...] The Two Types of Programmers « Pramit’s Weblog says on November 28th, 2007 at 1:36 am:

[...] November 28, 2007 at 6:35 am (Uncategorized) The Two Types of Programmers Contrary to myth, there aren’t fourteen types of programmers. There are really only two, as Ben Collins-Sussman reminds us. There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. The 20% folks are what many would call “alpha” programmers — the leaders, trailblazers, trendsetters, the kind of folks that places like Google and Fog Creek software are obsessed with hiring. These folks were the first ones to install Linux at home in the 90’s; the people who write lisp compilers and learn Haskell on weekends “just for fun”; they actively participate in open source projects; they’re always aware of the latest, coolest new trends in programming and tools. [...] Are you a 80% or 20%? :: Fat Penguin says on November 28th, 2007 at 1:58 am:

[...] If you are currently working as a programmer, what kind of a programmer are you? an “80%” or “20%”? If you’re not familiar with these types, you may want to read this or that. [...] Curious Chap » Blog Archive » The Two Types of Software Development says on November 28th, 2007 at 6:06 am:

[...] What spurred me to ink my thoughts is Ben Collins-Sussman’s recent Version Control and “the 80%” post where he separates developers into two groups: the 20% alpha geeks and the 80% folks. Ben, one of Subversion’s developers, dares to write: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. [...] Hisham Abboud says on November 28th, 2007 at 6:15 am:

Great post, and it inspired my own post. I agree totally with your 80/20 description. Personally, I would have divided the post into two separate ones: one describing the 80/20 observation, and the other regarding DVCS. Picando Código says on November 28th, 2007 at 7:36 am:

Los dos tipos de programador

En blogs, portales de noticias, empresas, centros de educación en programación, etc. generalmente se tiende a describir distintos “tipos” de programadores. Hace en poco en un blog en TechRepublic, nombraban 10 tipos distintos de programad… Big geek says on November 28th, 2007 at 3:41 pm:

[...] So, over to what popped to mind this time. I was reading an interesting post about programmers: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. [...] Anna-Jayne Metcalfe says on November 29th, 2007 at 5:38 am:

“version control and a working Linux abilities are vital tools for a programmer”.

That’s an interesting statement Zack. While I totally agree with the former, the latter is just one way of saying “the ability to motivate yourself to learn (and, crucially, keep learning) how to manipulate a system at a low level” or similar. Learning how to use GNU/Linux effectively is just one way of doing that - you could equally well substitute self-motivated learning of any skill which isn’t well supported by the mainstream.

In my experience all too many of the “80%” just don’t do that - I’ve lost count of the number of times I’ve had to “educate” a supposedly senior developer about const correctness or how to use STL containers efficiently. For a disturbingly large subset of developers, “Merge” is a terrifying word.

FWIW I’ve cut myself a career as a Windows developer and I’ve never got around to learning GNU/Linux - but that doesn’t mean I don’t keep up to date with what’s going on in the wider community. I’m all too well aware of what’s going on with C++0x, dynamic languages etc…it’s just that I simply don’t have the time to do everything I’d like to (my free time usually gets eaten up by company admin), so something usually has to give.

As the saying goes, “We live in interesting times”. No soup for me » Blog Archive » Where did the geeks go? says on November 29th, 2007 at 10:50 am:

[...] So, over to what popped to mind this time. I was reading an interesting post about programmers: There are two “classes” of programmers in the world of software development: I’m going to call them the 20% and the 80%. [...] Yet Another Blog » Blog Archive » Dois tipos de programadores… says on November 29th, 2007 at 5:29 pm:

[...] Quem quiser ler mais: [url]http://blog.red-bean.com/sussman/?p=79/url][ [...] oh how i hate the 80:20 | blog@tim-dawborn: ~$ says on November 29th, 2007 at 11:56 pm:

[...] Posted November 30th @ 3:56 pm by tim (for people who dont know the 80:20 programmers version, [url]http://blog.red-bean.com/sussman/?p=79/url][) [...] links for 2007-12-02 - Leere Signifikanten says on December 1st, 2007 at 8:24 pm:

[...] iBanjo » Blog Archive » Version Control and “the 80%” (tags: article blog development opensource programming svn dvcs subversion) [...] Suburban Chicago PHP » Blog Archive » Dave’s (Poignant) Guide to PHP says on December 2nd, 2007 at 3:17 am:

[...] Ruby and Haskell are the big “indie” programming languages these days. The 20% kind of programmers see them pushing the boundaries and breaking us out of the C++/Java influenced paradigms which have dominated for more than a decade. They’re the programming languages of rebels…digital Che Guevara t-shirts, if you will. [...] Low Country Software Ramblings » I don’t feel like one of the top 20%… says on December 2nd, 2007 at 2:54 pm:

[...] Posted by benoit on 02 Dec 2007 at 12:54 pm | Tagged as: career, ramblings Jeff Atwood at Coding Horror recently talked about two types of programmers (triggered by Ben Collins-Sussman’s source control comments). The top 20% which are interested in professional development, and the remaining 80% which are more like 9-5 clock workers, and are not doing the magazines/blogs/conferences thing. As Jeff clarified, here’s not dissing the 80%, just pointing out that they are unreachable by conventional means. [...] Rob Conery » Hey Cool Kids - Alt.Crank is Boring says on December 2nd, 2007 at 10:20 pm:

[...] I’m not trying to take a swipe here; I just really dislike divisive posts, in any fashion. I didn’t get past the first sentence. I literally clicked away, knowing that what was coming was yet another summation of our industry, and the millions of people in it, wrapped up nicely into little buckets for easy digestion: Contrary to myth, there aren’t fourteen types of program

[url]http://blog.red-bean.com/sussman/?p=79/url][

It’s a little weird to me, and I think it mostly comes from being overly enthusiastic, that the top 20% can so easily loose touch with reality and fail to view things from other peoples perspectives. Our first thoughts should be about “how will others feel about this tool”… not… “I think it rocks so I am going to try and force it on everyone else by driving them nuts pushing it every chance I get”. If a person likes a tool use it for your personal projects, you can’t expect everyone else to want to use it the way you want to. Especially in the business world. Companies tend to have very strict requirements, they don’t care about the latest trend (things come and go all the time), they care about keeping their business running, keeping customers happy and keeping the money rolling in. And nevermind government agencies… I will not even go there, if you have worked with them then you know what I am getting at. Technologies are just tools, it’s not cool to them. They most often take the… if it ain’t broken, don’t fix it approach.

I am really glad to hear about the improvements you guys are working on for the upcoming releases of SVN. Can’t wait to use the new and improved features. Thanks! and… keep up the great work! Matt Galvin says on October 19th, 2007 at 11:20 pm:

And even if it is broken they still don’t want to fix/improve it unless it is costing them money or lost revenue. Dan says on October 20th, 2007 at 2:26 pm:

Thanks for the interesting story. behdad says on October 20th, 2007 at 4:33 pm:

I think the main point your article misses (or is not clear about) is that corporate environments (small Windows shops, banks, …) and Open Source community need NOT use the same tools. Kurt Christensen says on October 21st, 2007 at 2:21 am:

Ben, thanks fo rthis post. You wrote:

“In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work”

I work in your 80%, and you simply cannot underestimate the importance of this. In a very large corporate IT shop, the inability of developers to cooperate with each other in sane ways literally shuts down development by leaving the build perpetually broken.

One other comment: your numbers are off - the 80% is much more like 99% outside of Silicon Valley, and many of us - shockingly - aren’t complete idiots and don’t like being addressed as such. Shabs says on October 21st, 2007 at 8:25 pm:

Ben:

For Subversion 2.0, a few of us are imagining a centralized system, but with certain decentralized features. We’d like to allow working copies to store “offline commits” and manage “local branches”, which can then be pushed to the central repository when you’re online again.

I’m beginning to think Subversion development is being poisoned by an influx of Perforce brain damage.

First, changesets, which are basically useless as implemented. You need patch-hunk-level granularity to make this a useful feature for general use — the person who justified the lack of this by saying “this is what 90% of users need — ignore the other 10%” has the percentages backwards, or at least very skewed from reality.

Then the svn update interactive merge feature, which breaks lots of existing shell scripts and is difficult to drive from a script (and –non-interactive is insufficiently granular, because it shuts off password access as well)).

And now a distinction between “offline” and “online” usage. Holy thionite, man. Next, you’ll be introducing Perforce’s idiotic mainframe-era “forms”. Ben Collins-Sussman says on October 21st, 2007 at 10:13 pm:

Shabs, perhaps you’d like to come to the [email] dev@subversion.tigris.org[/email] list and discuss your opinions about new svn 1.5 features? Drive-by criticisms of discussions that took months are sort of… unfair. Rams says on October 22nd, 2007 at 12:08 am:

Hi Ben, We had this disussion sometime back at the local linux users group [url]http://www.ae.iitm.ac.in/pipermail/ilugc/2007-May/034190.html/url][ [url]http://www.ae.iitm.ac.in/pipermail/ilugc/2007-May/034293.html./url][ Ian Clatworthy says on October 22nd, 2007 at 7:41 pm:

Ben,

It’s great to see you raising these issues and doing so in such a well written way. While thesedays I’m actively encouraging people to look at DVCS technology and Bazaar in particular, I’ve spent most of the last 12 years managing teams in a corporate environment using CVS. I’m highly familiar with many of the points you’ve raised. For example, the maximum number of branches our developers could manage on their laptops was 3 or 4 because of the huge size of the code base. The code was mission critical 24×7 - quality and processes to achieve it were major focuses of our team.

I must say though, that while each of your “shocking statements” are true, many of your other points about DVCS technology simply aren’t correct. They may apply to select tools and DVCS fan-boys (Git and Linus perhaps) but they don’t apply to Bazaar and (to a lesser extent) Hg. Bazaar in particular directly supports the central workflow model. In fact, it supports many workflows really well and really cleanly as illustrated in [url]http://bazaar-vcs.org/Workflows./url][ I’ve argued for some time now that the future of version control is neither central nor distributed, it’s adaptive. See [url]http://ianclatworthy.wordpress.com/2007/06/21/version-control-the-future-is-adaptive/./url][

Suggesting that central VCS is inherently better because it forces developers to check in to a central location more frequently is a myth. It’s a bit like saying “You’re allowed to talk to anyone in the company on the phone but only through a centrally registered conference call.” Used correctly, DVCS increases collaboration and leads to a much higher quality trunk than I’ve ever experienced or seen by teams using central VCS tools.

It’s good to hear of some of the improvements planned for Subversion. They will greatly help many people do their job more effectively. Together with companion tools like TeamCity, they will be sufficient for many teams for some time. However, there are compelling advantages to DVCS that mean no amount of adding features to a central-only VCS tool can match it. See my recent paper on Why DVCS Matters ([url]http://ianclatworthy.files.wordpress.com/2007/10/dvcs-why-and-how3.pdf/url][) for a a summary of these. About version control and “the 80%”… « Francesco Crippa says on October 23rd, 2007 at 4:16 am:

[...] Today Luca sent an interesting post on mugshot. [...] Ted says on October 26th, 2007 at 5:44 pm:

I think you have to have a middle ground between the 20%ers and the 80%ers. I’ve done things like taking the time to learn a language over the weekend for fun, and I’ve certainly gotten in arguments over algorithms with friends and of course have tried linux, but I also program in C# and Java (although, I barely do any work in my Java class and the only C# work I do is XNA stuff), and I like Windows. I’ve never participated in an open source project before although I guess I’m only 17. Whatever, maybe one day I’ll be a 20%er, but for right now I feel more like an mix between the two. ganeshram iyer says on October 29th, 2007 at 10:38 am:

Thanks for putting the stuff I already knew and was pondering upon into a blog. It is definitely better received and accepted when someone as well known as you states it. I have been considering similar nature of collaboration in the CAD world and your article provides some valuable insight on which route to pursue to reach a larger audience. Stefan says on November 2nd, 2007 at 10:42 am:

I think there are three types of programmers, not just two. You forgot those who are interested in new stuff and try everything out, but still go home friday afternoon and forget about computers until monday. Those who use Windows every day but still try Linux from time to time (and then go back to Windows again, because there’s always at least one device that doesn’t have a driver or the driver is so buggy it constantly freezes the system). And sometimes even those people contribute to open source projects

But you’re absolutely right about the problems of DVCS. They’re (at least for now, I’m sure they’ll improve) way too complicated for the average people. If you count the programmers out there who never even used version control (besides making a copy of their source folder from time to time and renaming that folder with the date of the copy) you will find that those still outnumber the ones who use version control by thousands. Try explaining DVCS to them - after a five minute introduction they will already have mentally shut down, built a defense wall against such a complicated beast - and from that time on, you won’t get through to them anymore and they’ll find any excuse to not use version control at all.

When I joined TortoiseSVN (yes, I joined, I didn’t start it), it was because at that time there simply was no version control system available that I would have considered introducing in our company. I found a lot back then, but they all were much too complicated to use or had a really high learning curve. I knew that I just wouldn’t be able to explain those to my coworkers (especially the one at the desk to my left back then) and get them to understand. That’s why I joined TortoiseSVN, and I’ve tried to keep it as easy to use as possible, hiding as much of the internals of version control as possible (e.g., you won’t find any peg revisions in TortoiseSVN - it always tries to find that itself). To be honest, most of the time I had to implement something in TortoiseSVN I was thinking about that guy to my left and how I would that feature to him - if I couldn’t come up with an explanation that he would understand I went back to the drawing board and tried to implement the feature a different way. And I think that’s one of the reasons why TortoiseSVN is one of the more successful SVN clients. Kim Sullivan says on November 8th, 2007 at 2:26 am:

Sam Vilain: “However the GUIs have already far surpassed anything you will see in the Subversion space so this is becoming less and less important.”

Great! I’m looking for some DVCS plugin that is on par with Subclipse/Subversive. Could you please post the link? I only found “Mercurial Eclipse” but that didn’t impress me, so I’m stuck with a local SVK repository becuse I can acess that with Subclipse. Two Types of Programmers? « Justin Rudd’s Drivel says on November 26th, 2007 at 3:29 pm:

TunnelRat, you might be surprised. A few years ago, I was in a shop that used TortoiseCVS. It was easier than any other tool we had tried, because it plugged straight into the shell. We didn’t have to launch a separate client as with VSS or PVCS or Perforce. Our file icons in Explorer or any file dialog were shaded red or green for “modified” or “unmodified.” All of the developers on my team were able to pick it up like (snaps fingers) that.

And as others have mentioned, Subversion has pretty much the same level of friendliness if you install TortoiseSVN. (And on the DVCS front, Mercurial has the young but promising TortoiseHg.)

I have bills to pay, too, and that’s why I don’t put up with crap tools that impede my ability to pay said bills. Thomas Arendsen Hein says on October 17th, 2007 at 12:07 pm:

“In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work;”

This is only true for the people having commit access to the central repository. So usually people will send patches, often against the latest release instead of trunk/HEAD/tip/whatever. Other people (which are probably those half way between the 80% and the 20%) will send tar/zip archives which contain all their changes.

“in a decentralized system, the default behavior is for each developer to privately fork the project.”

In Free Software projects using centralized systems, the default behaviour (at least for all the 80% people and most of the 20%) is to not have commit access, so the default is what I described above. For Free Software projects using a DSCM, the same is true for the described 80%, because they don’t know how to handle the SCM, so these people still can send their zip archives. For the 20% the situation is to either share their patches as before, keep their changes private as before, or (new option!) to publish their repository, so other people can benefit from this.

So, yes, there will be more “forks” than before, but now you have a chance to reintegrate these forks (i.e. merge the branch) which would have been very tedious with a centralized SCM. Josh’s Blog › Version Control Techniques says on October 17th, 2007 at 2:21 pm:

[...] by josh. Posted on Wednesday, December 31, 1969, at 4:00 pm. Filed under Programming. Bookmark the permalink. Follow comments here with the RSS feed. Post a comment or leave atrackback. [...] Head On » Blog Archive » Distributed Version Control says on October 17th, 2007 at 3:49 pm:

[...] I just read this article on distributed version control by Ben Collins-Sussman who is a lead developer behind Subversion. If I understand his arguments, he basically says that DVCS is better than centralized VCS, but you probably should not use one since 80% of all developers are too dumbfounded too understand VCS at all. [...] Marc Charbonneau’s Blog » Version Control and “the 80%” says on October 17th, 2007 at 5:32 pm:

[...] From iBanjo, on the topic of distributed version control systems in small corporate development environments: In 2007, Distributed Version Control Systems (DVCS) are all the range among the alpha-geeks. They’re thrilled with tools like git, mercurial, bazaar-ng, darcs, monotone… and they view Subversion as a dinosaur. Bleeding-edge open source projects are switching to DVCS. Many of these early adopters come off as either incredibly pretentious and self-righteous (like Linus Torvalds!), or are just obnoxious fanboys who love DVCS because it’s new and shiny. [...] Susannah Simons says on October 17th, 2007 at 8:16 pm:

Don’t forget that you still have the 80%/20% divide at both Google and FogCreek.

Not that this was your main point, but even using these two companies in your throwaway example is to overlook a point. Google is so much larger a company than FogCreek, and the work that Google does is so much more diverse, that to draw equivalence between the two of them is to invite dismissal on the grounds of hyperbole. Steve says on October 17th, 2007 at 11:59 pm:

offline commits and local branches…THANK YOU! i’m surprised more systems don’t allow this… BIll Black says on October 18th, 2007 at 7:56 am:

“640 K should be enough for everybody!”

And you want now us to think Subversion should be enough for everybody?

Maybe DVCS is not good enough for all, but only good for the top 20%. It doesn’t matter. Linux was once good only for the top 2%. NOw we have “consumer Linuxes”, and the same I do expect in a few years for DVCS, once all the top 20% simplify and iron every wrinkle on DVCS.

– Biil. BIll Black says on October 18th, 2007 at 8:34 am:

Awwww, come on!

DVCS is not going to change the landscape on how we design and code.

Object orientation is going to change the landscape: we will stop writing software, because software will be able to write itself.

You are missing the whole point!

We need no stinking ESBs and SOAs, the software in the future will read what we have written in the past, connect to it, and ask us what we want to do. Then simply perform.

Who needs coders in such an environment? Ben Collins-Sussman says on October 18th, 2007 at 8:35 am:

A number of comments indicate that my post should have been clearer in some ways. It was never my intent to say that “Subversion is good enough for everyone” or that “most of the world is too dumb to use DVCS, so don’t use it.” Instead, I’m simply presenting a checklist — a list of obstacles that DVCS needs to overcome in order to be accepted into mainstream corporate software development. I have no doubt that DVCS systems will get there someday, and that will be a great thing. And I’m imploring DVCS evangelists to be aware of these issues, rather than running around thoughtlessly trashing centralized systems. Daniel Barkalow says on October 18th, 2007 at 11:59 am:

I’m not so concerned about the 20% and the 80%. I’m more concerned about the .2%, the .8% and the 99%. As far as I can tell, 99% of the world doesn’t use anything at all: not a DVCS, not Subversion, not a commonly-visible directory that things are put in; not a series of releases by some maintainer; not patches; they email their latest version of the thing they’re working on to a list of the other people they’re working with, and hope that the next version anybody produces includes their changes. It’s like they’re using “rcs”, but doing it in their heads. That’s who I’d like to reach, in part because I sit near some of them, and I can hear them trying to find current versions of things and waiting for each other to finish working on documents, and I’m always cringing at the lost work and wasted effort.

I think it’s possible, and it’s got more of a DVCS feel to it, for me. The users understand the difference between “Save As…” (commit) and “Send” (push). They know about “Check Mail” (fetch). They do merge or fast-forward by hand. They’ve got no centralization, beyond the fact that, at the end of the process, some particular person is going to issue the press release.

That’s what I want to see somebody write; unfortunately, I don’t know how to use any of the software that these users know how to use, let alone how to write such software. Sam Vilain says on October 18th, 2007 at 5:14 pm:

Strange, I guess that either means that Catalyst is full of 20% programmers, or we must have very good internal training.

Or, of course, this argument is apologist rubbish .

Admit it, you’re just clinging to your old ways in exactly the same way that you accuse people using DVCS clinging to theirs. Your argument falls apart #1.

Your argument falls apart #2, when you realise that DVCS can be configured to work just like Centralized systems, because it’s more like a constraint which is removed than a different constraint. So you can benefit from the same simplicity of operation if you choose, and then people who do not need this can work without the shackles if they choose.

Yes they are not yet as integrated into things like the Windows shell. However the GUIs have already far surpassed anything you will see in the Subversion space so this is becoming less and less important. Matthieu says on October 18th, 2007 at 6:10 pm:

Errr…

o Most DVCS systems don’t run on Windows at all.

Can you cite one DVCS that doesn’t run on Windows?

o Most DVCS have no shell or GUI tool integrations; they’re command-line only.

Can you cite one DVCS that doesn’t have a GUI and that is command-line only?

I won’t argue about the “centralized systems encourrage review” Vs “decentralized systems encourrage bad practices”, other people did so already, and you probably know it’s wrong if you already looked at a few examples in real life. Matt Galvin says on October 19th, 2007 at 11:08 pm:

Great post. I have had more than one battle trying to introduce people to version control. I have had the most success with Subversion largely because of granular permission control, the Subversive Eclipse plugin and TortoiseSVN… and it is my VCS of choice.

I can’t even begin to describe how much I agree with the whole reality thing. People really need to come back to Earth and get and keep a solid grip on reality. I love what I do, but most people simply don’t care. I always try to keep that in mind. Introducing new tools can be less painful if it is done at the right time and with a little bit of care and understanding.

Replying to Colin:

I’m aware that I’m criticizing DVCSes which are (barely) 1.0 technologies. I have no doubt that they’ll get better over time, and that many of my criticisms will be fixed. On the other hand, I’m mainly responding the fanatical evangelists of DVCS; I’m trying to get them to be aware of these current flaws, and why DVCS is still mostly inaccessible to “the 80%”.

If you have people using a centralized repository that are blindly clobbering other people’s changes… then you have a serious social problem. The fact that it’s centralized just makes you more acutely aware of the problem, since a few people tend to spoil the public well for everyone, rather than spoiling their own private well.

Not sure I understand your “branch” complaint… the subversion filesystem is DAG, in fact. That’s why copying a directory (making a tag or branch) is a constant-time operation: it’s just making a new hard-link to an existing inode in the DAG. There’s a whole layer in the repository that covers up the DAG, trying to make it look like a normal filesystem. Colin Barrett says on October 16th, 2007 at 8:11 pm:

Responding to fanatics and such legitimizes them. Don’t let them get under your skin, or address any logical flaws in their arguments calmly. I feel your pain though (” Firefox will never look good on the Mac because it is cross platform”).

You know Augie Fackler, right? Ask him about Adium. He’ll tell you all about build breakages and stuff (people are better, but yeah…)

The problems, at least for me are (and you can see all these in the Adium repository):

• People committing to multiple branches in the same commit
• Multiple hierarchies in branches/ (ex: branches/summer_of_code_2006/student_name/)
• Copies of things other than trunk/ in branches/ (ex: branches/ChangeLog/changelog.txt)

All of this makes automated tools for looking at history go absolutely crazy. It’d be nice to enforce some invariants there :\ Again, social problems, but as you said, defaults matter.

The concept of a versioned file system is cool and all, but lets enforce some invariants here, or something… Colin Barrett says on October 16th, 2007 at 8:14 pm:

s/skin, or/skin, and/ Kalid says on October 16th, 2007 at 8:38 pm:

Great article. I recently wrote about regular VCS and DVCS systems, aimed at newbies (of which I am for DVCS). In my view, any VCS is a good VCS given that most people in the 80% aren’t using anything. I found the arrogant “DVCS are better, fool!” quite off-putting as well.

Keep up the good fight — introducing people to new tools is a crawl/walk/run process dextrous says on October 16th, 2007 at 8:57 pm:

Good walk through, from long time, I wanted it to say same thing to fanatics who are so obssessed with them selves that they are not even bother about others. I fully agree with you that DVCS might be good for some project but not all, this fact has to be realized, as I use subversion I know what it is capable of and its not as bad as it was qoted by some fanatic freaks. Distributed Version Control for the Other 80% - Kyle Cordes says on October 16th, 2007 at 9:26 pm:

[...] Ben Collins-Sussman, one of the key developers behind Subversion, argues in Version Control and the 80% that distributed version control will remain a niche interest, and will not move in to the mainstream (as his favorite tool certainly has). He has a number of good reasons to back up this thesis. [...] share reading in October « Robot Brain says on October 16th, 2007 at 9:44 pm:

[...] 2. Version Control and the “80%” [...] Why I HAVE to use Git from now on... — Josh Kim dot Org says on October 16th, 2007 at 10:09 pm:

[...] EDIT: Version Control and “the 80%” [...] TunnelRat says on October 16th, 2007 at 10:23 pm:

I gotta admit, I am in the 80% and totally agree with Shocking statement #2. I know Microsoft and nothing else — its been that way for 15 years. That goes for VSS. I just started a freelance ASP.NET gig and my DBA buddy wanted to use Suberversion. I said no f-ing way. I had to admit, I never heard of it.

But why bother? I been using version control since PVCS. And VSS is the defacto standard among the enterprisy 80%. It even shows up on job reqs.

There is no silver, no cool tool to handle a large project with a lot of developers checking stuff in. IMHO, merging and branching doesn’t work well, and exclusive checkouts are the way to go. That means you need good team leads and configuration managers to sort out the bs. Code reviews, continious integration, and discipline are what it takes.

But if it has a VisualStudio plug-in, maybe even I’ll try it. But you can have all that LAMP, Ruby, Lisp stuff — I have bills to pay. zach says on October 16th, 2007 at 10:37 pm:

Interesting take on the adoption of version control and an excellent summary of why large corporations will be slow to adopt DCVS, but I’m a little put off.

I am shocked by shocking statement #1. Am I that naive, or is 80% of our industry really as characterized? Just because they’re vocational (I’m willing to accept this part of the premise) doesn’t mean that they’re bad at their job — version control and a working Linux abilities are vital tools for a programmer.

And why lump Eclipse in the “bad / clueless practice” category? I run eclipse — on Linux — and am continually amazed at how much it aids my development. It’s got built-in refactoring tools, great debugging (including remote jvms), and it dramatically automates much of the boilerplate java forces you to write. If you are developing Java, you have either a) Eclipse or another IDE with the features named, b) deep, deep black magic macro skills with your text editor, or c) something wrong with you.

Yes, I’m relatively new to the field. Maybe if I had an additional decade of experience under my belt I would agree with the 80% summary, but there is no way on earth 80% of the developers where I work are so ignorant of best practice. Seeing the agreement in the comments above, I’m forced to conclude that the hiring bar is a lot higher than average where I work, because if you don’t know how to use version control and dig through a directory on Linux with your shell, you are not getting hired.

Thanks again for the interesting article.

zach zach says on October 16th, 2007 at 10:45 pm:

Dangit, just read the comment above mine.

Very saddened,

zach Chris Smith says on October 17th, 2007 at 12:48 am:

After thinking about this for a while, I think there’s a confusion between technology and policy here. The confusion exists on both sides of the fence. Distributed version control systems are a somewhat different technology; but it’s by no means true that they require different policy.

I’d be willing to bet that among corporate software development using version control systems, there still exists one central repository that everyone thinks of as “the” code base. Certainly there is one where I work now. Similarly, I can think of no place I’ve ever worked with a traditional version control system where developers didn’t keep a working copy of the entire code base on their systems, and sync it up with the repository on occasion.

There’s a good point here. This kind of organization exists for a reason, and it’s not just because everyone has adapted to the limitations of technology. Anyone preaching the gospel that we should no longer have a centralized code base is going to hit a wall. This is all too common among the DVCS community.

Similarly, though, it’s incorrect to argue that distributed systems are not workable just because they aren’t tied to that policy decision. What needs to be said is that it’s entirely possible to reproduce that same policy decision while using darcs, for example, and everything still works fine. Sure, darcs doesn’t require that decision, but neither does darcs preclude it.

Eventually, what I’m sure will happen is that businesses will cautiously pursue incremental changes to their policy decisions. Eventually, they’ll arrive at a sort of hierarchical arrangement of code repositories for large projects, which will fit the organization’s structure a little better than current centralized systems do. It remains true that a necessary component for this migration is that they adopt “distributed” systems (perhaps after the movement changes its name), because the change relies on the simple fact that using an organization-neutral VCS makes it easier to tweak the organization. One doesn’t have to wait for the software to catch up. Shanti Braford says on October 17th, 2007 at 1:49 am:

While it’s fun to play with new technologies, version control seems like one of those things you’d want to make sure was really well dogfooded (and that your data was consistently backed up / secure).

One recent blog post about a startup said that they started out using git, without a central server, and started sharing the repo between two client machines. I’m sure 99.9% of the time this is perfectly alright, but for my paranoid self I prefer –

central repository on a server that’s backed up regularly at least 2 checked out copies on different machines (at least one of which is not a laptop)

But maybe I’m just being paranoid, or not fully understanding git / DVCS. Daniel Svoboda says on October 17th, 2007 at 1:53 am:

Unfortunately I am part of third category of programmers, and now I can’t clasify myself, because there is no percentage left for me in your description. Looks like I don’t even exist. Mark says on October 17th, 2007 at 2:03 am:

The biggest problem in Subversion I encounter roughly weekly with the 80% crowd, is the fact that version control information is stored separately for each directory. They keep renaming (or more often, deleting) the directories and they get themselves into a mess. Git is better here because it has one directory for meta data.

git is a non-starter for them due to a complicated mental model (index, git-commit -a, and related). Merging/distributed is not a problem since most will not use any different than subversion (update/push)

Mercurial sems nice, but seems less robust in behavior than svn. James says on October 17th, 2007 at 3:14 am:

I admit the 80% does exist - and they are not all programmers. I develop Flex and many of our assets are images, animations, movies and sounds. Plus XML configuration files. I’d love artists to use VCS but they have real trouble using SVN.

Most of the complaints I saw in the Linus git video are around merging. He’s probably never used Perforce WinGui but that is sweet (note SVN devs: If you can match Perforce’s safe merge and auto-merge behaviours your most of the way there … in fact just become an open source Perforce clone, it is really the best). Really - auto merging files with no warning is brain-dead behaviour. Notify the user a merge is pending and allow them to sort it out at their leisure.

I guess I’m in the 20% since yesterday I installed Mercurial and set up a test repository to give it a go. The merging seems similar to Perforce (warns before merge - auto merges - conflicts raised into graphic 3-pane merge app).

Your claims are both founded and unfounded. I could put together a hierarchical process using DVCS where programmers push to leads, leads push to higher leads and so forth until it hits testing/release/etc. Breaking code into modules keeps confidential stuff confidential (e.g. check-out pre-built confidential modules and source section modules). In fact, I like the idea of not having to download large 3d source files and just having a pre-built place to pull from. Leads become responsible for aggregating and reviewing. It creates a responsibility chain that a central system does not have. Code escalation.

Good comments though - SVN is the best popular free choice Nikhil says on October 17th, 2007 at 5:26 am:

I totally agree about the 80/20 divide. But unfortunately the 80% guys will never read this post of yours, because the programming blogosphere is written and read only by the 20%, Pierre THIERRY says on October 17th, 2007 at 7:39 am:

zach, you say “version control and a working Linux abilities are vital tools for a programmer”.

While I would tend to agree (I couldn’t develop without version control and a powerful OS at hand), most of the IT industry would have been decimated for a long time if that was even remotely true.

Most programmers probably don’t even understand the very basic notions of version control, not to speak about branching and merging, never learned regular expressions and a devent scripting language.

They (sometimes) store regular snapshots of their code on CDs, search/replace is the most complex tool they’ll ever use when it comes to automatic code change and do a lot of basic file manipulatins by hand. Mike says on October 17th, 2007 at 8:08 am:

Hmm. The thing that pushed me to look at git in the first place was using Subversion for a few months and seeing how unpleasant it is. The whole ’svn copy’/trunk/tags/branches thing is hard to use and hard to understand. For the unwashed 80%, I like RCS–it’s quite simple and handles the simple cases, which, as you say, are all that the 80% really need anyway. Jay says on October 17th, 2007 at 8:10 am:

What f..ing planet do you come from?

“In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work;…”

I have been in the IT industry for years and have NEVER had a meaningful code review. Vey very rarely are people working on the kinds of projects where they need to collaborate to any great extent. A lot of businesses have a buy instead of build software mentality.

This does remind me. I was working on a very large project to redo a order entry system. If the code I had written was wrong the company would not be able to ship product. When having a casual BS session with the manager of the project I mentioned that I though code reviews were a great idea and that are company should do them. I also mentioned that I had been at the company for 3 or 4 years and we had basically never done them. Guess what? I was the first person on the project to get a code review.

I was fairly nervous and all about it. They scheduled the meeting. I printed out the 60 or 70 pages of code. They arrived at the meeting about ten minutes late. They didn’t get much past the fifth or six page. Done. Good to go. This is code that had to be correct or we didn’t ship computers out the door.

The place I am out now also has code reviews and we do them before we put anything into production. Guess what, I have never had to change anything as a result of the code review. As a matter of fact fairly often they are done by a person that may not even understand the technology I am working with. 20Percent says on October 17th, 2007 at 8:37 am:

“I just started a freelance ASP.NET gig and my DBA buddy wanted to use Suberversion. I said no f-ing way. I had to admit, I never heard of it.”

What Microsoft tools are you using for Continuous Integration? Ben Collins-Sussman says on October 17th, 2007 at 8:59 am:

Jay: my comment about “being forced to collaborate and review work” was specifically about the impact of centralized repositories on open source projects. That’s a completely different culture from corporate software development, where code reviews almost never, ever happen. (You’re totally right about that — I’ve been there.) Jared says on October 17th, 2007 at 9:30 am:

I’m sort of one foot in, one foot out of the 80%. I do the vast majority of my programming in a platform agnostic language (Javascript.) Previously I programmed my sever side stuff in PHP, I wanted to learned Ruby but in order for me to learn Ruby I need a project to do so that is relevant to me, not just some hello world app. I’m currently in a Gig that uses vb.net as the back end. I wanted so bad to use SVN starting my project because I recognise the benefits of using a versioning system, but I’ve never used it before and when I installed it I had NO EFFIN CLUE what anything really meant. I don’t have time to read through a cryptic manual meant for the 20%, I need a simple tutorial that spoon feeds me the basics in a clear and step-by-step manner. I simply don’t have time to tinker and learn by trial and error like I used to.

And like many things open source when you go to look for help you usually just find a hostile forum, or if you’re lucky an irc channel with nothing but idlers, but more likely a cob-webbed newsgroup (which usually precludes a great majority of the 80% ever even knowing it exists,) with nothing but a slew of unanswered questions by newbies like myself. Not exactly saying this is the case with SVN, but lets just say I’ve become disillusioned when it comes to looking for support on OSS projects. More OSS startups should model their support after Mozilla in my opinion, they have such an active support userbase on mozillazine, irc and newsgroups whatever your choice you’ll find a lot of mostly friendly people looking to help. Andrew Bettison says on October 17th, 2007 at 9:45 am:

I would say it’s more like 5% - 20% - 75%. The band in the middle are more or less competent, and may or may not actually enjoy their work. Five percent are well above competent, they are on about excellence in one way or another. Easily seventy percent are below competent, and don’t understand why the rest get so enthusiastic, and resent being treated like inferiors.

This distribution is found in all professions and trades. Medicos, financial advisers, teachers, social workers, bureaucrats, law makers. Scary when you think about it.

I remember once saying to some co-workers, while enthusing about the latest developments in interpreted languages (Python, Perl, Java, etc.), “If you don’t love the stuff, what are you doing here?” Blank looks. Left me in no doubt I was surrounded by 80%-ers. Karl Fogel says on October 17th, 2007 at 10:27 am:

Great essay!

I was talking about it with jackr (see first comment) and others recently. One thing we thought was that the differences between today’s centralized and decentralized systems are divisible — that is, it’s more of a feature-by-feature difference than a monolithic “fully centralized” versus “fully distributed” difference. Everyone agrees Subversion should have local commits, and “foreign branching”, for example. It just might not get those features at the same time.

There are certain features that, today, tend to be present in the distributed systems but not in centralized ones (just as there are the reverse, e.g., locking & lock notifications). Some of those features come more naturally to the distributed systems, I won’t deny that (and again, the reverse is true as well), but the point is that it’s the features users use, not the single adjective used to describe the system as a whole. Vile says on October 17th, 2007 at 11:10 am:

’tis the ideas that count. Next generation of version control systems will have picked the best ideas from each of the current ones. MaryG says on October 17th, 2007 at 11:22 am:

Great article! I’m not a programmer (though I am in the website development business) but we’ve got programmers here that I’ve never really looked at in this point of view. The agents here at Agents of Value are more or less part of the 80%, although I would like to think that there’s one or two who has the potential to be one of the 20%. undees says on October 17th, 2007 at 11:27 am:

五、配置管理经验谈 围绕配置管理,世界一些致力于软件工程研究的公司在深入理解 ISO 9000 的基础上, 推出了各种符合 ISO 9000 配置管理标准的工具软件,如 INTERSOLV 公司的 PVCS,Rational 公司的 Clear Case 等。这些配置管理工具面向软件规范化、工程化、自动化的需要,帮助开发团队提高科学管理水平,从而提高工程效率,降低工程成本。现以 PVCS 为例,结合我们的实际经验,谈谈我们实施配置管 理的益处:

1. 节约费用 (1) 缩短开发周期 利用 PVCS 的 Version Manager 对程序资源进行版本管理和跟踪,建立公司的代码知识库,保存开发过程中每一过程版本,这样大大提高了代码的重用率,还便于同时维护多个版本和进行新版本的开发,防止系统崩溃,最大限 度地共享代码。同时项目管理人员可以通过 Version Manager 查看项目开发日志,测试人员可以根据开发日志和不同版本对软件进行测试,工程人员可以从 Version Manager 上得到不同的运行版本,并且 Version Manager 可以安装在 Web Server 供外地施工人员存取最新版本,无需开发人员亲临现场。 利用 Tracker 组建开发团体之间的问题跟踪及消息通迅,通过其 Notify 模块与电子邮件结合起来大大加强了开发团体之间的沟通,Reporter 模块可对发现的问题进行整理、以报表方式分类报出,作为开发� ��指导。 以上为 PVCS 的两个主要模块,科学地应用可以大大提高开发效率,避免了代码覆盖、沟通不够、开发无序的混乱局面,如果利用了公司原有的知识库,则更能提高工作效率,缩短开发周期。 (2) 减少施工费用 利用 PVCS 进行软件配置管理后,建立开发管理规范,把版本管理档案挂接在公司内部的 Web 服务器上,内部直接通过 Netscape 访问 Version Manager,工程人员通过远程进入内部网,获取所需的最新版本。开发人员无需下现场,现场工程人员通过对方系统管理员收集反馈意见,书面提交到公司内部开发组项目经理,开发组内部讨论决定是� ��修改,并作出书面答复。这样做,可以同时响应多个项目点,防止开发人员分配到各个项目点、分散力量、人员不够的毛病,同时节约大量的旅差费用。
2. 有利于知识库的建立 (1) 代码对象库 软件代码是软件开发人员脑力劳动的结晶,也是软件公司的宝贵财富,长期开发过程中形成的各种代码对象就像一个个零件坯一样,是快速生成系统的组成部分。长期的一个事实是: 一旦某个开发人员离开工作岗位,其原来所作的代码便基本成为垃圾,无人过问。究其原因,就是没有专门对各人的有用对象进行管理,把其使用范围扩大到公司一级,进行规范化,加以说明和普及� ��Version Manager 为对象管理提供了一个平台和仓库,有利于建立公司级的代码对象库。 (2) 业务及经验库 通过 PVCS Version Manager 的注释及 Tracker,可形成完整的开发日志及问题集合,以文字方式伴随开发的整个过程,不依某个人的转移而消失,有利于公司积累业务经验,无论对版本整改或版本升级,都具有重要的指导作� �。
3. 规范管理 (1) 量化工作量考核 传统的开发管理中,工作量一直是难以估量的指标,靠开发人员自已把握,随意性相当大;靠管理人员把握,主观性又太强。采用 PVCS 管理后,开发人员每天下班前对修改的文件 Check In,其中记述当天修改细节描述,这些描述可以作为工作量的衡量指标。 (2) 规范测试 采用 PVCS 以后,测试有了实实在在的工作,测试工作人员根据每天的修改细节描述对每一天的工作做具体的测试,对测试人员也具有可考核性,这样环环相扣,大大减少了其工作的随意性。 (3) 加强协调与沟通 采用 PVCS 后,通过 Version Manager 文档共享及其特定锁机制、Tracker 与电子邮件的集成,大大加强了项目成员之间的沟通,做到有问题及时发现、及时修改、及时通知,但又不额外增加很多的工作量。 六、配置管理的精髓 具体来讲，配置管理包含如下内容： 􀂾 标识：识别产品的结构、产品的构件及其类型，为其分配唯一的标识符，并以某种形式提供对它们的存取。 􀂾 控制：通过一定的机制控制对配置项的修改 􀂾 状态报告：记录并报告配置项以及元数据的状态。 􀂾 配置审计：确认产品的完整性并维护配置项间的一致性。 从上面的描述，我们知道，配置管理的基本单位是配置项。 从 “哲学” 意义上讲，它记录配置项的三个方面： 􀂾 从哪里来？此项可归结为 WWW 的问题，（Who）谁创建的？（When）什么时间创建的？（Why）为什么创建此配置项？ 􀂾 当前在哪里？此项纪录配置项当前的存储位置以及状态。 􀂾 将到哪里去？通过配置控制来把配置项 “组装” 到正确的版本中去。 配置项可以是大粒度的，也可以是小粒度的。如果跟踪个别需求，那么不必要把整个需求规格说明文档定义为一个配置项，可以把每个需求定义为配置项；如果把软件开发工具也放入配置管� ��系统，那么把配置项定义为文件级就不合适了，只需要跟踪开发工具的版本，即把整个配置工具定义为一个配置项就足够了。 简而言之，配置项可以是文件级粒度的，也可以使文件版本级粒度的。当然，粒度越小管理的成本越高，但是配置的精度也就越高。 一个完整的 SCM 系统要具有三个核心功能：版本控制、变更控制、配置控制以及两个支持功能：状态统计和配置审计。 版本控制 版本，亦称配置标识，是指某一特定对象的具体实例的潜在存在。这里的某一特定对象是指版本维护工具管理的软件组成单元，一般是指源文件；具体实例则是指软件开发人员从软件库中恢� ��出来的某软件组成单元的具有一定内容和属性的一个真实拷贝。例如，对源文件的每一次修改都生成一个新版本。 版本控制就是对在软件开发过程中所创建的配置对象的不同版本进行管理，保证任何时候都能取到正确的版本以及版本的组合。 当前，这方面典型的工具有如 VSS 和 CVS。 变更控制

变更控制是通过对变更请求（Change Request，简称 CR）进行分类、追踪和管理的过程来实现的。 变更的起源有两种：功能变更和缺陷修补（Bug-Fix）。功能变更是为了增加或者删除某些功能。缺陷修补则是对已存在的缺陷进行修补。 对变更进行控制的机构称为变更控制委员会（Change Control Board，简称 CCB）。变更控制委员会要定期召开会议，对近期所产生的变更请求进行分析、整理，并做出决定。而且要遵循一定的变更机制。 下面是一个典型的变更机制：

我们可以随着变更过程的推进，提升配置项的状态。 这方面的工具有 Bugzilla。

配置控制 配置控制使用户能够通过对适当版本的选择来组成特定属性（配置）的软件系统，这种灵活的 “组装” 策略使得配置管理系统象搭积木似的使用已有的积木（版本）组装成各种各样、不同功� ��的模型。 软件产品的每个版本都是一组配置项（源代码、文档、数据）的集合。配置控制就是要保证每个配置的完整性和精确性。 举个例子来说，我们要发布软件的 32.6 版本，那么我们就要把源代码、文档、数据中所有这个应该包含到这个版本中的正确配置项检出。 在开发过程中，我们在不同阶段要建立各种基线。基线的建立是配置控制功能的典型应用。所以说，基线是具有里程碑意义的一个配置。 一般的商业软件配置管理工具都具有配置控制的功能，只是灵活性和精确性有差别。 状态报告 状态报告要回答所谓 4W 的问题： What：发生了什么事？ Who：谁做的此事？ When：此事是什么时候发生的？ Why：为什么做此事？ 状态报告还要能够报告所有配置项以及变更请求的状态。 配置审计 配置审计要审查整个配置管理过程是否符合规范，配置项是否与需求一致，记录正确，配置的组成是否具有一致性等等。 由于现在软件行业越来越重视质量，许多项目专门成立质量保证部门专门来进行配置审计。所以现在也可以说，配置审计是一个 SQA（软件质量保证）活动。 配置管理的商业模型 配置管理的实施包括两部分：工具和规范。 在软件开发过程自动化的今天，没有工具的支持而实施配置完整的配置管理是不能想象的。因此选择一个符合公司或项目的工具至关重要。在配置管理系统中，我们可归纳出四种模型。当前� ��业工具一般采用其中一种或几种模型。 我们通过对商业模型的理解可以帮助我们了解某种工具是否适合我们公司或项目。 CICO 模型 CICO 模型主要关注的是单个文件的版本控制。图显示了一个支持 CICO 模型的 CM 系统的工作过程。用户利用库和文件系统来进行工作。文件被版本化并存储到库中，新版本的产生是由库工具控制的 。然而， 文件在库中不是可以直接存取的，用户必须去检出（即 Check Out）一个文件的版本到工作空间中以便读取它的内容。更改后的文件可以被检入库中（即 Check in）,产生文件的一个新版本。 此模型的代表工具是 SCCS 和 CVS。

组织模型

组织模型由 CICO 模型自然导出，建立于构件版本图的基础之上，同时依赖于存储库和工作空间的概念，可以通过对构件加锁进行并发控制。组织模型的重点是在 CM 系统支撑下加强了对创建配置� ��对有关的历史信息的管理和使用他们作为工作环境的支持。 组织模型中的配置由系统模型和版本选择规则组成。系统模型列出了组成系统的所有的构件。版本选择规则指出了组成配置的每一个构件选择版本。选择规则用于系统模型，选择构件版本，� ��绑定一构件到某一版本。这个模型的操作方式是：开发员根据模型的构件定义整个系统，并在每一步骤中给每个构件选择合适的版本。版本操作的工作方式如图所示。 CM 支持主要关心的是维护系统和其构件的版本历史，并选择符合一致性配置的构件版本。只有在所选构件的版本与所选其它构件版本一致时才认为一个配置版本。 此模型的代表工具是 CCC。 长事务模型 长事务模型主要支持包括一系列原子变更的全系统演变和由团队开发员对系统变更的协调。开发员主要操作配置而非单独的构件。事务提交的结果是新配置版本，一系列连续的变更结果生成� ��系列的配置版本，称为开发路径。 在长事务模型中，开发员主要的工作对象时配置，开发员首先选择系统配置版本，接下来把关注重点放在系统结构上。构件的版本由配置隐式决定。长事务由两个概念组成：工作空间和并发� ��制方案。工作空间来源于存储库或一个封闭工作空间中的一个固定配置。工作空间由工作配置和一系列已保存的配置组成。工作配置代表构件和系统结构能够被动态更改的配置。提供通过� �作空间进行的透明库访问、将高效的库存储技术应用于工作空间和管理派生构件的版本。

此模型的代表系统是 NSE。

变更集模型 主要集中于对系统配置的逻辑变更的支持。在这个模型中引入的变更集表示组成逻辑变更的对不同构件修改的集合，它是创建变更的活动完成后对逻辑变更的记录。支持这个模型的 CM 系统用� �可以直接操作变更集。在变更集模型中，配置可描述为由基线和一组变更集组成。 变更传播给其它配置可通过包含各自变更集来进行。开发员使用不同的集成策略将逻辑变更集包含到一个新的系统发行中。这样的好处非常明显，例如，我们现在维护 10 个不同版本的产品，� �在要对所有的版本修改一个缺陷（Bug）。如果相同的工具简单的重复 10 次显然是不可接受的。而通过变更集把这个逻辑变更从一个版本自由的传到另外一个版本。 开发员可跟踪逻辑变更和确定这些变更是否属于特定配置。这种配置管理的方法，因为其将重点放于逻辑变更上，所以被称作面向变更的配置管理。它不同于现在的其他 3 种 CM 模型，因为其它 3 种 CM 模型使用的面向版本的方法把重点放在构件和配置版本上。 在单一构件的情况下，变更集是两个文件版本之间区别的集合，通常指的是增量内容。对配置来说，变更集就是两个配置版本之间区别的集合。这组区别就是两个配置版本间的修改构件增量� ��合，即变更构件集的增量。 面向变更的观点不同于面向版本的观点。这有两点不同，一是逻辑变更的显式表示允许对与单个构件和配置有关的变更集进行跟踪。二是引用单个变更集并有选择地将它们纳入配置管理中的� ��种能力提供了对系统演化管理的支持，这种演化是基于将逻辑变更传播到维护的系统配置进行的。 此模型的代表工具是 UCM 和 SABLIME。

结束语 配置管理本身无论从理论和实践都在不断丰富和发展。例如，配置管理应用于 “知识库” 的管理就产生了 “内容管理” 这一新的领域。配置管理提供的状态报告和数据统计也为软件度量提供� ��决策依据。配置管理为项目管理提供了各种监控项目进展的视角，为项目经理确切掌握项目进程提供了保证。配置管理也为开发人员提供了一个协作的平台，在此平台上，大家能够更有效� �的交流和协作。可以说，配置管理是软件开发的基石！ 配置管理近年来在中国得到了极大的认可，可以毫不夸张的说，没有配置管理，就谈不上软件开发，就谈不上软件质量，就谈不上软件业的发展。随着软件业规模的扩大，配置管理的实施不� ��要不要的问题，而是什么时间、如何实施的问题了。 [url]http://baike.baidu.com/view/569797.htm/url][