用如果造句 牛奶不如果汁好喝

用果真造句，苹果真好吃

你少了个"乡"字.我家又不住大堤上边.....hometown 从老家回来,bus 抛锚了,司机修车,我中途下来拍了两张,光线充足的话,照的效果还可以

还记得一部电视剧里说了这么一句话:"现在农村就剩下空气不错了"

zoe 于 2008-7-15 12:13 发表
你手机乱拍，泄漏别人隐私～ [/quote] 大众照片,又不特写某个人

zoe 于 2008-7-15 12:11 发表
我这几天正看红楼梦呢 刚看过那段···

得到教训了吧，女人也不是那么好惹的！！！ [/quote]

什么时候你又转型才女拉?

gao qiao zhen~~

好隐讳的缩写啊

还有几张，手机照的，所以不是很清楚

[[i] 本帖最后由 laofo 于 2008-7-14 22:01 编辑 ]

laofo 于 2008-7-14 13:00 发表
出处：京华时报　作者：王京　2008-07-14 备受关注的 3G 版 iPhone 上周末终于在首个大中华地区——香港正式上市。上市首日，和记电讯还推出了最低售价 0 港元的套餐。

　　备受关注的 3G 版 iPhone 上周末终于在首个大中华地区— ... [/quote] iPhone 手机还是很 pp 的

haha,笑死了

zoe 于 2008-7-13 23:19 发表
不能乱 8g，恩恩 [/quote] 不是吧?难道他真的住到 GCZ 去了?

zoe 于 2008-7-13 23:20 发表
鼓掌～～～～～～～～～ 撒花～～～～～～～～··· [/quote]

我的钱啊钱啊钱啊

zoe 于 2008-7-13 23:21 发表
那个 CIO？？ 他跳去哪了？？？？ ZTE？？ [/quote] 具体还不知道,方正是要走了..

ZYS 也跳槽了

yes 以前空间是和别个共享 IP 的,现在已经是独立 IP 了.

zoe 于 2008-7-11 12:48 发表
ps：自从你跟老马混了之后，腐败啊腐败！ [/quote]

啊啊?是么?有多节俭?说说啊

laofo 于 2008-7-4 09:50 发表
Branching and merging in the face of agile development, extreme programming, team collaboration, and parallel releases. Laura Wingerd • Perforce Software • [url=http://www.perforce.comwww.perforce.com[/url]] What we’ll cover The ide ... [/quote]
The Flow of Change—Wingerd.pdf

[[i] 本帖最后由 laofo 于 2008-7-4 12:54 编辑 ]

[url]http://linuxmafia.com/faq/Apps/vcs.html#jrms/url][

[url=http://www.qef.com/html/QEF[/url]] (QEF, Inc., formerly QEF Advanced Software, Inc.) ([url=http://linuxmafia.com/faq/Apps/vcs.html#qeflink[/url]) QEF is a complete software-management/build system that includes a wrapper to use third-party VCSes such as [url=http://linuxmafia.com/faq/Apps/vcs.html#rcsRCS[/url]], SCCS, and [url=http://linuxmafia.com/faq/Apps/vcs.html#cvsCVS[/url]]. (It is often listed as an VCS, but technically includes no VCS component of its own.) Binary-only. Proprietary.

[url=http://www.visible.com/Products/Razor/Razor[/url]] (Visible Systems Corporation) ([url=http://linuxmafia.com/faq/Apps/vcs.html#razorlink[/url]) Razor (developed by Tower Concepts, Inc., which was acquired in 1998-12 by Visible Systems Corporation) offers VCS integrated with trouble-ticketing and project and release management. The Linux version appears to work only on 2.0 and 2.2 kernels. Visible Systems is trying to extend this into a comprehensive IDE. Concurrent licences are available in blocks of 5 for US $3,700, with quantity discounts, and optional annual maintenance contracts (with upgrades) are about 15% additional. Binary-only. Proprietary.

[url=http://www.ipd.uka.de/%7Edurasoft/frame_en.htmlRCE[/url]] (DuraSoft GmbH) ([url=http://linuxmafia.com/faq/Apps/vcs.html#rcelink[/url]) RCE (Revision Control Engine) is a local-oriented (non-network-aware) VCS, designed to improve on [url=http://linuxmafia.com/faq/Apps/vcs.html#rcsRCS[/url]], with an optional graphical front-end (Visual RCE), created by Walter F. Tichy, creator of RCS. Supports any data format, parallel development, automatic history. There is a Java-based GUI front-end. Binary-only. Proprietary.

RCS ([url=http://www.cs.purdue.edu/homes/trinkle/RCS/1[/url]], [url=http://www.gnu.org/software/rcs/rcs.html2[/url]) (Free Software Foundation) ([url=http://linuxmafia.com/faq/Apps/vcs.html#rcslink[/url]) RCS (Revision Control System), originally written by Walter F.Tichy at Purdue University in the early 1980s, is a simplelocal-oriented (non-network-aware) VCS, often considered somewhat more advanced than [url=http://linuxmafia.com/faq/Apps/vcs.html#csscCSSC[/url/SCCS], and yet (as it turns out) much less useful as the foundation of an advanced system. Implements locking and a centralised (local) repository. Supports tags, and symbolic names for revisions. Supports versioning of binary files if you're careful to disable keyword expansion. Has a (primitive) merge function. History (implemented as a series of deltas backwards from the tip versionof each file handled) is stored in the working directory.
Code is C. Open source (GNU GPL).

[url=http://www.bell-labs.com/project/sablime/Sablime[/url]] (Lucent Technologies, Inc.) ([url=http://linuxmafia.com/faq/Apps/vcs.html#sablimelink[/url]) Sablime appears to be a well-rounded networked system. Lucent Technologies is coy about pricing. Predecessor codebase: AT&T's internal CMS & ECMS VCS systems. Lucent Technologies was formerly AT&T Software Solutions. Binary-only. Proprietary.

[url=http://sccs.berlios.de/SCCS[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#sccs%22link[/url]) SCCS (Source Code Control System) is the oldest VCS, alocal-oriented (non-network-aware) system developed in 1972 by Marc Rochkind at Bell Labs on an IBM System/370 running OS/MVT. It's the first change-management system to record a distinct identifier for each revision and keep a clear revision history. Version numbers are in format "major.minor". Uses weave storage, which makes it an [url=http://blog.fxa.org/articles/2005/09/30/bzr-weaving-its-way-to-the-frontexcellentfoundation[/url]] for building advanced VCSs, despite SCCS's antiquity. Does locking, uses a central repository. Versions files (doesn't dochangesets). Doesn't handle binary files. No merging. Confusingcommand-line interface. Code is C. Open source (CDDL, GNU GPL, GNU LGPL).

[url=http://kisocd.sf.net/siveco.htmSiVeCo[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#sivecolink[/url]) SiVeCo (Simple Version Control) is Jens Wilhelm Wulf's basic VCS, designed for use by someone working alone on smaller projects. It is self-contained, but requires a filesystem supporting symbolic links (and therefore cannot run on Win32). Code is C++. Open source (GNU GPL).

[url=http://www.truebluesoftware.com/SnapshotCM[/url]] (True Blue Software Company) ([url=http://linuxmafia.com/faq/Apps/vcs.html#snapshotcmlink[/url]) SnapshotCM (formerly TrueCM) is a multi-platform, networked VCS with easy merging and branching, storing most files in RCS storage. Integrates with sundry IDE front-ends using Microsoft's SCC application interface. Binary-only. Proprietary.

[url=http://potiron.loria.fr/documentation/so6-user-manualSo6[/url([url=http://linuxmafia.com/faq/Apps/vcs.html#so6link[/url)] So6 is a 100% Java networked VCS intended to be used as part of the LibreSource development environment, where diffs get checked in by various users into a message queue, which then generates an event and consequent messages to notify other users of their availability. Instead of branches, there are multiple message queues with which the user can elect to synchronise. Network access is mediated via Sun Java Web Start over generic http transport.
Code is Java. Open Source (QPL v. 1.0).

[url=http://www.mks.com/products/sis/Source] Integrity/url ([url=http://linuxmafia.com/faq/Apps/vcs.html#sourceintegritylink[/url]) MKS Source Integrity seems to be a local-oriented(non-network-aware) VCS designed to integrate with various MS-Windows IDEs and Mortice Kern Systems Inc.'s workflow management software. Does automatic merging, supports event triggers. Binary-only. Proprietary.

[url=http://sourcejammer.sourceforge.net/SourceJammer[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#sourcejammerlink[/url]) SourceJammer is a 100% Java networked system with renames/moves, requiring Jakarta Tomcat or Apache / Resin, the proprietary Sun JDK / JavaBeans / JavaMail , Apache SOAP and Xerces. Does labels, but it's unclear from the docs whether it does branching. Said to be suitable for small-to-medium projects, in being simple and easy to understand. Code is Java. Open source (GNU GPL and LGPL).

[url=http://www.sourceoffsite.com/SourceOffSite] Classic/url ([url=http://linuxmafia.com/faq/Apps/vcs.html#sourceoffsitelink[/url]) SourceOffSite Classic is a networked tool for users of various operating systems to remotely use Microsoft Visual SourceSafe repositories. Linux client works on Linux 2.2.x kernels. Binary-only. Proprietary.

[url=http://www.borland.com/starteam/StarTeam[/url]] (Borland Software Corporation, formerly Starbase Corporation) ([url=http://linuxmafia.com/faq/Apps/vcs.html#starteamlink[/url]) StarTeam is a networked VCS with support for various MS-Windows IDEs via the Microsoft Source Code Control (SCC) application interface, and integrated defect tracking and threaded discussions. There's a Java-based Linux client piece. Code is Java bytecode. Proprietary.

[url=http://archive.eclipse.org/technology/archives/stellation-project.tar.gzStellation[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#stellationlink[/url]) Stellation is an extensible system with project-oriented versioning and lightweight branching, which back-ends into common relational databases, such as PostgreSQL, Oracle, Firebird, and DB2 (with MySQL support in progress). It runs either standalone, or with an Eclipse plugin allowing it to be integrated into the Eclipse IDE. It fixes typical [url=http://linuxmafia.com/faq/Apps/vcs.html#cvsCVS[/url]] problems, e.g., it handles moves and renames correctly, registers changes affecting multiple files as an atomic changeset, and maintains full project history through merges without manual measures. Code is Java. Open source (Common Public Licence).

[img]http://linuxmafia.com/faq/Apps/note.png/img] url=http://subversion.tigris.org/] Subversion/url][ ([url=http://linuxmafia.com/faq/Apps/vcs.html#svnlink[/url]) Subversion (aka SVN; executable name "svn") is specifically designed as a [url=http://linuxmafia.com/faq/Apps/vcs.html#cvsCVS[/url]] replacement (developed starting 2000), fixing all of the long-known design flaws in CVS: It adds versioning of directories, intelligent handling of binary files, and handling of all file metadata including symlinks (missing: to be fixed post-1.0). Revision numbering is per-commit instead of per-file. Atomic commits. Supports file/directory copies that retain version history. The repository stores snapshots of works, not changesets (deltas). As with CVS, Subversion follows a centralised development model; this is not a distributed, decentralised VCS, though the [url=http://linuxmafia.com/faq/Apps/vcs.html#svkSVK[/url]] extensions adapt Subversion to create one. Designed-in network operations are over either WebDAV, or a lightweight custom protocol called svnserve, which runs on port 3690 and can be anonymous or authenticated by a svnserve-specific password file. Alternatively, svnserve can provide authentication through SSH. No history-sensitive merging (no merge history tracking) as in [url=http://linuxmafia.com/faq/Apps/vcs.html#gnuarch%22GNU] Arch/tla[/url]: Trying to reapply a patch more than once can cause problems. Uses rename history instead of file-IDs to determine file identity. Existing project history can be revised, but only through special mechanisms. Original Subversion repository design used the BerkeleyDB database as a back-end store; in more recent versions, you can optionally use a filesystem/flatfile-based "fsfs" store if you prefer. Despite ubiquitous claims to the contrary from its proponents and from the program's official features list, it has turned out (2005) that Subversion [url=http://www.livejournal.com/users/bramcohen/4563.html?thread=33747#t33747cannot] handle file renames[/url]: Renames are implemented as deletion of the old file and separate copy to a new file, with the result that the file's version history gets broken. As Codeville's Bram Cohen points out, this "is even worse behavior than CVS has". David A. Wheeler's 2004-03 [url=http://www.dwheeler.com/essays/scm.htmlSCM] essay[/url] enumerates Subversion's virtues and limitations. Ariejan de Vroom maintains a useful [url=http://ariejan.net/svncheatsheet/SVN] cheat sheet[/url]. Code is C, with a fairly lengthy dependency tree. Open source (Apache Software Licence v. 1.1).

[url=http://www.superversion.org/Superversion[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#superversionlink[/url]) Superversion is Stefan Reich's networked, distributed, changeset-based VCS. Atomic commits. No rename support. Server access is mediated by Java RMI. GUIfied for all operations. Code is Java: Program functions anywhere that Java does. Open source (GNU GPL).

[url=http://www.seapine.com/surroundscm.htmlSurround] SCM/url ([url=http://linuxmafia.com/faq/Apps/vcs.html#surroundlink[/url]) Surround SCM is a multi-platform, networked VCS. Flexible branching model, with support for private branches. Integrates with sundry IDE front-ends using Microsoft's SCC application interface. Licences are US $600/user with quantity discounts. Binary-only. Proprietary.

[url=http://svk.elixus.org/SVK[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#svklink[/url]) SVK is a Perl-based, networked, (mostly) decentralised/disconnected VCS released by Chia-liang Kao in Sept. 2003, using the [url=http://linuxmafia.com/faq/Apps/vcs.html#svnSubversion[/url]] back-end storage repository but also adding distributed branches, lightweight checkout copy management, and more-advanced merging algorithms. Near future plans include cryptographic signing and verification of changesets, graphical merge manager, transparent VCP integration of alien-type VCS repositories ([url=http://linuxmafia.com/faq/Apps/vcs.html#cvsCVS[/url]], etc.) As of v. 8.08, 2004-02, SVK was described as being in "working prototype" stage; users are cautioned that all things are subject to change. As of 2005-04, it was still said to be a bit flaky, probably in part because the composite SVK/SVN system is fairly "heavyweight" (a tall software stack). Little documentation. Control files are [i] not stored inside the working directory tree, similar to with [url=http://linuxmafia.com/faq/Apps/vcs.html#perforcePerforce[/url]]. Requires CGI on server end. Fast. Good integration with external merge tools. Code is Perl script. Open source (Perl Artistic Licence).

[url=http://www.telelogic.com/Synergy/CM[/url]] (Telelogic AB) ([url=http://linuxmafia.com/faq/Apps/vcs.html#synergylink[/url]) Telelogic Synergy/CM, (formerly CM Synergy, formerly Continuus/CM) appears to be a networked client-server system that back-ends into an SQL database (not included) and includes workgroup-management features. Atomic commits. Supports renames. Supports file/directory copies that retain version history. Telelogic (which acquired Continuus Software Corp., formerly CaseWare, Inc., formerly Amplify Control) is coy about pricing, but, in 2000-05, CM Synergy was US $25,000 for 10 users. Binary-only. Proprietary.

[url=http://www.mccabe.com/truechange.phpTrueChange[/url]] (McCabe & Associates) ([url=http://linuxmafia.com/faq/Apps/vcs.html#truechangelink[/url]) TrueChange is some sort of changeset-based VCS. Web site is vague: It seems respected, if obscure, and was formerly known as Aide-de-Camp. McCabe is very coy about pricing. Binary-only. Proprietary.

[url=http://www.georgejames.com/VC/m[/url]] (George James Software) ([url=http://linuxmafia.com/faq/Apps/vcs.html#vcmlink[/url]) VC/m appears to be a local-oriented (non-network-aware) VCS with process control. Most operations can be optionally performed from a Web browser. Binary-only. Proprietary.

[url=http://www.vestasys.org/Vesta[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#vestalink[/url]) Vesta is a fairly robust configuration-control and software-building system developed by/for the Digital Equipment Corp. Alpha processor team, but does not yet include tools to implement merges. Atomic commits. Renames are supported: The unit of checkout/checkin is a directory tree. Files and directories can be added, deleted, and renamed between versions. Supports file/directory copies that retain version history: A new package/branch can be based on any existing version without affecting the past history. David A. Wheeler's 2004-03 [url=http://www.dwheeler.com/essays/scm.htmlSCM] essay[/url] includes a brief rundown on Vesta. Code is C++. Open source (GNU LGPL).

More tools can be found at [url=http://www.faqs.org/faqs/by-newsgroup/comp/comp.software.config-mgmt.htmlurl] http://www.faqs.org/faqs/by-newsgroup/comp/comp.software.config-mgmt.html[/url/url][] (comp.software.config-mgmt FAQ). I've attempted to include all options listed there that have a Linux presence. Ross Cohen maintains the [url=http://revctrl.org/RevctrlWiki[/url]], linking to the related [url=http://lists.zooko.com/mailman/listinfo/revctrlRevctrl] mailinglist[/url] administered by Zooko (Bryce Wilson) and logs of the #revctrlIRC channel on freenode.net, all of which are the leading forums for discussion among developers of advanced open-source VCSes. [url=http://planet.revisioncontrol.net/RCS] Planet[/url] tracks the weblogs of VCS developers. [url=http://versioncontrolblog.com/Version] Control Blog[/url] houses Alexey Makhotkin's writings on the subject. Further VCS information may be findable at the [url=http://dmoz.org/Computers/Software/Configuration_Management/Tools/Open] Directory CM category[/url], [url=http://better-scm.berlios.de/Better] SCM Initiative[/url], including a [url=http://better-scm.berlios.de/comparison/comparison.htmlcomparison] page[/url], Zooko's (Bryce Wilson's) [url=http://zooko.com/revision_control_quick_ref.htmlquick-reference] comparison chart[/url], [url=http://www.cmcrossroads.com/CM] Crossroads[/url], [url=http://www.paper-review.com/tools/tdb/home.phpINCOSE[/url]], Oy Laatukonsultointi P. Kantelinen Ab's [url=http://www.laatuk.com/tools/SCM_tools.htmlSCM] Tools page[/url], [url=http://www.ovum.com/Ovum], Ltd.[/url], or the [url=news://comp.software.config-mgmt] comp.software.config-mgmt[/url] newsgroup. See also David Wheeler's perceptive [url=http://www.dwheeler.com/essays/scm.htmlComments] on OSS/FSSoftware Configuration Management (SCM) Systems/url, Kevin Smith's blog's [url=http://web.archive.org/web/20061206073756/http://blog.fxa.org/articles/category/scmSCM] category[/url],and Bram Cohen's blog's SCM items ([url=http://www.livejournal.com/users/bramcohen/17319.html1[/url]], [url=http://www.livejournal.com/users/bramcohen/17925.html2[/url) and] the OpenSolaris project's [url=http://www.opensolaris.org/os/community/tools/scm/comparativeSCM] evaluations[/url]. Also extremely worth reading is Martin Pool's [url=http://sourcefrog.net/weblog/software/vc/derivatives.htmlessay[/url]], in which he compares and contrasts VCSes that capture snapshots (Subversion, CVS) with those that capture changesets (GNU Arch, darcs), and explains why the latter win as projects become more complex.

[url=http://jrms.sourceforge.net/JRMS[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#jrcslink[/url]) Java Revision Control System was a project for a lightweight Java non-changeset-oriented VCS that was to run over Java RMI (remote method invocation), abandoned by its author while still in late planning stages when he discovered [url=http://linuxmafia.com/faq/Apps/vcs.html#svnSubversion[/url]]. Code is Java. Open source (GNU GPL).

[url=http://www.netcraft.com.au/geoffrey/katie/Katie[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#katielink[/url]) Katie (defunct) was a local-oriented (non-network-aware) system, where the repository is mounted as a filesystem, as with [url=http://linuxmafia.com/faq/Apps/vcs.html#clearcaseClearCase[/url]]. Abandoned in pre-alpha state. Code is Perl script. Open source (GNU GPL).

[url=http://regexps.srparish.net/src/larch/Larch[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#larchlink[/url]) Larch (now defunct) was Tom Lord's initial "functional prototype" implementation of the fully decentralised, networked [url=http://linuxmafia.com/faq/Apps/vcs.html#archArch] VCS specification[/url]. It was initially named "arch", but was then renamed to Larch because of a naming conflict. (/bin/arch on a POSIX system returns its machine architecture type.) Larch's reliance on shell scripts caused it to be often pronounced less portable than alternatives. Could function over ftp, sftp, WebDAV, and plain http transport. Replaced by C-based [url=http://linuxmafia.com/faq/Apps/gnuarchGNU] Arch/tla[/url] and numerous competitors inspired in part by Larch's drawbacks. Code is shell scripts. Open source (GNU GPL).

[img]http://linuxmafia.com/faq/Apps/note.png/img] url=http://www.selenic.com/mercurial/] Mercurial/url][ ([url=http://linuxmafia.com/faq/Apps/vcs.html#hglink[/url]) Mercurial (executable name "hg"), by Matt Mackall, is a distributed VCS inspired by certain of[url=http://linuxmafia.com/faq/Apps/vcs.html#monotoneMonotone's[/url]] design elements, and said to be similar insome ways to [url=http://linuxmafia.com/faq/Apps/vcs.html#gitgit[/url/Cogito], but storing changes instead of whole files, saving storage and making some functions related to file history easier to perform. Very compressed storage, as a result. Note: Mercurial stores only oneproject per repository, but allows multiple branches within a repository.Control files are stored inside the working directory tree. Uses SHA-1 hashes of changesets for integrity-checking, supportsfully decentralised operation and arbitrary merging. Merging keeps allmetadata on each changeset (committer, message, etc.). Everything is abranch. Provides command-line and Web interfaces. Uses http and ssh asnetwork transport. Can also use e-mail as transport ("hg export" to exportchangesets, mail the changesets, then "hg import"). Changeset numbers are referred to by sequential numbers. "hg serve" starts a built-in Web server, and serves up the branch for "pull" access. Renames, deletes, and permissions are versioned, but rename isimplemented as copy and delete. (Fortunately, a file created with thesame path as one deleted inherits the old file's history.) No supportfor partial trees. Per-file history is available by specifying the filename with "hg log". No direct support for "cherry-picking": However, anequivalent can be achieved by exporting specific patches from one repo(branch), and importing them into another repo. Repositories are normally fully independent, but can beconfigured to have a [url=http://www.opensolaris.org/jive/message.jspa?messageID=30643&tstart=0defacto] parent[/url]. Network access is supported via SSH, http (in "pull"mode) and of course network filesystems. There is no built-in facilityfor controlling access (via ACLs) to subtrees. Repository internal storageformat is binary (hence, fast) but platform-neutral. Offering repo access via plain http ("pull") access from commodity Web servers (a very desirable feature) is complicated (2005-09) by the fact that the "[url=http://www.selenic.com/pipermail/mercurial/2005-September/004658.htmlpreferred] method[/url]" for publishing such a repo requires uploaders to continually first create "bundles" to hold the contents, and for downloaders to know that things are bundled, and (apparently) even to know what the bundles are named. Mercurial was one of three VCSes seriously considered([url=http://www.opensolaris.org/os/community/tools/scm/mercurial-eval.html1[/url,[url=http://www.opensolaris.org/os/community/tools/scm/dcm_evaluation_mercurial2[/url) for] hosting the very large OpenSolaris Project, and was the final winnerover git and Bazaar. Sebastien Pierre maintains a useful[url=http://www.ivy.fr/mercurial/ref/v1.0/Mercurial] cheat sheet[/url]. Code is a small Python script, and is fullycross-platform. Open source (GNU GPL).

[url=http://users.footprints.net/%7Ekaz/mcvs.htmlMeta-CVS[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#metacvslink[/url]) Meta-CVS (now defunct), by Kaz Kylheku, is an ambitious attempt to update [url=http://linuxmafia.com/faq/Apps/vcs.html#cvsCVS[/url]] by embedding the standard CVS client in Lisp wrappers, which cause an enhanced data representation to be stored in the CVS repository. Adds directory versioning, renames/moves, support for symlinks and file metadata, simpler branching and merging, persistent memory of each file type being declared (and to be treated as) binary or text after it's been imported or added the first time. Commits are not atomic; the author's algorithm for atomic commits has been proposed but not yet adopted for both CVS and Meta-CVS. Code is Lisp. Open source (GNU GPL).

[img]http://linuxmafia.com/faq/Apps/note.png/img] url=http://www.venge.net/monotone/] Monotone/url][ ([url=http://linuxmafia.com/faq/Apps/vcs.html#monotonelink[/url]) Monotone (executable name "mtn") is Graydon Hoare's 2003 distributed (networked) VCS with a flat peer model, cryptographic (SHA-1) version naming and metadata certificates (SHA-1 identification of all files, directories and revisions), decentralized authority, atomic commits, versioned file and directory renames (unlike, say, [url=http://linuxmafia.com/faq/Apps/vcs.html#hgMercurial[/url]), and overlapping branches. Supports file/directory copies that retain version history. Distributed merging is implemented via 3-way merge. Tracks changesets (deltas). Identifies revisions using chained hashes, requiring only one signature to authenticate a line of development. Uses rename history instead of file-IDs to determine file identity. Monotone works out of a transactional version database stored in a regular file (using sqlite). Network communication is mediated via HTTP, netnews (NNTP), or SMTP transport. Code is C++ and Lua. Mechanisms such as cryptographic hashing are too exposed for many people's tastes. Nice graph tool. Good manual and Web pages. Project is now self-hosting, and while still being experimental now (2005-05) has a stable database schema and a reliable datastore.
Note: One of the reasons Linus Torvalds started the "[url=http://linuxmafia.com/faq/Apps/vcs.html#hggit[/url]" project is that he tried Monotone, and liked many of its aspects, but found it unacceptably slow at the time (but not as slow as [url=http://linuxmafia.com/faq/Apps/vcs.html#darcsdarcs[/url]). Monotone has gained performance considerably since that time, when the designer had not yet found and fixed a serious performance bug. It is reported (2005-08) that the "initial pull" initial repository clone still takes quite a long time, but that this is being worked on. (2008 update: That has now been addressed.) David A. Wheeler's 2004-03 [url=http://www.dwheeler.com/essays/scm.htmlSCM] essay[/url] includes a brief rundown on Monotone. Tool works on Unixes including MacOS X, plus Win32. Beta as of 2005-04.
Code is Lua and C. Open source (GNU GPL).

[url=http://www.opencm.org/OpenCM[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#opencmlink[/url]) OpenCM (now defunct), by Jonathan Shapiro, was another intended [url=http://linuxmafia.com/faq/Apps/vcs.html#cvsCVS[/url-replacement], supporting renames, access control on branches, cryptographic authentication (SHA-1 hashes), atomic commits, end-to-end integrity controls, and file-level ACLs. Directories are inferred by having files that exist under them; empty directories are a special case with an object of type DIR. It was still in early development when the project (apparently) stalled a/o 2004-10-24. Code is C. Open source (2-clause BSD licence with some GNU GPL; aiming to move to Common Public Licence).

[url=http://www.ouraysoftware.com/OurayCM[/url]] (Ouray Software L.L.C.) ([url=http://linuxmafia.com/faq/Apps/vcs.html#ouraycmlink[/url]) OurayCM is a networked VCS supporting renames, branching including per-user branching with automatic merge tracking, built-in cache servers, tools to assist conflict resolution, and atomic commit operations. GUI and command-line tools are provided for the various platforms. The release-tagging feature is called "vrefs". Binary-only. Proprietary.

[url=http://www.perforce.com/perforce/price.htmlPerforce[/url]] (Perforce Software, Inc.) ([url=http://linuxmafia.com/faq/Apps/vcs.html#perforcelink[/url]) Perforce is a networked VCS with emphasis on high performance, using [url=http://linuxmafia.com/faq/Apps/vcs.html#rcsRCS[/url]] files plus a database. Supports versioning of most objects (but notably not directories), change control, shared access, atomic commits, branching/merging, and auditing for software production teams. Renames not directly supported: you copy and then delete but it manages to keep track of the branch. Supports file/directory copies that retain version history. Costs US $750 for a single licence. Quantity discounts, and gratis licences to open-source developers upon request. Binary-only. Proprietary.

[url=http://prcs.sourceforge.net/PRCS[/url]] ([url=http://linuxmafia.com/faq/Apps/vcs.html#prcslink[/url]) PRCS (now defunct) was a promising project (particularly the 2.x development branch) that had been progressing slowly; source code tree is in anoncvs.gnome.org . Unfortunately, there has been no sign of progress towards release since 2001. It handled files and directories as an entity, preserving coherent versions of the entire set. Had named branches, custom keyword replacement. Best-parent three-way merge algorithm. Users were allowed to edit the manifest file, which also contains some system-maintained data. No network support; no Win32 or Mac support. Code was C++. Open source (GNU GPL).

[url=http://www.synergex.com/solutions/pvcs/PVCS[/url]] (Synergex International Corp., under licence from Merant, Inc.) ([url=http://linuxmafia.com/faq/Apps/vcs.html#pvcslink[/url]) PVCS is a local-oriented (non-network-aware) VCS and build-control system with client software for just about all OSes. Merant, which wrote the code, was formed by the merger of MicroFocus and Intersolv. Binary-only. Proprietary.

darcs also suffers from impenetrable, poorly designed error messages and diagnostics. Each repository can only hold a single branch of a single project: To create a new branch, you must create an entirely new repository.

As of 2005-08, darcs's development branch is now alternatively able to work with git repositories.

David A. Wheeler's 2004-03 SCM essay includes a brief description, and some thoughtful analysis, on darcs.

Trent Buck published a comparison of darcs and Bazaar (bzr) and some comments on darcs kludges in 2006.

Code is Haskell. Open source (GNU GPL).

DCVS (Distributed Concurrent Versions System) (elego Software Solutions GmbH) (link)

DCVS extends the CVS model, adding support for distributed repositories and local lines of development, using a variant of John D. Polstra's file distribution and synchronization program CVSup.

Code is C. Open source (GNU GPL).

Discipline 4GL (Saint Mavris Technology) (link)

Discipline 4GL is a networked VCS, software-development, build control, and release-control tool. Saint Mavris Technology is coy about pricing.

Binary-only. Proprietary.

Eva (link)

Eva (now defunct) was Federico Di Gregorio's compatible Python implementation of the decentralised, networked Arch VCS specification — inspired in part by the need to transcend technical and portability limitations in Tom Lord's then-current shell-script-based implementation, Larch. The project appears to have stalled as of Di Gregorio's 2003-04-13 snapshot code.

Code is Python script. Open source (GNU GPL).

FastCST (link)

FastCST (Fast Change Set Tool) is Zed Shaw's experimental, distributed, networked VCS, [re-] coded in Ruby, from Shaw's C original. (The Ruby version still lacks the original's revision control and encryption features, as of 2005-04.) Supports sending and receiving changesets via POP3 + SMTP; also works over http, http+ftp, or a built-in "serve" command (http access on port 3040). Merge command is (a/o 2005-04) only partially working: Basic merge is implemented, but without conflict resolution.

Code is Ruby. Open source (GNU GPL).

[notable] git and related "porcelains": (link)

*

"git", sometimes said to be short for "global information tracker", is an extremely fast (especially for its 3-way patch merges performed using GNU diffutils's "diff3" utility — which, however, is relatively unsophisticated compared to other modern VCSes' merge algorithms) object-addressable file-versioning/storage system developed with astonishing speed by Linus Torvalds with help from other Linux kernel developers starting 2005-04 as their primary source-management tool, after their licence to use BitKeeper was revoked. Starting with the 2005-07 1.0 release, git has been managed by Junio C. Hamano.

Like many recent VCS engines, git tracks/references checked-in entities by their SHA-1 cryptographic hashes, storing large dataset snapshots (full data collections rather than diffs) concerning several such "entities" for each file checked in (in a pseudo-filesystem, complete with its own fsck utility), thus gaining speed at some cost in disk space consumed. There is an optional space-efficient (but rather kludgey and allegedly fragile), "packed" format that saves spaced and network bandwidth by delta-fying file revisions (i.e., transforming them into a changeset format) where possible, that can be used with its "repack" command.

Commits are not signed; however, tags are. Also, Torvalds simplified the problem domain by deciding to have git not handle file renames/moves at all, nor some metadata such as time stamps. (Torvalds feels these are non-essential, believing for example that renaming foo to bar should be treated as destroying foo and creating bar, and that tracking the movement of content between files, which it is intended to do eventually, is more important than filenames, which are just transitory labels.) There is also no explicit file "history" as such. Project history is stored as a directed acyclic graph, making long-lived branches and repeated merging simple. (Delete file, commit, create new file with the same name, commit, is a supported sequence of operations. After the file is re-created and committed in the final step, it inherits the history of the original file.)

Permissions and ownership appear not to be versioned; only the execute bit is archived and preserved, of that class of metadata.

Binaries are of course versioned. Partial trees and per-file histories are not supported (though the git core commands will extract the revisions that affected this file when asked for the history of a file).

As with other decentralised VCSes, each git checkout is a full-fledged repository with full revision tracking capabilities. Synchronization between repositories is done via explicit push/pull operations. Location of the metadata/history information can be specified using environment variable GIT_DIR, thus allowing you to use less space in your working files area, have less cruft there, keep your version history on archival media, etc.

Networked access is supported, with SSH support built in, and no dedicated server component. The presence of GNU RCS is helpful for merge operations but not required.

There is a separate tool git-update-index, that for some operations, e.g., add, but not others, e.g., mv, is required to update repository state for a file in the repository (before a commit). There is an "fsck" command to recover corrupted repositories.

Jeff Garzik has written a git HOWTO; an earlier tutorial is provided with the source code's Documentation tree. Don Marti recommended in April 2008 some good tutorials, plus Zack Rusin has created a git cheat sheet.

git v. 1.2.2 through 1.2.4 was one of three VCSes seriously considered (1, 2) for hosting the very large OpenSolaris Project, and was eliminated on grounds of a half-dozen operational disadvantages and design flaws compared to (the winner) Mercurial.

Code is C, and depends on zlib, libcurl, and OpenSSL's libcrypto to build, and rsync 2.6.0 or later to run. It thus appears to use rsync for network transport. Open source (GNU GPL). *

Cogito (formerly git-pasky) is Petr "Pasky" Baudis's set of higher-level VCS services (a UI wrapper aka "porcelain") designed to complement the git engine, comprising an arguably complete VCS. Note: Cogito stores only one project per repository, but allows multiple branches within a repository.

Cogito appears to use rsync, http, and ssh as network transports. It is written in bash shell script and thus is not portable to non-Unix systems, notably MS-Windows (absent Unix-ey retrofits such as Cygwin). Open source (GNU GPL).

The git/Cogito combination evolved rapidly during its first six months and achieved strong acceptance, but since 2006 has been officially deprecated, replaced by improvements in the git tool's own native user interface. As of 2007, the redoubtable Ted T'so recommends pure git 1.5.x, as less confusing than git + Cogito. *

"gitweb" is a simple, one-file CGI/perl Web interface (a UI wrapper aka "porcelain") to track (view) changes in git repositories, written by Kay Sievers and Christian Gierke.

Code is Perl script. Open source (GNU GPL.) *

"gitk" is Paul Mackerras's Tcl/tk graphical front-end viewer for git (a UI wrapper aka "porcelain"), providing a three-paned window showing a reverse-time list of committed patches, a graphical trace showing which tree each patch was merged from, tags, the selected patch and commit text, and a list of files that will be touched by the selected patch. It does not aspire to provide a full VCS superstructure similar to Cogito.

Patches can be searched by description, author, or SHA-1 tag, with regular expression support.

Code is Tcl script. Open source (GNU GPL). *

"qgit" is Marco Costalba's Qt-based graphical front-end viewer for git (a UI wrapper aka "porcelain"), showing a commit text and a patch list (one patch per line, with annotations, making it easy to figure out which commit modified a specific piece of code). It does not aspire to provide a full VCS superstructure similar to Cogito.

Double-clicking lines in the patch list bring up patches in "diff -up" format, in a separate window. There is a search/filter feature.

Code is C++. Open source (GNU GPL). *

"gct" (Git Commit Tool) is Fredrik Kuivinen's GUI-enabled git commit tool (a UI wrapper aka "porcelain"), using the Qt graphics toolkit, permitting the user to select which files should be committed, write commit messages, and perform the commit. It also has some support for controlling the synchronisation between the git cache and the working directory.

Code is Python. Open source (GNU GPL). *

"StGIT" (Stacked GIT) is Catalin Marinas's Python-based patch pusher/popper for git (thus facilitating "cherry-picking"), only: It does not aspire to provide a full VCS superstructure similar to Cogito.

Quoting the author: "The idea of StGIT is to keep a set of patches (tens usually) always on top of the main repository you are tracking until they get merged into it. At that point, the StGIT patch would become empty and can be safely removed. StGIT is not intended to be used as an VCS where you can create thousands of patches. You expect the patches to be merged upstream and removed from the stack. It closely follows the Quilt philosophy."

Code is Python script. Open source (GNU GPL). *

"JIT" (unmaintained, deprecated!) was Junio C. Hamano's VCS layer built on top of git, supporting a workflow based on manipulating patches. Its snapshot mechanism, rewind, patch, and ipatch commands are intended to help "individual developer" users (as opposed to "project lead" ones) first develop a working version in a random order, and then refactor the working version into a clean sequence of changes to be fed upstream. Deliberately does not support per-file commits, on grounds of that being bad workflow: Developers are helped to work with snapshots and patches, instead. (Snapshots are local commits within the work tree, implemented as git commit objects, and are encouraged.)

Code is shell scripts and C — but the codebase is unmaintained, has not kept up with git's development, and is deprecated by its author. Licence unstated.

GNU Arch 1.x ("tla") (link)

GNU Arch 1.x (executable name "tla", for Tom Lord's Arch) is Tom Lord's second (compatible) implementation, this time in C, of his decentralised, networked Arch VCS specification. It is now (2006) maintained by Andy Tai. Very complex, arguably overfeatured system. Does star-merge. Patches from others can be collapsed/rolled up upon integration so as to lose their separate identities. Atomic commits. Supports renames. Commits are gnupg-signed. Parseable/scriptable shell interface; uses tar, gzip, and patch. Changelogs are autogenerated. Uses weird, often problematic filenames featuring (e.g.) leading "++", ",,", "=", and "{ ... }" sequences. Uses inode signatures to detect file modifications, leading to some false alarms, e.g., when copying a tree. Uses MD5 hashing (insecure) for archive verification; will eventually move to SHA-1: Only patches (not complete revisions) are signed. Uses sequence, rather than time, to determine precedence of changes. Can use ftp, sftp, WebDAV, and plain http transport. Relies on ssh for remote access, authentication, and confidentiality. Changesets can be also conveyed via e-mail. A dedicated arch-server component isn't really needed, but has been prototyped, or alternatively one could use Colin Walters's Python-based archd software and matching protocol (using TCP port 2420).

Interested parties will find Nick Moffitt's concise and focussed "Arch for CVS Users" tutorial an excellent place to start.

David A. Wheeler's SCM essay points out some of GNU Arch's current (2004-03) problems: (1) The Win32 port is currently missing quite a few features (symlinks, most file permissions, correct handling of newlines), and in general GNU Arch may never be fully functional on non-POSIX systems. (2) The repository's file-naming conventions use very badly chosen special characters that tend to break vi, more, the C shell, various scripting languages, and other primary tools. (3) Automated cache management is missing (making the program slow by default), and is badly needed. (4) Merging breaks if branches aren't either all commit-based or all tag-based, but the tool doesn't enforce that limitation. (5) "mv" and "move" do very different things, and in general the full command set is needlessly complex.

Wheeler considered almost all of these to be short-term problems.

Lord had released, working entirely by himself, three development betas of a GNU Arch 2.0 redesign (executable name "revc") incorporating ideas from Bazaar ("bzr"), git, and Monotone, including a belated switch from MD5 to SHA-1 checksums. However, my guess is that the 2.0 effort (at minimum) is now (2005-08) defunct. The GNU Project adopted tla as "GNU Arch" in 2003-07.

Code is C. Open source (GNU GPL).

Maintainer's personal note: In my opinion, GNU Arch's implementation flaws are sufficiently grievous that people considering its use should hasten to substitute Canonical's compatible replacement, Bazaar ("bzr"), in its place.

It appears that I'm not alone in this perception: As of 2005-08-15, Tom Lord announced that he was resigning effective immediately as GNU Arch maintainer, endorsed Bazaar 1.x ("baz") as an immediate direct replacement, and expressed hope that Bazaar ("bzr") will eventually take its place, in turn. The main GNU Arch developers other than Lord had already left that project, by that point, and had become Bazaar 1.x coders.

2005-10 update: Developer Andy Tai has taken over the GNU Arch project lead, and it has resumed.

Bitsafe (Bitmanager-Media GmbH) (link)

Bitsafe is a networked VCS coded in Java (JRE/JDK in version 1.4.2 or later required) and back-ended into either Oracle RDBMS or SAP-DB for its repository.

Code is Java bytecode. Proprietary.

/BriefCase 3 Toolkit (Applied Computer Sciences, Inc.) (link)

/BriefCase 3 Toolkit is ACSi's enhanced networked variant on RCS wrapped inside a comprehensive development, release, and lifecycle toolkit. Network access is via rsh transport for coordination of client and server-side scripts, and NFS & pipes for data transport. NFS support has a well-developed locking structure. Administrative and private user tag mechanisms are provided. Client-side work areas can have multiple local replicas, to work on different releases and/or aspects of a project. Import tools are provided for SCCS, CVS, RCS and PVCS data.

Code is Korn shell and awk scripts. Open source (GNU GPL).

CBE (link)

CBE (Code Building Environment) is Thomas Neumann's VCS coded in pure Java with integrated software build functions. Functionality is roughly similar to that of CVS with some new features like renaming files (while still keeping the history) and using a database as backend (optional). Code is said to be alpha-stage (2005-04).

Code is Java. Open source (GNU GPL).

ChangeMan DS (Serena Software, Inc.) (link)

ChangeMan DS is a networked VCS integrated with build control, release management, a programmers' editor, software-distribution tools, and process control. It also integrates with SAP for packaged application management, and with various third-party IDEs. Serena Software is coy about pricing.

The product was formerly known as ChangeMan and before that as Diamond CM — because it was written by Diamond Optimum Systems, which was acquired by Serena Software. (Even earlier, during its origins as an HP-3000 / HP/UX tool, it was called VCS-UX.)

Binary-only. Proprietary.

ClearCase (IBM / Rational Software, Inc.) (link)

ClearCase is a networked VCS whose repository one accesses using a quasi-filesystem of its own design, with integration to external software-build tools and adding some of its own. Supports advanced 3-way merge, versioning of any object (including directories), parallel builds distributed over a network, and triggers for local site customising. Linux usage requires loading a proprietary kernel module, said to freeze up frequently (at least that was true around 2001, not confirmed recently), and compatible only with particular kernels: See the ClearCase Linux Installation Guide Whitepaper for compatibility details.

They're extremely coy about pricing; probably you have to haggle on site-wide terms with their sales team. One claim is that ClearCase licenses tend to cost around US $5000/seat plus 20% per year for support.

ClearCase's history goes back to 1984, when a team at Apollo Computer created DSEE (Domain Software Engineering Environment), a VCS/build system. At the time of HP's purchase of Apollo, they left and formed Atria Software, which then merged with Pure Software, to form PureAtria, which was then bought by Rational Software. In 2002-12, Rational Software was bought by IBM Corp.

Binary-only. Proprietary.

CM+ (Neuma Technology, Inc.) (link)

CM+ integrates networked VCS with process control, build control, configuration management, product management, document management, problem tracking, activity tracking, requirements tracking, and release control. Neuma Technology is coy about pricing.

Binary-only. Proprietary.

CMZ (CodeME S.A.R.L.) (link)

CMZ is a local-oriented (non-network-aware) system, supporting a wide range of VCS, coding, editing, and library-management functions. Linux binary is PPC-only (no x86).

Binary-only. Gratis non-commercial usage. Proprietary.

[notable] Codeville (link)

Codeville (executable name "cdv") is Bram and Ross Cohen's fully decentralised (networked) VCS with some advanced merge methods, based on line identity: two-way merge with history. (It allows you to update from or commit to any repository at any time, with no unnecessary re-merges. Supports offline commits: Supports a workflow model where the repository is centralized, but the working tree is used as a branch.)

Repository is stored in a binary BerkeleyDB database. History is stored in the form of changes from old hashed versions. Support for non-ASCII files and some metadata (e.g., execute bit) are still (2005-08) pending. SRP as authentication protocol, network access via (if I understand correctly) custom, built-in network transport to the "cdvserver" piece on TCP port 6601. File and directory renaming are supported. Code is now (2005-08) solid, with a small to-do list remaining. Still has nearly nil built-in documentation, and only a little more on the project Web site. Very well-designed but very unusual merge algorithm (aforementioned two-way merge with history).

Code is Python script (Python 2.3 and up, BerkeleyDB 4.1 and up). Open source (newer BSD licence).

Control-CS (Network Concepts, Inc.) (link)

Control-CS is a networked version-management system. (Earlier version was called Control.) Linux has server-end tool only; client-end software exists only for Win32.

Binary-only. Proprietary.

cscvs (1, 2) (link)

cscvs (now defunct) was a networked, decentralised VCS coded in Python, using CVS as a back-end storage repository, imposing on top of CVS atomic changeset semantics (and with easy migration to arch).

Code is Python script. Open source (BSD-style licence).

CSSC (Free Software Foundation) (link)

CSSC (Compatibly Stupid Source Control) is a simple local-oriented (non-network-aware) reimplementation of the old SCCS (Source Code Control System) system from early Unix (pre-RCS), mostly used for access to old repositories (being not recommended for new data repositories), and (for a while but reportedly not any more), with minor modification, to BitKeeper repositories. Uses weave storage, which makes it an excellent foundation for building advanced VCSs, despite CSSC/SCCS's antiquity. Fast, small, lightweight. Versions files (no changesets). Doesn't handle binary files. Does locking, uses a centralised (local) repository. No merging. Confusing command-line interface.

Code is C. Open source (GNU GPL).

CVS (link)

CVS (Concurrent Versions System) is the ubiquitous old-school default, but has serious flaws: No moves/renames, inefficient with binaries, no versioning of directories, no merge-history tracking (must be done manually through tagging), no atomic commits or retrievals (i.e., no atomic tree-wide operations), interacts badly with backup software, tends to leave stale locks, doesn't deal well with symlinks/special files, often gets into merging snarls, branching is often problematic and requires scrupulous attention to tagging, changes are tracked per-file instead of per-change, development is stagnant. Tagging and branching are expensive operations. No integrity checking: Prone to repository corruption. Derived from script wrappers by Prof. Dick Grune of the Free University of Amsterdam around the local-only RCS system (written in 1984-5 and rewritten in C two years later by Brian Berliner), it added concurrency control, annotations, and other enhancements. History is stored separately from the working directory (in the central repository), and can contain many modules. Working copies are separate and contain one module each. Able to transact data across network connections since 1994, making CVS the first practical network-capable VCS. Existing project history can be revised, but only through special mechanisms. Syncing of repositories is possible using add-on software CVSup.

Code is C. Open source (GNU GPL).

Maintainer's note: If you still use this thing, for heaven's sake upgrade to Subversion, or at least CVSNT.

CVSNT (link)

CVSNT started out to be an NT-only variant of CVS, but is now fully portable. It adds merge tracking, SSPI authentication, and a built-in copy of the PuTTY SSH code. Has per-branch ACLs, remote user administration using "cvs passwd" commands, a separate LockServer instead of filesystem-based locks, Unicode support, more-efficient storage of binary diffs, atomic checkouts, better handling of merges without tagging requirements, additional server triggers, etc. However, it retains many of CVS's disadvantages, including poor handling of renames, etc.

Code is C. Open source (GNU GPL).

[notable] darcs (link)

DARCS (David's Advanced Revision Control System), more often called "darcs", is David Roundy's CVS-replacement VCS, written in Haskell, handling all metadata, supporting fully decentralised repositories and advanced branching / patch-handling: Distributed merge is implemented via patch commutation. History is stored with the working directory. (Control files are stored inside the working directory tree.) Atomic commits. Supports renames. Existing project history can be revised (which is potentially a drawback: Interlopers can change what the history says). Patches from others can retain their separate identity even after integration (are not collapsed/rolled up) — and darcs also has the so-far unique advantage of being able to track inter-patch dependencies, and thus is the canonical example (and, really, the pioneer) of the concept of "cherry-picking" of patches and groups thereof. Based on tracking changesets (deltas). Fully functional (but slower) Win32 port; also works on MacOS X. Attempts to do all work entirely in RAM. Simple to use; easy to learn. Mature tool with active user community. No crypto checksum on the tree; no crypto signatures except on the transport. Does not guarantee than any past revision can be reproduced. Can be extremely slow when resolving merge conflicts.

The Haskell language is a rather obscure functional language, known to but few, and additionally is reported to characteristically suffer unpredictable but sometimes severe performance problems. Because of the language's obscurity, there have been relatively few third-party contributions to the codebase.

Arch (link)

Arch is an advanced VCS specification with multiple, independent but compatible implementations, and several descendants/offshoots. Arch is widely considered more ambitious than Subversion, mainly on account of its support for decentralised repositories: In Arch, any branch or developer's private work area can be treated as a repository of its own, with a global name space for developers, repositories, and branches, which you then periodically merge with a central repository.

Please see also the individual entries for the several implementations and offshoots of this specification: ArX, Barch, Bazaar 1.x, Bazaar, Eva, GNU Arch/tla, Larch.

All the various Arch implementations used to be linked from Mat Kovach's Arch Wiki (formerly Michael Grubb's) — but recently (2005-04) the wiki seems to have dropped all but GNU Arch/tla and Bazaar 1.x.

[notable] ArX (link)

ArX is Walter Landry's (no longer data-compatible) 2003 C++ reimplementation of the decentralised, networked Arch VCS specification, originally inspired in part by dissatisfaction with poor portability and other problems in Tom Lord's original shell-script-based Larch implementation. As an Arch offshoot, ArX is based on tracking deltas (changesets). Archives, patches, and revisions are cryptographically signed using gnupg signatures and SHA-256 hashes. ArX can use ftp, ssh, sftp, http, and http w/WebDAV transport. Internationalised but not localised. Centralised development can be done via a patch queue. Program ports to MacOS X, and in an "embryonic" fashion (2005-01-23) to Win32 (via Cygwin). On Linux, note (large) dependency on gnome-vfs. Beta as of 2005-04. Possibly moribund (2008).

Code is C++. Open Source (GNU GPL).

Archipel (link)

A prototype distributed system coded on Python by "Sébastien". Repository is stored in a queryable RDF database. Extensible/modifiable using plug-in delta modules for different versioning models. Version information is stored as SHA-1 hashes.

It is unclear at this point (2005-04) whether this software is publicly available in any form, let alone open source.

Barch (link)

Barch (for "binary arch" — now defunct) was Robert Collins's (early) attempt at a compatible C++ implementation of the Arch VCS specification — inspired in part by the need to transcend technical and portability limitations in Tom Lord's then-current shell-script-based implementation, Larch. The project appears to have stalled as of Collins's 0.0.6-DEVEL code released on 2002-12-29. However, more recently, Collins created Bazaar 1.x (now defunct).

Code is C++. Open source (GNU GPL).

Bazaar 1.x (baz) (link)

Bazaar 1.x (executable name "baz") was Robert Collins's fork for Canonical, Ltd. of Tom Lord's GNU Arch ("tla") C-language implementation of the Arch VCS specification.

It aimed to combine the essential features of GNU Arch ("tla") with user interface improvements and Win32 support: Subversion-like diff, switch, import, export, and log commands. A single merge command allowed merging between arbitrary branches, daily builds, internationalisation, Python bindings, Win32 binaries and an MS-Windows GUI, an annotate/blame/praise command, comprehensive documentation, and UI simplification. History was stored separately from the working directory.

As of 2005-08, Canonical decided to de-emphasise work on Bazaar 1.x, put that codebase in maintenance mode, and concentrate on Bazaar ("bzr"), formerly Bazaar 2, as the true long-term successor for GNU Arch/tla. Then, some time during 2006, Bazaar 1.x was discontinued entirely.

Code is C. Open source (GNU GPL).

[notable] Bazaar (bzr) (link)

Bazaar (executable name "bzr"), initially called Bazaar-NG, later called Bazaar 2, is Martin Pool's networked, fully distributed, changeset-oriented variant implementation / offshoot, coded in Python for Canonical, Ltd., based on the Arch VCS specification.

It aims to combine the best feature of all the new VCSes (darcs, Subversion, GNU Arch/tla, Quilt, and BK/Pro) "into a single coherent and simple system", and has a simple CVS-like syntax for common operations like add, mv, diff, status, commit, log, merge, etc. Stores/checks SHA-1 hashes of all patches and hashes of the tree state in each revision. Hashes can optionally be signed. Stores changesets (deltas). Control files are stored inside the working directory tree. Changesets can be sent/received over e-mail, optionally gnupg-signed. Renames, deletions, binaries are versioned. Uses hashes for integrity checks, not for identity. Repository data are stored encoded in UTF-8. Partial trees and per-file histories are not supported.

Though there is no dedicated network server program module, there is built-in support for "pull" synchronisation over a variety of network mechanisms; by default, there is both "push" and "pull" support over sftp transport only, and sftp is supported only if you install the bzrtools extensions (plus Python modules paramiko and pyCrypto).

Bazaar is also the successor to the former Bazaar 1.x ("baz") project, and all baz repositories should by now (2006) have been converted.

Change history is append-only. Tool lets you "cherry-pick" changes from one branch to another. As a further advance on Bazaar 1.x, each checkout is fully usable as a repository. At this date (2005-04), bzr is not yet feature-complete. Modular design: library + command-line client, making feasible use via library call from any other client. All development takes place on branches, which are the highest-level grouping. Forking of branches is by intention frequent and has been made easy. Three-way merge algorithm. Allows merges within an arbitrary graph. History-sensitive merges allow safe repeated merges, merges across renames, and mutual merges between parallel lines. Checkouts default to the last archive you pulled from (as with darcs and BK/Pro).

Bazaar (v. 0.7) was one of three VCSes seriously considered for hosting the very large OpenSolaris Project, and was eliminated on grounds of slowness and high memory usage compared to git and (the winner) Mercurial.

Trent Buck published a comparison of darcs and Bazaar (bzr) in 2006.

Code is Python script: Tool should run anywhere that Python 2.4 and above runs (i.e., Unixes including MacOS X, Win32, etc.). Open source (GNU GPL).

[notable] BK/Pro, formerly BitKeeper (BitMover, Inc.) (link)

Networked, changeset-oriented system (executable name "bk"). Atomic commits. Supports renames. Supports file/directory copies that retain version history. Has some advanced merge methods, based on line identity. Uses time, rather than sequence, in some places. Repository, which uses weave storage, gets fully replicated onto each developer's system (multiple repositories / staging areas). History is stored with the working directory. Checked-out files must be marked before editing. Patches from others can retain their separate identity even after integration (are not collapsed/rolled up). Has default GUI. Emits lots of noise messages, and has lots of weird commands. Requires both per-file and per-changeset commands. Very space-efficient storage. Has fine-grained pre- and post-event triggers. Can remotely find status of a tree, e.g. parent, number of comitters, versioned files, extras, modified, etc. Binary-only in recent versions. Was used by the majority of core Linux kernel developers until 2005-04, although some declined for licensing and other reasons. See: analysis of architectural advantages over competitors.

*

Commercial version is either buy or lease: Lease is US $1000 to US $1750 annually per seat. Purchase is US $2800/seat to US $5800/seat. Pricing depends on quantity. One person who posted a BitMover price list was threatened ([url]http://yro.slashdot.org/comments.pl?sid=41614&cid=4396950/url][) with a copyright-violation lawsuit. Actual pricing may differ, and may depend on sales negotiations. BitMover CEO Larry McVoy has addressed BitKeeper pricing on the kernel mailing list.

As of 2004, the commercial version, and not just the gratis-usage version (below), likewise proved to be subject to gaining more restrictive conditions over time: Developers who are considered likely to assist in development of competing VCSes are, starting 2004, refused the right to buy a copy.

BitMover CEO Larry McVoy claimed in 2005-04 that his firm regards hosted projects' metadata, e.g., who did which changes and when (the projects' change history), as proprietary to BitMover, Inc., rather than being customer data.

It also recently (2005) came to light that BitMover has some undisclosed patents.

As of 2005-09, potential BitMover customers should be warned there are still ongoing reports of threatening letters sent to BK/Pro commercial licensees whose staff separately perform development work on open-source VCSes. (In the case linked to, the coder's employer claimed to infer in followup telephone conversation with McVoy a threat to not renew licences).

Proprietary. Binary-only. *

Gratis-usage version (discontinued a/o 2005-04): o

Was encumbered by mandatory "Open Logging" of your metadata (privacy loss) if used with multi-user access. o

Had a history of gaining more restrictive conditions over time. E.g.: The licence initially provided that, if the company's Open Logging servers ceased to function for 180 days, the software would convert to GPL, but that provision was later withdrawn. Source code access was also withdrawn. The non-compete clause was added. A provision was added (and later removed) to allow BitMover to terminate the licences of any individuals or groups whose usage is deemed to have cost BitMover over US $20,000 in support costs.

Consequently: (1) Publicly posted comments about BitKeeper were often outdated. (2) It was recommended to download the program and read its current licence agreement. (See slightly outdated licence analysis, mirror copy 1 2, for which BitMover threatened author Jack Moffitt with litigation. The reference to a mirror copy is necessary because BitMover successfully demanded suppression of Moffitt's own pages on the subject.) o

Was subject to mandatory upgrading, per the licence's requirement, when new versions come out. There are compelling technical reasons why BitMover required this. However, it should be noted that replacement versions often introduced new licensing containing novel restrictions, such as the no-compete clause. (The point was not to portray this as somehow sinister: It was to prevent people from assuming they could keep using older versions, if they didn't like newer ones' terms of use.) o

Was encumbered by non-compete clause, [url]http://lwn.net/Articles/12120/./url][ If you or your employer develops, produces, or [re] sells a "substantially similar" competing product, you may not use it, while a BitMover licensee and for a year's time thereafter. BitMover sometimes waived this restriction for particular users. BitMover had advised some Linux kernel developers that they may not use the gratis-usage version, given their work on other VCSes. (They would have been obliged to buy the commercial version. 2005 addendum: That option has reportedly also been closed, with appending of that same non-compete clause to the commercial version, as well.) o

Required in latter versions that the the hosted repositories' source code contents be available (on BitMover request) via the BitKeeper access protocol. o

Was announced to be end-of-lifed in a company press release of 2005-04-06. A later press release pegged the EOL date as 2005-07-01, on which all client copies will be remotely disabled. o

Proprietary. Binary-only.

Open-Source BitKeeper Client: o

Allows check-out of the head (latest) version of any codebase in a public BK/Pro (BitKeeper) repository. *

Access via third-party open-source tools to repository contents:

Andrew Tridgell's SourcePuller is an open source (GNU GPLv2) client and two subroutine libraries (libsp and libsccs) able to talk to BitKeeper servers (finally) with full access over the wire, using a (trivially easy) reverse-engineered implementation of the BitKeeper network-access protocols, to codebase metadata, e.g., who did which changes and when (the hosted codebases' change history). Tridgell independently developed SourcePuller to allow it (and potentially other VCSes using its library interfaces) to check out BitMover-hosted data and information in local BitKeeper repositories without the information lossage that occurs when using (e.g.) BitMover's BK-CVS gateways.

Access was for a while possible, until changes to BitKeeper's operation, using Andrea Arcangeli's openbkweb or Pavel Machek's BitBucket. The latter uses CSSC with the required patch to extract data from individual files. (Warning: openbkweb is an alphaware Python script implementing the BitKeeper HTTP access protocol, and may at any given time lag BitKeeper development too much to be functional. BitBucket is likewise pre-release, and BitMover's Larry McVoy claimed to me on 2003-11-04 that the patched CSSC no longer works on current BK/Pro / BitKeeper, though I don't have details.)

Note that McVoy threatened trademark litigation against Machek and his employer SUSE Linux AG over the fact that Machek's BitBucket Web page mentioned the BitKeeper name. Machek complied and removed replaced that name with "", but it should be noted that McVoy's demand exceeded the reach of trademark law and was toothless. (Disclaimer: I am not an attorney, and the above is not professional legal advice.)

[Maintainer's personal comment: The obvious comparison to BK/Pro is IBM / Rational's very high-priced ClearCase tool, which I've used in the software industry. Having tried BitKeeper for a bit, I found it technically superior in every way — and it's dramatically cheaper. (On the other hand, 2005 has seen the rise of the remarkable, fast, stable open-source VCS "Mercurial", which should certainly be considered strongly, having much the same strengths except paid technical handholding.)

This document's entry for BK/Pro / BitKeeper initially had several mis-statements of fact, unflattering to the company, that I'd picked up by repeating uncritically some Linux developers' on-line assertions. I regret those errors, and caution people to be skeptical of such claims.]

项目经理面试中常被问到的问题 以下是典型的项目管理面试中通常会问到的问题（期望的回答）：很多的问题的答案是主观的，面试官想知道你的观点是否和他们的及公司一致。问题的构成如下：

1. 项目管理软件工具知识
2. 编制项目计划的技术
3. 人员管理技能
4. 沟通技能
5. 原理体系知识（标准开发生命周期和项目管理）。 　　 项目管理软件工具知识 问题 1：工期和工作量之间的差异是什么？ 答案 1：工期是商业/日历上的天数，与人数和工作量无关。工作量是与日历天数无关的人的工作。例如： 一天的工作量对于一个一只花 50% 在时间在上面的人来说，他的工期就是两天。如果两个人全职工作，工期是 1 天，而工作量是两个工作日。

问题 2：怎样和为什么要在编制项目计划时考虑依赖关系？ 答案 2：根据使用的软件包，依赖关系可以通过将任务及其后续任务的标识符进行关联来表示。依赖关系说明了任务之间关联/并列的要求。依赖关系可以是指在另一个任务能开始之前有一个任务必须完成。例如，逻辑模型必须在物理模型前完成。但测试并不是要在所有编程工作完成之后才开始，如果没有完成的程序对线性测试没有影响。项目计划加入依赖关系，就能找出项目的关键路径并且能够确定它对项目工期的影响。

问题 3：你怎样将人的工作步调与计划结合？ 答案 3：根据组织使用的具体的工具，可以将资源拆成更小的资源/单位，或者可以将任务拆成更小的任务。

问题 4：你怎样将培训，假日和个人教育时间表结合起来？ 答案 4：每个产品都有标明不工作的天数的公司/全球的日历。每个产品都也有个人的资源日历标明个人不工作的时间。如果项目需要教育和培训，应该把它们象任务那样写在项目计划上。

问题 5：你怎样安排类似状态会议这样贯穿整个项目但只需要极少的时间和工作量的任务？ 答案 5：它的工期将和整个项目时间一样长，占工作量的百分比很小。被分配给任务的每个人花在该任务的时间占他时间的百分比极低。

问题 6：实况报告对计划的作用以及实况与最初预计的比较有何价值？ 答案 6：根据组织使用的特定的工具，每个工具都为实况报告中输入相互独立的要素/域信息。也可以将报表进行分类，来向团队成员和其他相关团体说明关键路径的变化或时间表的调整。这些报告对已实现工作评价和作为在计划下一个工程或阶段的输入有价值。另一个把估计和实况报告比较的有价值的用途是把范围变更对项目的影响记录下来。 　做项目计划的技能

问题 7：你为什么制定项目计划？ 答案 7：项目计划是实现成功的系统的路线图。它提供了一种手段来通知每个人希望他们做什么及何时完成。它帮助项目经理使管理层，商务用户和支持团体了解项目状态和调整特殊的资源。逐项列记的 “一览表” 协助对任何变动的影响进行迅速评估。当实况报告与计划联系起来后，项目计划为今后项目的任务划分和估算提供了有用的信息。

问题 8：你将怎样着手做项目的计划？ 答案 8：进程安排是一门艺术。根据已知有关业务目标的事实，公司一般标准，以及可以利用的过去的经验。可以从清楚地定义范围和目标开始。把项目的风险和制约做成文件。差的估计源于对业务知识和项目范围缺乏了解。可以从项目任务分解入手，例如先划分阶段，然后定义每个阶段的活动，再定义每个活动中的任务。识别和文档化里程碑和可交付产品。项目计划是当信息变得可以利用的时，不断细化的有生命文件。很好地记录进度的变化对项目经理，开发团队，支持团队，以及管理层，商业用户都有益处。

问题 9：你将怎样着手制定项目计划？ 答案 9：在适当的活动和阶段或其他的概括的标准说明下，输入确定的任务。将适当的可交付产品及里程碑和特定的任务联系起来。连接全部需要依赖关联的任务。把资源角色或资源名字加到每个任务上。应用度量结果确定事先的任务工作量，把更多的时间用于需求收集，设计和测试。考虑所有已知的节假日，培训，休假或其他的资源停工时间。计划草案将同支持团体，管理层和商务用户一起复查，做为补充性的输入和最终的批准。

问题 10：怎样确定人员需求？ 答案 10：不考虑资源限制进行计划开发。在任务旁边加上诸如数据模型制作者，业务分析员和用户等角色。再加上能将任务重叠起来的补充性的资源。在计划中要考虑开发团队包括支持团队和用户代表失去一个或多个资源的情况，要在每个任务上增加 15% 的余量。要使项目小组的组成容易理解，要有角色所必备的技术水平的说明。

问题 11：给项目加上测量标准有什么价值？ 答案 11：如果使用得当，测量标准是一个有价值的工具。它们提供测定开发系统的复杂性和工作量的方法。度量结果为制定项目计划提供了信息输入资源，并且是确定发展方向的有价值的历史信息。软件测量标准将有助于开发更好的软件。不过，最好有 3 年的历史资料。

问题 12：你怎样在计划中运用新技术？ 答案 12：在增加培训任务的同时要扩大工作量，缩小每个工作单元。在评价新技术在开发中的影响的过程中加上额外的原型和检查点（里程碑）。 　　

人员管理技能 问题 13：你作为项目经理要做的第一件事情是什么？ 答案 13：除了注意公司的发展方向并从中发现自己的发展道路外，在头脑中要建立项目经理所关注事物（商务，公司，项目，团队，个人，技术和方法论的变化）的优先顺序。因此，和部门经理开会确定优先顺序，安排用户和职员会议，得到全部成员的状态报告和评价。重要的是能尽快处理业务，项目和个人有关的事情。

问题 14：当你的职员减少了 30 % 你将怎样着手完成公司的项目？ 答案 14：首先，确定和区分项目的优先次序，哪些项目是必须在今后的 18 个月内完成的。把绝对的最小的总人数与每个项目联系起来。向管理者和用户说明对进度表的影响。因为两者都也许不愿意接受进度表的变化，因此或许可以给你一些例外。减掉顾问比去掉一个雇员要好。每个项目的顾问也许可以用雇员代替。坚持运用学习曲线理论并逐步减少顾问人数。可以把一些顾问的工作从一周降低到一星期中的 2 或 3 天以应付人员削减。如果公司有提前退休的一览子法案，赶紧寻找一些有资历的、适用的雇员。牢牢记住失去 “老资格的人” 你也许就失去了有价值的知识。尽可能将一个快退休的人和新手组合在一起。以满足业务目标为前提，确定剩下员工的重要性以及他们在每个项目中的重要性。使新手和经验丰富人员的比例适当。两者都是确保项目和公司不断成功的财富。

问题 15：你的团队主要是由新手组成的，并且进度已经落后。你将做什么？ 答案 15：需要记住一个项目很少因为在截止时间内没有完成而被取消的。项目被取消，主要是诸如缺少资金，用户支持或不能满足的业务目标。因此，要做的第一件事是培训，无论在室内还是室外，在课堂或通过录像带。另一种附加方法就是让资深的雇员或高级顾问充当教师。举办针对个人评估和辅导的会议。帮助每个员工准确评价他们各自的优点和缺点。同时明确任务，将所有必须遵守的标准或准则阐述清楚。为每个员工提供从成功项目中得到的模板作为指南，还要允许他们发挥自己的才能。如果需要，和他们一起工作。对任何问题或完成的任务做出迅速的反馈。对于较大的任务，看看他们的计划，有助于确定他们是否了解任务的范围和目标，以便了解他们是否能完成任务。倾听员工的观点，也许他们会有完成任务的正确的方法和途径。然而也要防止雇员陷入挫折和士气低落的困境中。

问题 16：你将怎样和与你竞争相同职位的员工相处？ 答案 16：这是经常发生的不愉快情况。雇员总是认为他们能胜任某个职位而管理层还没有意识到这一点。因此，要进行如下调查： 发现员工的管理能力阅读评估和状态报告 当雇员变得不合作时试图发现一些变通的方法并且针对这种状况进行一些个人谈话，谈话内容包括：弄清楚状况；与员工一起分析他/她具有的能使他/她得到提升的资历；强调在初期协作的必要性和管理层是如何高度重视合作关系的。

问题 17：在决策和工作风格方面你会给你手下多大的自由？ 答案 17：自由的大小取决于每个人的技能和专业水平。一个好的经理是 “面向结果的” 并且能创造一个能使团队广泛交流的环境。无论如何，每个员工每周需提交项目和商业目标有关的状态报告并且经理要进行审查。这有利于加强组织建设并使每个员工致力于他们自己应完成的工作。

问题 18：如何对待即将退休的员工？ 答案 18：即将退休的员工能提供大量的信息。一个人在把所有业务知识和关系网拒之门外时必须三思而后行。因此，要利用这些人的能力：他们在某些特殊技能方面可以作为新手的老师。明确主要的工作利益，要使项目能充分利用这些技能，可以利用他们从非正规途径得到的必要支持（不用通过正规的，官僚的途径完成工作）

问题 19：对一个一贯迟到的员工你会怎么办？ 答案 19：好的经理是通过结果与所花时间来评价一个员工的。然而，还需要了解迟到会在公司和团队中造成什么影响。一个人经常迟到人们会感到领导在徇私并且会影响团队的士气。这个人也许可以按期完成自己的任务但可能会影响到别人的进度。职业特性包括可靠性。如果别人的工作进度取决于他们的工作进度，那么，他们的进度对于整个团队就很重要。首先判断这些员工的模式。换句话说，是偶尔还是一贯如此。其次，明确公司有关考勤方面的政策，确定迟到及其相关处理方法。要了解该员工的工作是否与进度相符并了解与他一起工作的人对他迟到的反应。最后，必须与他们进行客观的谈话，谈话的主题包括： 公司的规章制度 对团队的影响 对个人评价的影响强调时间进度 达成谅解

问题 20：在费用削减的情况下，你将怎样鼓舞士气？ 答案 20：钱不是仅有的激励因素。人们需要了解他们是否对项目有积极的贡献。因此，要强调拥有的自豪感并且举行业务会议，在会上让用户谈谈他们对项目组的良好印象。同时，让用户对他们的功能和业务提出一个概括。培训是一个激励因素。因此，状况会议可以作为一个非正式的培训课程。不定期地举办有关新技术的内部研讨会。如果培训课程费用太昂贵，可以租赁技术录像带。订阅杂志，有许多技术杂志是免费的。必须记住的是，忽视培训将使团队的精神低落。这样会影响产品的质量和数量。

问题 21：你如何雇人？ 答案 21：首先做一个工作所需技能的描述。如果你不了解现在的需求就很难雇到合适的人。接下来要了解团队成员的个性。列出团队现在缺乏的技能或工作风格。与人力资源部门讨论所有这些情况，包括调动现有员工。当候选人到来，针对现有工作进行面试，同时还要了解他是否具有新岗位所需的技能。

问题 22：你将如何解决团队中的个人冲突？ 答案 22：辨别出人的不同个性。分别向员工表述每种风格的价值。当与冲突双方讨论试图分析申诉或冲突的原因时应持有客观的态度。

问题 23：你将如何监控/管理顾问？ 答案 23：顾问也是人，也需要得到尊重。他们还需要明确的目标和任务。坚持做工作周报，将工作时间和工作完成情况联系起来。

问题 24：你将如何管理外援？ 答案 24：和管理顾问的方法相同。不过，他们可能有一个经理来负责外包合作。首先要和这个经理一起组织日常会议。坚持做工作周报和可交付产品的拷贝。

问题 25：你将如何同一个似乎总是不能按时完成工作的员工一起工作？ 答案 25：直到找到问题的原因时，问题才能解决。原因不一定是分析问题或解决问题的能力差。可能是一个管理方面的问题。该员工可能没有得到适当的培训，他的工作可能超出了他的能力范围。另外一种可能是这个人有太多的事情要做而且这些事情都是最重要的或者他不清楚交付日期。如果不是上述原因，要注意观察，找出原因所在。例如当所有人遇到问题时，都会找这个人。那么，这个人的工作经常会被无数次地打断。 　

沟通技巧 问题 26：你将怎样使用户参与和了解项目的每个阶段？ 答案 26：贯穿整个项目的原型是得到用户肯定的方法。让用户对有形和无形的利益进行研究，以做出成本效益分析。和用户一起开发测试数据，测试大纲和验收标准。e-mail 里程碑状态报告和更新/修改的项目计划。在项目进行阶段性检查时的同时对可交付产品进行检查。

问题 27：你将如何发现和解决内部和外部问题？ 答案 27：从所有可能的资源获取实情并客观地记录下来。然后在相关方参与下，尽量自己解决问题。如果这种方法无效，按照组织的管理结构提出问题并参照可能的解决方法。

问题 28：你将如何得到供应商的一贯支持？ 答案 28：虽然供应商是在管理范围之外的，但也可以将他们包含进来，如果他们：得到尊重；了解业务目标；预先购买；将供应作为计划的输入，这样会对他们产生影响；参与设计，因此，在项目的早期阶段就应该考虑供应商的管理。确保他们了解业务目标和工作的利益。

问题 29：如何处理 “是否能破除一些规矩” 现象？ 答案 29：单纯为了技术而采用某种技术是不能说服用户或领导的。任何人都可能抵制那些会改变现状的变化。然而，如果将技术与商业利润联系起来，用户会支持你的建议。

问题 30：你如何应对不同的商业用户，如果他： a) 拒绝确认需求 b) 经常改变主意 c) 不肯花时间 d) 坚持不现实的截止日期 答案 30：无论客户有多难应付，都应该记住正因为他们我们才有工作做。他们是客户。必须以高度的职业精神，完全尊重他们。因为他们不能了解我们的工作正如我们不能完全了解他们的那样，沟通变得比较复杂。因此，我们要花时间作规划并解释其中包含的内容。用户需要感到他们没有浪费时间，正在取得成果，并且他们的意图被很好地理解。制作原型是一个有用的工具。它提供了一幅用户能理解的、灵活的图画。另外，对工作风格的理解也很重要。拒绝承认或不断地改变想法可能源于对问题缺乏理解，或是对未来的担心。用户往往不愿意花时间与 IT 人员交谈并认为这样做是浪费时间，因为 IT 人员过分关注他们自己的任务。应该对过去交付产品的历史进行检查。如果用户来了多次但并未发看到有价值的输出，他们将拒绝花更多的时间。在这种情况下，你应该做你擅长的商业领域的项目以期得到用户的尊重。召开一个历时一小时（并且要限定在该时间范围内）的需求讨论会来讨论特殊的问题。会议结束时应让用户知道下一步该怎么做（并要取得共识）。用户的观点被记录在 “会谈纪要” 上。这些会让用户感到他们的意见已被听取并且允许他们更改错误。一个项目被取消往往是由于没有经济合理地达到用户的业务要求。如果在项目的整个过程中，一直保持与用户的有效沟通，他们将看到他们的要求正在逐步达到。项目很少因为延期而被取消。要注意范围变更。在原有的截止日期上增加额外的任务，将会产生不现实的截止日期。

问题 31：在一个不编程，就认为你没在工作的环境中，你如何开展工作？ 答案 31：如果用户认为你了解了他们的业务目标，他们就希望早些开始编程。以一种他们能够理解的形式制作需求文档，提供一种开放的沟通方式，并让他们知道你了解什么，你正在做什么。通过项目计划，状态报告和原型同样能够表明项目的进展。通过让用户审查需求，原型和状态报告的形式，让用户参与项目

Sky_pele 于 2008-7-2 23:45 发表

好吧。你很新。。

那你把 admin 的密码给我吧，哈哈 [/quote]

123456

3.13 自动生成依赖关系 在 makefile 中，许多规则都是一些目标文件依赖于一些头文件。例如：’main.c’ 通过’#include’ 使用’defs.h’，这样规则： main.o: defs.h 告诉 make 在’defs.h’ 变化时更新’main.o’。在程序比较大时，需要写许多这样的规则；而且当每次增删’#include’ 时，必须小心的更新 makefile。许多现代的编译器可以帮你写这些规则，通常这是通过编译器的’-M’ 选项，例如命令： cc –M main.c 输出以下内容： main.o : main.c defs.h 这样就不必写这些规则，有编译器代劳了。 注意这样的依赖关系中提及’main.o’，不会被隐式规则认为是中间文件，这意味这 make 在使用过它之后不会将其删除。使用老的’make’ 程序时，习惯做法是使用’make depend’ 命令利用编译器的功能产生依赖关系，该命令会产生一个’depend’ 文件包含所有自动产生的依赖关系，然后在 makefile 中使用 ’include’ 将其读入。 使用 GNU 的 make 时，重新生成 makefile 的功能使得这种做法变得过时：从不需要显式请求更新依赖关系，因为它总是重新生成任何过时的 makefile。 自动依赖关系生成推荐的做法是对每个源文件做一个 makefile。对每个源文件’NAME.c’，有一个 makefile ’NAME.d’，其中列出了目标文件’NAME.o’ 依赖的所有文件，这样在源文件更新时，需要扫描来产生新的依赖关系。例子是一个从’NAME.c’ 产生依赖关系文件’NAME.d’ 的模式规则： %.d: %.c $(SHELL) -ec '$(CC) -M $(CPPFLAGS) $< \ | sed '\''s/($).o[ :]/\1 $@/g'\'' > $@' -e 选项是当 $(CC) 命令失败时（exit 状态非 0），shell 立刻退出。通常 shell 的返回值是管道中最后一条命令（sed）的返回值，这样 make 不会注意到编译器出错。 使用 GNU 的 C 编译器时（gcc），可以用’-MM’ 选项来代替’-M’ 选项，这样省略系统头文件的依赖关系。’sed’ 命令的目的是将 main.o : main.c defs.h 转换为 main.o main.d : main.c defs.h 这样使得每个’.d’ 文件依赖于’.o’ 文件相应源文件和头文件，make 则可以在原文间或头文件变化时更新依赖关系文件。 如果定义了生成’.d’ 文件的规则，可以使用’include’ 指令来读入所有的文件： sources = foo.c bar.c include $(sources:.c=.d) 例中使用替换变量来将源文件列表’ foo.c bar.c’ 转换为依赖关系文件的列表。因为’.d’ 文件和其它文件一样，不需要更多工作，make 会在需要时重新生成它们。

4 编写命令 规则的命令是由一一执行的 shell 命令组成。除了以分号隔开写在依赖关系后的命令，每个命令行必须以 tab 字符开始空行和注释行可以出现在命令行中，处理时被忽略（注意：以 tab 字符开始的空行不是’ 空’ 行，是一条空命令）。 可以在命令中使用任何程序，但这些程序是由 $(SHELL) 来执行的。

4.1 回显 通常 make 打印出要执行的命令，称之为回显，这和亲自敲命令的现象是一样的。当行之前有’@’ 字符时，命令不再回显，字符’@’ 在传递给 shell 前丢弃。典型的用法是只对打印命令有效，比如’echo’ 命令： @echo About to make distribution files 当 make 使用’-n’ 或’—just-print’ 选项时，显示要发生的一切，但不执行命令。只有在这种情况下，即使命令以’@’ 开始，命令行仍然显示出来。这个选项对查看 make 实际要执行的动作很有用。 ‘-s’ 或’—silent’ 选项阻止 make 所有回显，就象所有命令以’@’ 开始一样；一条没有依赖关系的’.SILENT’ 规则有相同的作用，但是’@’ 更加灵活。

4.2 执行 在需要执行命令更新目标时，make 为每一行创建一个子 shell 来执行。这意味着诸如为进程设置局部变量的 shell 命令’cd’（改变进程的当前目录）不会影响以后的命令。如果需要’cd’ 影响下一个命令，将它们放在一行上用分号隔开，这样 make 认为是一条命令传递给 shell 程序（注意：这需要 shell 支持）： foo : bar/lose cd bar; gobble lose > ../foo 另一个形式使用续行符： foo : bar/lose cd bar; \ gobble lose > ../foo shell 程序的名字是通过’SHELL’ 变量来取得的。 （*UNIX）不象大多数变量，’SHELL’ 变量不是通过环境来设置的（即需要在 makefile 中设置），因为’SHELL’ 环境是个人选择的，如果不同人的选择会影响 makefile 的功能的话，这样很糟糕。

4.3 并行执行 GNU make 可以一次执行几条命令。通常 make 一次执行一条命令，等待其返回，再执行下一条。使用’-j’ 或’—jobs’ 可以同时执行多条命令。如果’- j’ 后梗一个正数，表示一次可以执行的命令条数；如果’-j’ 之后没有参数，则不限制可执行的命令数。缺省的数量是一。 一个讨厌的问题是如果同时执行多条命令，它们的输出会混在一起；另一个问题是两个进程不能从同一个设备获得输入。

4.4 错误 每条 shell 命令返回时，make 会检查其返回状态。如果命令执行成功，则下一条命令被执行，最后一条命令执行完后，规则执行结束。 如果有错误（返回非 0 状态），make 放弃当前规则，也可能是所有规则。 有时候命令执行错误并不是问题，比如使用’mkdir’ 命令确保目录存在：如果目录一存在，则’mkdir’ 会报告错误，但仍希望 make 继续。 要忽略命令的错误，在命令之前使用’ - ‘字符，’ - ‘字符在传递给 shell 之前被丢弃： clean: -rm -f *.o 如果使用’-i’ 或’—ignore-errors’ 选项，make 会忽略所有命令产生的错误；一条没有依赖关系的’.IGNORE’ 规则有相同的作用，但’ - ‘更灵活。 在忽略错误时，make 将错误也认为是成功，只是通知你命令的退出状态和和错误被忽略。如果 make 并未告知忽略错误，在错误发生时，表明该目标不能成功更新，直接或间接依赖于此的目标当然也不能成功；这些目标的命令不会被执行，因为其先决条件不满足。 通常 make 会立即以非 0 状态退出。然而，如果给定’-k’ 或’—keep-going’ 选项，make 在退出前会处理其它的依赖关系，进行必要的更新。例如，在编译一个目标文件遇到错误，’make -k’ 会继续编译其它的目标文件。 通常认为你的目的是更新指定的目标，当 make 知道这是不可能时，会立即报告失败；’-k’ 选项指示真正目的是测试更新程序的更多可能性：在编译之前找出更多不相关的问题。 如果命令失败了，假设它更新的目标文件，这个文件是不完整的不能使用－至少不是完全更新的。但文件的最后修改时间表明停已经是最新的，下一次 make 运行时，不会再更新这个文件。这种情况和命令被 kill 相同；则通常情况下在命令失败时将目标删除是正确的；当’.DELETE_ON_ERROR’ 是目标时 make 帮你做这件事。虽然你总是希望 make 这么做，但这不是过去的习惯；所以必须显式要求 make 这样做（其它的 make 自动这样做）。

4.5 中断 make 如果 make 执行命令时遇到错误，可能会删除命令更新的目标文件： make 检查文件的修改时间是否变化。删除目标的目的是确保 make 下次执行时重新生成它。为什么这样做？假设在编译器运行时按了’Ctrl-c’，此时编译器写生成目标文件’foo.o’。’Ctrl-c’ kill 了编译器，留下一个不完整的文件，但它的修改时间比源文件’foo.c’ 新；此时 make 也受到’Ctrl-c’ 信号删除这个不完整的文件，如果 make 不这样做，下次 make 运行时认为’foo.o’ 不需要更新，会在链接时出现奇怪的错误。 可以使用’.PRECIOUS’ 规则来防止目标文件被删除。在 make 更新目标时，会检测其是否为’.PRECIOUS’ 的依赖，决定在命令出错或中断时是否删除该目标。如果你希望目标的更新是原子操作，或是用来记录修改时间，或必须一直存在防止其它类型的错误，这些理由使得你必须这样做。

4.6 递归使用 递归使用 make 就是在 makefile 中使用 make 命令。这种技术在你将一个大系统分解为几个子系统，为每个自系统提供一个 makefile 时有用处。比如有一个子目录’subdir’ 中有自己的 makefile，希望 make 在自目录中运行，可以这样做： subsystem: cd subdir; $(MAKE) 或者 subsystem: $(MAKE) -C subdir 可以照抄这个；例子来递归使用 make

4.6.1‘MAKE’ 变量 递归的 make 必须使用’MAKE’ 变量，不是显式的 make 命令： subsystem: cd subdir; $(MAKE) 该变量的值是被调用的 make 的名字。在命令中使用’MAKE’ 有特殊的功能：它改变了-t' (--touch')， -n' (--just-print') 和-q' (--question') 选项的含义。使用上例来考虑’make –t’ 命令（’-t’ 选项将目标标记为最新但不运行命令），更加’-t’ 选项的功能，该命令将创建一个’subsystem’ 文件，实际希望的操作是运行 ’cd subdir; make –t’；但这会执行命令，与’-t’ 的原意不符。 这个特殊功能做了期望的工作。当命令行包含变量’MAKE’ 时，选项’-t’，’-n’ 和’-q’ 并不适用。不管这些导致不会执行命令的标志，包含’MAKE’ 变量的命令始终会执行。正常的’MAKEFLAGS’ 机制将这些标志传递到子 make，这样打印命令的请求被传播到子系统中。

4.6.2 传递变量到子 make 上级（top-level）make 中的变量可以显式通过环境传递到子 make 中。在子 make 中，这些变量被缺省定义，但不会重载子 makefile 中的定义除非使用’-e’ 选项。 为向下传递，或输出变量，make 在运行命令时将其加入到环境变量中；子 make，可以使用环境变量来初始化变量表。除非显式要求，make 只输出初始环境中或命令行设置的变量而且变量名只由字母，数字和下划线组成。一些 shell 不能处理有其它字符的环境变量。 特殊变量’SHELL’，’MAKEFLAGS’ 总是输出，如果’MAKEFILE’ 变量有值，也会输出。Make 自动通过’MAKEFLAGS’ 来输出命令行定义的变量。 如果想要输出特定变量，使用’export’ 指令： export VARIABLE ... 如果要阻止输出一个变量，使用’unexport’ 指令： unexport VARIABLE ... 为方便起见，可以在定义变量时输出它： export VARIABLE = value 和 VARIABLE = value export VARIABLE 作用相同。 如果要输出所有的变量，使用’export’ 指令本身就可以了。 变量’MAKELEVEL’ 在一级一级传递时会改变，这个变量的值是表示嵌套层数的字符串，顶级’make’ 是，变量的值为’0’；子 make 的值为’1’；子子 make 的值为’2’，依此类推。 ‘MAKELEVEL’ 的用途是在条件指令中测试它，这样写出在递归运行时和直接运行时表现不同的 makefile。 h

来源不详了:(