FreeOZ论坛

标题: 从CVS到SVN--关于源码版本控制系统- [打印本页]

作者: ubuntuhk 时间: 15-6-2008 21:12
标题: 从CVS到SVN--关于源码版本控制系统-
我正在准备从CVS切换到SVN来管理源码，目前还基本上对SVN一无所知，所以通过这个帖子来记录一下我的转换过程，也和大家一起分享探讨。

作者: ubuntuhk 时间: 15-6-2008 21:13
标题: 先转一些关于SVN的介绍文章
《驱散对Subversion的恐惧，不确定性和疑义》
http://www.subversion.org.cn/?action-viewnews-itemid-12

字号:  小  中  大  | 打印发布: 2008-6-01 02:24 作者: webmaster 来源: 本站原创查看: 160次

本文是Ben Collins-Sussman对关于Subversion的一些非议写的一篇文章，其中的FUD意思是“恐惧，不确定性和疑义”。

作者：
Ben Collins-Sussman
sussman@red-bean.comsussman@red-bean.com

翻译：
Rock Sun
daijun@gmail.comdaijun@gmail.com

Last Updated: 2004-12-21 14:00:06 CST

我是Subversion项目最初的开发者，这是我写的一篇非常个人化的文章，我不会装出丝毫的客观，只是代表了个人的观点和对Subversion的感觉，这不是一篇官方的项目文档，只是希望人们会在他们看到关于Subversion的FUD时，能够链接这篇文档。我的目标是驱散在网上流传的许多流言和误解。

在开始之前，需要给小心的管理员一点忠告。如果你正在学习Subversion并且想在团队或者公司里使用，请你像使用普通的新产品一样使用Subversion，这并不是说 Subversion不可靠...只是意味着不应该使用任何常识。不要没有任何测试的盲目跳入，没有任何用户希望新产品强迫他们，如果你是负责系统管理工作，你必须在推广给别人之前对它足够熟悉。找一个小项目，作为Subversion的试验，寻求热情的志愿者来进行试验，最后，如果Subversion 有好的结果，你会有许多高兴的开发者（从一开始参与这个过程），你也可以开始准备大的设置。

就这样了，下面是我最常听到的FUD。

Subversion非常难于编译，有太多的依赖，我听说它需要Apache...打断一下！

首先说一下Apache的问题：Subversion不需要Apache，它依赖Apache Portable Runtime (APR)库，并不等同于Apache的web服务器，APR允许Subversion客户端和服务器能够在Apache存在的任何地方编译，同一个道理，Netscape Portable Runtime (NSPR)让Mozilla可以在任何地方编译。

Subversion有两种不同的服务器：你可以使用包含WebDAV模块的Apache2，或者是使用类似于CVS pserver的独立运行的“svnserve”服务器，没有一种server会是“更官方的”，两种方式都存在一些代价，可以看看Subversion Book的第六章中的一些特性比较。

第二，关于“难于编译”的问题：你最后一次编译CVS是什么时候？从来没有？那是因为它安装在每一个系统，对吧？如果你使用支持良好的操作系统，Subversion二进制一定是你的发布版本（rpms, debs, fink等等）的预装标准包，或者非常容易下载（win32的情况）。

编译是开发者的事情，不是用户的。Mozilla, Evolution, KDE和Gnome也都有许多过度的依赖，但是大多数用户不知道也不关心，因为他们并不编译。事实上，Subversion有这么多依赖是因为它有很多复杂的特性，并没有重新发明轮子，没有不寻常的东西。

Subversion没有打破所有的根基 -- 它保存了CVS的模型，为什么都要模仿CVS？

从一开始，Subversion项目一直有一个“基本公理”：

CVS是版本控制一个已证明的完美模型；它只是没有能足够好的实现。

我们不是打磨垃圾，我们是在打磨粗糙的钻石，Subversion采纳了CVS模型，添加了版本控制，原子提交，数据库后端，版本化的元数据，有效地二进制处理，灵活的网络能力和坚实的C API，大多数特性是CVS应该首先具备的特性。

如果你不认可本项目的基础公理，就没有必要多说了；你不适合Subversion。

一些新的竞争的版本控制系统是“分布式的”或“非集中式的” -- 例如Monotone，或Arch，甚至非自由系统例如Bitkeeper，这些产品提供了工作的新方式，每一个开发者都有一个私有的版本库，版本库可以以任何等级的方式交换变更。

许多Subversion开发者对这些分布式系统有复杂的感觉，一方面，这听起来很整洁，我们很有兴趣尝试一下，另一方面，许多用户抱怨这些东西有多难使用，或许有些会随时间得到改善，但是至少一个Subversion开发者相信非集中式的模型对于自由软件开发是不恰当的。你要自己作出选择。

此刻，还没有将Subversion变成非集中系统的完整计划，但是有一个基于Subversion库的有趣的非集中项目svk，它应该可以与普通的 Subversion版本库和不使用svk的普通用户是共存。许多人真的喜欢它，所以你可能会将其检出。Subversion项目，最起码，计划会有一天学习svk，只是去看一看如何实现各种各样“智能合并”，谁知道呢？也许一些非集中能力也会融入Subversion，一切在此刻都还只是构思。
如果Subversion只是“CVS的改进”，为什么花了四年才进入1.0？在CVS基础上增加一些特性就这么难吗？

请不要因为我们仅仅“扩展了CVS的一些特性”就侮辱我们的项目，这些特性不能通过扩展CVS实现，CVS的代码基佷混乱，非常难于扩展（尽管如此，容然有两个项目尝试如此：CVSNT和MetaCVS），这就是我们从头开始重新设计的原因，Subversion和CVS没有共同的代码；它们之间共同点只有并行，集中式的模型和相似的UI。

我们通过实现管理工作拷贝数据和理解版本化目录的日志库开始，然后我们在事务性数据库基础上实现了一个不版本库，每一个事务储存整个目录树，花了14月实现了使用Subversion保存自己的代码，之后，大约花了两年半时间持续的使之稳定，发现bug和回归测试，每几个周就发布一个新的版本，目录树的版本化是一件困难的事情。

当Subversion进入了“alpha”阶段，它已经经过了几十位开发者和工作室的实际工作的考验，此刻，任何其他项目都会叫这个产品“1.0”，但是我们决定尽可能延迟这个标签，因为我们是管理用户不可替代的数据，所以我们在标注1.0这件事上非常保守，我们已经意识到许多人在使用Subversion之前在等待这个标签，对这个标签的含义充满了期待，所以我们遵守这个标准，数据丢失会摧毁一个SCM的名誉。

我为我们的公司研究不同的SCM解决方案，我有一个Subversion与其他系统的比较表格，我认为Subversion缺少了[特性 X]，你不认为这是一个问题？有计划解决这个问题吗？为什么会希望团队为这个项目贡献，但是最终不会看到这个特性的实现。

首先，威胁没有任何结果，许多人以为可以通过提供资源影响项目，但是如果使用这些资源意味着将项目引入错误的方向，Subversion像其他开源项目一样，是基于代码贡献和讨论的知识精华。欢迎你和其他人一起参与进来，但是必须遵守共同的术语和规则，更多细节请看HACKING文档。

第二，Subversion的开发者确实知道特性蔓延问题，许多项目有松散的目标，对所作的事情没有坚实的定义，所以项目的范围不断扩大，社区不断变迁，不会发布任何东西，就像许多Sourceforge上的遗嘱一样的项目。从第一天起，我们的开发者就发表了一份简要的定义，说明了CVS的问题，和 Subversion1.0将要做的和不会做的事情，如果你错过了讨论，很抱歉，那是网站的首页，是我们多年不变的指导。如果你希望影响1.0之后的特性，可以自由的加入到项目的讨论中来，并准备好写代码，一定要浏览一下我们的问题追踪和以前讨论的邮件列表，我几乎可以保证你不会是第一个询问这些问题的人。

最后，我要讨伐许多在网上见到的SCM“比较表格”，真诚的讲，我有许多原因对这些东西保持不信任，许多编写者都是某个SCM系统的核心开发者，所有的讨论都是在作者自己系统的术语和方法论框架下进行的，另一方面，许多作者都是简单的信息收集者: 表格读起来像书籍报告，你的印象就是作者读了所有项目的描述，然后简单的总结出来，但是作者缺乏甚至没有在团队中实际使用系统的经验。最后，我对这些表格之后的假设有我的个人异议，许多SCM特性被列出来好像有一个理想的，柏拉图主义似的系统：”让我们看看这些系统累加起来与完美系统的比较！“真是一派胡言，没有完美的系统，每一种系统都有优点和缺点，每一种系统在特定项目都有其优势和劣势，没有一种图表会告诉你那一种系统适合你，你需要自己去尝试。

为什么Subversion没有使用好的现代语言如Java或C++编写？为什么使用古老的C？

这是一个危险的领域 -- 没有人希望卷入这场语言圣战，我们使用C有一些原因，下面是我们开发者的解释：

* 可移植性：C++编译器没有C语言编译器级别的标准，一种C++编译器可以执行的代码不能工作在另一种下，而C++库的链接更是一场恶梦。
* C有大量熟练的程序员。
* C库API可以几乎所有的其他语言访问，这对Java来说不是真实的。

可移植是这里的重点，因为Subversion是由C库编写并不意味着你必须使用C，有许多Subversion库的绑定，例如perl, python, Java和C++，都被许多第三方项目使用。
数据库后端太危险也不友好，如果我希望修改数据结构？如果是CVS，至少我可以用编辑器打开RCS文件。

你是暗示人们直接搞坏RCS文件更加安全？让我们把问题反过来：你为什么要将RCS文件载入编辑器？为什么你的管理员手工移动CVS版本库的文件？以我的经验，这通常因为CVS本身的问题和缺陷，一个好的系统应该避免版本库的修改。

当你希望在网罗上分享高度组织的数据，现在标准的实践是什么？佷简单：把数据放到数据库（如MySQL），然后通过web界面展现，这是经典的LAMP方案。

Subversion 作了同样的事情：将你的数据存放在数据库，使之可以在网络上可以访问，请注意没有人因为将关键数据存放在MySQL感到恐慌，而MySQL的数据不是能用编辑器直接修改的，如果你希望查看低层次的数据，必须使用导出工具，如果你希望移植数据，需要导出为一种可以移植的，透明的格式。

还需要提一下Subversion 1.1可以创建完全不使用BerkeleyDB的版本库，”fsfs“使用普通的OS文件保存数据。（依然是二进制格式，还是意味着不可以人工编辑！）
我的朋友说Subversion非常慢。

是的，曾经是这样的，我们花了大量时间来解决正确性而不是速度，在2003年后期，我们也花了大量时间进行性能优化，通过我们自己的测试，Subversion 1.x的速度与CVS相近。
看，Subversion不是butterflies和rainbows，如果出了问题我该怎么办？

我不想欺骗你，Subversion依然有一些问题，但是我们只是希望在宇宙毁灭之前作一些感兴趣的事情，我们必须容忍不完美：
*许多错误信息应该被清理，我们正在努力。
*很容易得到字符转化失败，版本库使用UTF8保存所有的路径和提交信息，但是客户端可能一直不能转化UTF8为本地系统的设置，我们应该优雅的解决这种失败，在验证UTF8方面做的更好。
*BerkeleyDB需要关心和照顾，一方面，它非常简单的提供了事务性数据库，而不是强迫用户创建完整的SQL系统，但是另一方面，许多人对于数据库恣意挥霍，如果访问版本库（apache, svnserve, svnadmin, svn等等）的进程对于db文件没有完全的读写权限，数据库会锁住，并且需要日志恢复到一致的状态，这不是佷严重的问题，但这通常会使不够小心的人无所适从，”更大的力量带来更大的责任“ -- 大多数人没有意识到这种责任，并且得到了失败，因为他们像对待CVS版本库一样对待SVN版本库。请阅读本书的这一小节，你将成为”受过教育的用户“。

   作为选择，创建'fsfs'版本库而不是BerkeleyDB的 -- 没有数据库的问题，并且可以工作在NFS，见Subversion 1.1的发布说明。

作者: ubuntuhk 时间: 15-6-2008 21:20
标题: Subversion特性
http://www.subversion.org.cn/?action-viewnews-itemid-13

字号: 小中大 | 打印发布: 2008-6-01 02:25 作者: webmaster 来源: 本站原创查看: 135次

* 保留大多数CVS 特性
* 目录、重命名和文件meta-data都已经版本化
* 提交是真实的原子操作
* 可以通过WebDAV/DeltaV协议选择Apache作为网络服务器
* 可以选择独立服务器模式
* 分支和标签是代价低廉（固定不变的）的操作
* 本地化的客户端/服务器，分层的库设计
* 客户端/服务器双向传输区别的协议
* 消耗和修改部分的大小成比例，而不是数据的大小
* 可以选择数据库和纯文件的版本库实现
* 对象链接的版本化
* 处理二进制文件的高效性
* 可解析的输出
* 本地化信息

# 保留大多数CVS 特性

Subversion意味着比CVS更好，它拥有CVS的大多数特性，一般说来，Subversion的接口与CVS的十分相似，除了一些有竞争性的原因我们选择了其他方式。
# 目录、重命名和文件meta-data都已经版本化

CVS经常因为缺少这些特性而被抱怨，Subversion的版本不仅仅是关注文件的内容和存在性，它也允许附加在任意文件和目录上的metadata ("properties")可以被版本化，而且提供了一种机制可以版本化文件上的“执行”许可标志。
# 提交是真实的原子操作

在整体提交之前不会有部分提交起作用的情况出现，修订号对应每次提交而不是对应每个文件，log信息与修订号附在一起，并没有和CVS一样需要冗余的地方存放。
# 可以通过 WebDAV/DeltaV协议选择Apache作为网络服务器

Subversion可以使用HTTP为基础的WebDAV/DeltaV协议用来网络通讯，Apache服务器提供版本库端的网络服务，这给了Subversion更好的协同性，也轻易获得许多关键特性：认证、路径为基础的授权，数据压缩和基本的版本库浏览。
# 可以选择独立服务器模式

Subversion也提供了独立服务器选项，这时使用自定义的协议（并不是所有的人希望运行Apache 2.x），独立服务器模式可以作为inetd的一个服务运行，或者以守护进程模式，提供了基本的认证和授权，也可以使用SSH作为通道。
# 分支和标签是代价低廉（固定不变的）的操作

没有原因会使得这些操作会很昂贵，所以它不是。.

分支和标签本质上都是通过“拷贝”操作实现的，一个拷贝操作会占用很少的固定数量的空间，任何拷贝都是一个标签，如果你对一个拷贝提交，它的分支也会一样的操作。（This does away with CVS's "branch-point tagging", by removing the distinction that made branch-point tags necessary in the first place.）
# 本地化的客户端/服务器，分层的库设计

Subversion从一开始就是设计为客户端/服务器模式，从而免去了许多折磨着CVS的维护问题，代码是有一系列结构化的模块组成，有定义良好的接口，设计为被别的程序调用。
# 客户端/服务器双向传输区别的协议

网络协议有效的利用网络带宽，在有可能的情况下回双向传输区别（CVS的服务器向客户端传输区别，但反之不是）。
# 消耗和修改部分的大小成比例，而不是数据的大小

通常情况下，Subversion操作所耗费的时间与此次操作引起的变化成比例，而不是对这个项目改变的绝对值，这个是Subversion版本库模型的特性。
# 可以选择数据库和纯文件的版本库实现

版本库可以使用嵌入的数据库后端也可以使用定义格式的纯文件的后端
# 对象链接的版本化

Unix用户可以在版本控制里置入对象链接，这个链接会在Unix的工作拷贝里重建，但不会在win32工作拷贝里创建。
# 处理二进制文件的高效性

Subversion对于二进制文件具备同文本文件一样的高效性，这是因为它在传输和存储连续的修订版本中使用二进制的文件交换算法。
# 可解析的输出

Subversion所有的命令行客户端输出的内容都经过精心的设计，适合人们读取和自动解析；脚本化也具备较高的优先级。
# 本地化信息

SUbversion会根据本地设置使用gettext()来显示传输错误、报告和帮助信息。

作者: MSPro 时间: 16-6-2008 00:11
看翻译的太累，还不如看英文的呢

作者: coredump 时间: 16-6-2008 00:30
标题: 我从WIKI上COPY的版本控制软件的调查
http://docs.google.com/Doc?id=ajdnjpnjwcnx_267dkjb7kwf

蓝色高亮的是我曾经用过的，个人感觉subversion综合排名中上。我最喜欢的是perforce,只不过这是个很贵的商业版版本控制系统，Google内部就用这个。其次是目前在用的TFS，TFS之于VSS就如SQL Server之于Access。Subversion基本上在我心目中排在第三位。

对于分布式的版本控制系统我最喜欢git (Linux kernel和Xorg的选择)，其次Mercurial (OpenSolaris和Mozilla的选择)，适用于Subversion和CVS的SVK接触过，没留下深刻印象，这种在集中版本控制系统上patch的东西不太喜欢。

作者: ubuntuhk 时间: 16-6-2008 00:40
标题: 回复 #5 coredump 的帖子
呵呵，原来有这么多种选择，这个比较资料非常棒。

作者: xblues 时间: 16-6-2008 00:42
提示: 作者被禁止或删除, 无法发言 标题: SVN
http://tortoisesvn.tigris.org/

A Subversion client, implemented as a windows shell extension.

TortoiseSVN is a really easy to use Revision control / version control / source control software for Windows.
Since it's not an integration for a specific IDE you can use it with whatever development tools you like.
TortoiseSVN is free to use. You don't need to get a loan or pay a full years salary to use it.

作者: ubuntuhk 时间: 16-6-2008 00:42
标题: 回复 #4 MSPro 的帖子
确实好些IT技术文章看着如同嚼蜡（包括我转的这两篇SVN帖子，呵呵）

作者: xblues 时间: 16-6-2008 00:46
提示: 作者被禁止或删除, 无法发言 标题: 回复 #8 ubuntuhk 的帖子
Try the one I recommended! It's the best SVN client so far. I have been using it for awhile now.

作者: AnaCoppola 时间: 17-6-2008 21:41
u版，我们之前公司就是用SVN的，我还给同事们做过SVN的初级培训。有什么问题大家拿来一起探讨哦。

作者: ubuntuhk 时间: 18-6-2008 00:27
标题: 回复 #10 AnaCoppola 的帖子
快来给俺做个初级培训吧

作者: AnaCoppola 时间: 18-6-2008 10:03
标题: 回复 #11 ubuntuhk 的帖子
你要是很熟CVS，SVN要通不难的啊

呃。。。偶是说的使用，偶在公司也不管server端的部署的。。。

作者: xblues 时间: 25-6-2008 12:33
提示: 作者被禁止或删除, 无法发言 标题: SVN更新，TortoiseSVN 也跟进推出了1.5Beta版了
详情见：
http://tortoisesvn.tigris.org/tsvn_1.5_releasenotes.html

我目前感觉这个东西越用越顺手，习惯成自然。自己的源码最好还是用这个管理一下。

What's New in TortoiseSVN 1.5

* Merge Tracking
* Sparse checkouts
* Cyrus SASL support for svnserve
* Changelist support
* Log message caching
* Repository browser
* Revision graph
* Client side hook scripts
* TortoiseMerge

Details are described below.

TortoiseSVN 1.5 is a superset of all previous TortoiseSVN releases, and is considered the current stable and "best" release. Anything in 1.0.x, 1.1.x, 1.2.x, 1.3.x or 1.4.x is also in 1.5, but 1.5 contains features and bugfixes not present in any earlier release.

作者: xblues 时间: 25-6-2008 12:48
提示: 作者被禁止或删除, 无法发言 标题: Wiki上比较各种版本控制的页面
http://en.wikipedia.org/wiki/Com ... on_control_software

居然可以找到很多IDE集成的工具，我用VS比较多，居然找到了一个免费的subversion for VS 的插件。

http://ankhsvn.open.collab.net/servlets/ProjectProcess;jsessionid=5076E119FECD262161CBD81124BABD77?pageID=3794

作者: langchu 时间: 25-6-2008 12:56
哎，公司有过一次尝试用svn，结果适应不来，暂时感觉不如cvs用的方便

作者: xblues 时间: 25-6-2008 12:58
提示: 作者被禁止或删除, 无法发言 标题: 回复 #15 langchu 的帖子
自己用的话，使用TortoiseSVN 还是很不错的选择，功能强大。

作者: langchu 时间: 25-6-2008 15:19
标题: 回复 #16 xblues 的帖子
也是那时候没有时间去研究这玩意

作者: AnaCoppola 时间: 25-6-2008 19:43
标题: 回复 #15 langchu 的帖子
那你快点习惯，等习惯了，就会发现svn比cvs好用多了。

作者: langchu 时间: 25-6-2008 20:14
标题: 回复 #18 AnaCoppola 的帖子
没有项目用，目前的项目甚至都没有代码控制

作者: AnaCoppola 时间: 25-6-2008 21:06
标题: 回复 #19 langchu 的帖子

项目啥都可以缺，连文档也可以不要，可是怎么可能不要版本控制的？？

作者: ubuntuhk 时间: 26-6-2008 04:14
标题: 回复 #20 AnaCoppola 的帖子
呵呵，绝对有道理，没有版本控制，项目开发到后面就成了一团麻了

至于文档也是有必要，不过程序员都不爱写，大多是把变量和函数命名得直观一些，再多一些就是写几个字当注释

作者: langchu 时间: 26-6-2008 11:34

原帖由 AnaCoppola 于 25-6-2008 21:06 发表

 登录/注册后可看大图

项目啥都可以缺，连文档也可以不要，可是怎么可能不要版本控制的？？

可是就是没有，我能有什么办法，碰到这种项目只能说命苦

不过，也可能是因为是小项目，所以上面无所谓

作者: xblues 时间: 26-6-2008 11:58
提示: 作者被禁止或删除, 无法发言 标题: 回复 #22 langchu 的帖子
习惯问题，习惯成自然，版本控制也不是什么那么难用的，习惯就好了。你自己装上，先用一段时间。

作者: langchu 时间: 26-6-2008 14:18
标题: 回复 #23 xblues 的帖子
不是没有用过版本控制，只是当前的项目没有控制而已shrug

作者: sliuhao 时间: 21-11-2008 10:11
SVN的设计思路比任何SCM tool都要超前.

SVN对资源库的管理是按照对整个库的管理来的, 而不是管理单个文件的版本升级,进而做basline
所以, SVN对整个开发过程来讲, 不会丢失任何资料, 另外一个好处就是submit的原子性, 能理解在CVS下一次submit一系列文件, 一些成功,一些失败的苦恼吧.

所以n年前, wincvs的创始人已经不做CVS的后续开发了, 转投了SVN门下.
还有个比较好的SCM是EMSRV, 不过完全是集成到IBM VAJ环境, 虽然经常出错, 不过在IBM VAJ的产品线里面还是很handy的....呵呵....

作者: 四香油饼 时间: 20-12-2008 14:47
各位高人，你们觉得bazaar怎么样？
我的需求就是单机版，windows/linux双平台

作者: coredump 时间: 20-12-2008 23:20
标题: 回复 #26 四香油饼的帖子
这个需求很多都可以满足： git, cvs, subversion, perforce, git, mercurial

就bazaar来说，优点是支持ssh, ftp, http的push/pull, 服务器端不需要安装bazaar环境，这点的确非常方便。缺点是bazaar的速度是VCS中较慢的一个，而且缺少一个比较好用的图形话工具。这些缺点对于习惯于使用命令行和不管理非常大的项目来说也可以无视。

作者: kane321 时间: 21-12-2008 21:24
很好用,以前上學時就用過

作者: xblues 时间: 22-12-2008 04:25
提示: 作者被禁止或删除, 无法发言 标题: 推荐两个免费的SVN客户端
可以和VS2005 VS2008集成，用起来非常方便！
http://ankhsvn.open.collab.net/

直接集成到文件浏览器，也很方便，如果你不用VS，那就选用这一款吧。
http://tortoisesvn.tigris.org/

目前我两款都用。

作者: seth_chen 时间: 22-12-2008 10:56
嗯，我们现在开发就是用的tortoiseSVN，感觉还是很好用的。

作者: lwnxx 时间: 22-12-2008 15:16
悉尼的Atlassian公司出的一整套开发工具还是很不错的：

Jira + Confluence + Fisheye，可以实现全套的任务管理，BUG跟踪，代码分享（审核），SVN/CVS整合。

可以看看我们项目用使用这些产品的实例：

首先是整合SVN进行代码分享及审核（审核功能只有相关权限人员才可看）

http://edupass.chinaedu.net:8080 ... on/Indexer.java?r=1

然后是文档管理：

http://edupass.chinaedu.net:8080/wiki

当然还有超强大的jira:
http://edupass.chinaedu.net:8080/jira

bug跟踪，任务管理，当然还有代码patch管理整合。

作者: coredump 时间: 22-12-2008 15:21
标题: 回复 #31 lwnxx 的帖子
Atlassian的产品是不错，我们也在用，不过都是商业版的，价格不菲

作者: lwnxx 时间: 22-12-2008 15:26
标题: 回复 #32 coredump 的帖子
是啊，不过这个公司很厚道，如果你从事的是开源产品的开发，他们所有的产品及其源代码免费提供。

作者: coredump 时间: 22-12-2008 15:32
标题: 回复 #33 lwnxx 的帖子
需要申请，批不批准要看运气。

BTW,Confluence我很喜欢,性能不错，接口也很友好，提供XMLRPC接口，前段时间才写了段perl脚本，很方便的就把公司的一大堆html数据导入到了Confluence wiki中，商业软件考虑的就是周到。

作者: seth_chen 时间: 22-12-2008 22:22
脚本语言我只熟悉tcl，做通信产品测试自动化用的比较多

作者: playbug 时间: 20-11-2009 16:50
我们用的是PVCS 和 DOORS，只会用不太懂。
你们说的太深奥了哦。

作者: marshal 时间: 21-11-2009 22:58

原帖由 AnaCoppola 于 25-6-2008 20:43 发表

 登录/注册后可看大图

那你快点习惯，等习惯了，就会发现svn比cvs好用多了。

这就跟用过Mercurial之后，就不会想碰SVN了是一个道理滴

作者: uniwg 时间: 26-11-2009 18:02
很有价值，仔细研究

[ 本帖最后由 uniwg 于 26-11-2009 19:04 编辑 ]

作者: uniwg 时间: 26-11-2009 18:03
标题: 回复 #32 coredump 的帖子
我搞了一个破解版，但不大会用。

作者: uniwg 时间: 26-11-2009 18:08
标题: 回复 #20 AnaCoppola 的帖子
MYECLIPSE可以集成SVN，感觉操作team里面一些选项了，不要多研究这些细节。

作者: trisun 时间: 26-11-2009 18:18
用得最多的是 CLEARCASE，现在工作中用TFS，在家用CVS。
不过觉得最好用的还是CLEARCASE，特别是 treeview ,建branch 可以只对部分文件，不需要对整个project copy

作者: fred_au 时间: 26-11-2009 23:31
以前用cvs，现在用svn。
好像不怎么用什么高级功能，一般就这几个：
svn co http://blah/blah blah
改巴改巴
查看修改结果：
svn stat | grep ^M
svn diff > something.diff

上传到codestrike上供人review

提交，yeah
svn commit

有时候被抽中当猴子做merge
svn merge -c12345 http://blah/blah
svn merge -r123:456 http://blah/blah

貌似没试过其他什么别的功能了。。。。
conflunce我们也在用，有什么特别之处么？感觉和一般wiki差不多阿。。。

欢迎光临 FreeOZ论坛 (https://www.freeoz.org/ibbs/)