0

正如标题所说,我正在寻找 CVS 的替代品。基本上,我无法在 CVS 服务器上持续设置 a,到目前为止,我的团队使用的当前设置是共享目录。

考虑到这一点,我正在寻找具有版本跟踪和文件合并功能的东西,其中我不需要在服务器上不断设置。

我在想,是否有类似 CVS 的设置,其中存储库只是一个共享网络资源(文件夹、驱动器等),用户将连接到存储库,签出他们自己的本地副本。用户所做的任何更改都只会存在于他们的本地副本上,直到他们提交更改,在此之前更改将被推送到存储库。如果发现任何冲突,它们会像在 CVS 上一样进行处理。

此外,如果它可以与 Eclipse 作为插件一起使用,那将是一个额外的好处,因为这是我们团队现在正在使用的。

TIA

4

5 回答 5

3

Git是你最好的朋友。分布式、健壮且速度惊人!对于您的 Eclipse 集成,请尝试EGit

于 2012-07-26T18:10:02.117 回答
2

SVN的口号是“CVS 做得对”,所以在使用 CVS 之后很容易得到 SVN 的哲学。

但是,有些人说“没有办法正确地进行 CVS”并建议使用Git。Git 更先进,并提供了一些很酷的功能,如分布式版本控制和轻量级分支,但学习过程更加困难。

PS我使用Git,我很满意!

于 2012-07-26T18:15:34.510 回答
2

常用且支持良好的版本控制系统包括 Git、SVN 和 Mercurial。其中,我自己使用过 SVN 并运行了一些 repos,但人们倾向于说 Git 和 Mercurial 更易于使用。

您可以获得一个用于 Eclipse 的 SVN 插件,称为subclipse

其他人可能也有,但我不知道。

于 2012-07-26T18:11:05.933 回答
2

我看不出你不能继续使用 CVS 的任何强有力的理由。如果您有一个可见的“共享网络资源”,就好像它是一个普通的文件系统(用户可以读取、创建和写入文件),您可以将您的 CVS 存储库放在那里并$CVSROOT适当地设置您的用户。或者,您可以设置具有 ssh 访问权限的 Linux 或其他类 Unix 系统;CVS 在 ssh 上运行良好。

如果您能够拥有共享目录,则可以使用 CVS。

有很多理由比 CVS 更喜欢其他系统(就我个人而言,我已经成为 Git 的忠实粉丝),但听起来你不需要立即切换。

我的建议:考虑从 CVS 切换到 Git,但这并不紧急。

快速的 Google 搜索表明 Eclipse/CVS 集成应该不是问题。

于 2012-07-26T21:23:21.667 回答
1

我同意 Keith Thompson 关于继续使用 CVS 的说法,但是,基于通过实际尝试 git 两周完成的对 DVCS 的审查,我不能推荐 git 作为经验丰富的 cvs 用户的平滑替代品,他们希望以最少的速度平稳过渡到 DVCS再培训。重新阅读最后一句,同时特别注意限定条款。我并不是说 git 有能力成为一个优秀的工具。虽然个人经验通常是非常主观的,但 git 在确定使用两周后从未“感觉到”,以便学习它作为 CVS 的潜在替代品。在尝试它的过程中,我设法把事情(想想存储库)搞砸了好几次,有些事情我从来没有迅速弄清楚。

当我碰到 git 无法对目录进行版本控制的墙时,我将 Mercurial 和 Bazaar 视为最有可能考虑的候选者,并发现 Mercurial 与 git 有相同的问题。在 CVS 中,我可以轻松地添加包含现有文件的目录,而无需在其中添加文件。git 和 Mercurial 似乎这样做是一件荒谬的事情。该工具要求我无法在各种用例中做有意义的事情,这让我很困扰。结果,我尝试了 Bazaar,令人惊讶的是,我在几分钟内就感到很舒服。使用 git 两周后,我从来没有这样做过。我的 git 存储库在几分钟内转换为 Bazaar,并且我在不到一个小时的时间内就可以轻松使用它。

我目前仍在使用 CVS,尽管我已承诺使用 Bazaar,但我在一些边缘情况下遇到了烦恼,我在应用程序中使用 Bazaar,而这些应用程序在软件开发中通常不是问题。即便如此,作为最有可能在替代 VCS 中培训一组 CVS 同事的人,我坚信 Bazaar 将需要最少的再培训。在与 CVS 工作流程密切相关的工作流程中使用 Bazaar 几乎是微不足道的。与我一起工作的人不会通过版本控制来获得乐趣。他们想要一些不引人注目且易于学习的东西。我知道,如果他们发现学习曲线最令人生畏,他们就不会最大限度地利用 VCS。

选择 Bazaar 的重要之处在于它可以轻松地在 Windows 上运行,并与 MinGW MSYS 环境很好地集成。集成的 Windows 安装程序非常适合希望以统一方式最小化设置工作站的工作的环境 - 特别是在一些用户需要命令行工具而其他用户需要图形工具的情况下。

VCS 的选择通常会受到各种偏见的影响。我开始寻找 DVCS,而不会对任何特定工具产生偏见。我发现 git 天生就有偏见。它是在对 CVS 的强烈仇恨(参见作者对 CVS 的态度)和 CVS 之类的东西 $Id: $ 的情况下开发的。Bazaar 声称它试图避免对各种工作流程的偏见,并且似乎避免对开发人员在他们对其他 VCS 的特定使用中开始欣赏的事物采取立场。诚然,这是一个主观的说法,但我在 Bazaar 的经验似乎表明这是真的。

Bazaar 没有提供我想要的一切。例如,我不高兴它不支持部分结帐。这在 CVS 中非常容易做到。我对 Bazaar 操作完全因文件访问问题而失败而感到恼火,因为一组文件中的单个文件正在被操作,但这通常不应该发生在典型的软件开发用例中。我想说的是,我并没有盲目地迷恋 Bazaar,但我仍然相信它是小型工程部门从 CVS 过渡到最简单的工具。

作为一个脚注,多年前加入了一个 SVN 开源开发团队,其明确目标是适应类似 CVS 的改进 VCS。我与 SVN 合作了很多,甚至设置了部分结帐等,但我不同意 SVN 是“CVS 做得对”。经过多年的使用,由于多种原因,我无法负责任地选择 SVN 作为我组织中 CVS 的继任者。它将一组问题换成另一组问题。虽然这对于几乎所有工具都是如此,但在考虑过渡成本时,SVN 的好处似乎并没有超过问题。

于 2012-08-23T15:58:05.287 回答