git 和 cvs 比单独的 cvs 更快吗?

发布于 2024-07-10 12:18:56 字数 342 浏览 5 评论 0原文

我的团队在 cvs 中处理一个包含大约 20,000 个 Java 文件的项目。 由于文件数量较多,执行 cvs 更新需要一段时间。 我通常会签出整个树的大约 5 个副本,以便轻松签入不同的请求,而不必担心每个请求修改了哪些文件。 让所有 5 棵树保持最新状态并相互同步是一件非常痛苦的事情。

我读到,在本地使用 git 与远程 cvs 服务器相当容易,而且 git 速度很快。 git 会显着加快本地树的更新速度吗?

我意识到下限是进行一次 cvs 更新的时间。 但我认为,一旦第一棵树是最新的,就可以快速将其他 4 棵树与第一棵树同步,而不是再执行 4 个 cvs 更新命令。 我对git的理解正确吗?

My team works on a project in cvs containing about 20,000 Java files. Because of the number of files, it takes a while to do a cvs update. I typically keep about 5 copies of the entire tree checked out, to make it easy to check in different requests without worrying about which files were modified for each. It's a real pain to keep all 5 trees up to date and in sync with each other.

I've read that it's fairly easy to use git locally with a remote cvs server, and that git is fast. Will git significantly speed up the updating of my local trees?

I realize the lower bound is the time to do one cvs update. But I'm thinking that once the first tree is up to date, it might possible to quickly sync the other 4 with the first, rather than to do 4 more cvs update commands. Do I understand git correctly?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

夜灵血窟げ 2024-07-17 12:18:57

我在一个大型项目(大约 10k 个文件)中使用 Git 作为 Subversion 客户端。 Git 很快,真的很快。 它是如此之快,以至于我只保留一个工作克隆,并在同一克隆内的功能分支之间切换。 和你一样,当我使用 Subversion 时,我会进行两到三个类似的检查,并且会定期在它们之间切换,因为我同时进行多项操作。 有时确实很令人困惑。 借助 Git 的轻量级分支、存储和“git add -p”等功能,我发现我不再需要多次签出。 我可以在一个目录中完成所有操作,而不必太担心丢失我忘记或意外覆盖的更改。

我还没有将 Git 与 CVS 一起使用,但是如果它的集成类似于 git-svn 那么那就没有问题了。

I use Git as a Subversion client on a large project (on the order of 10k files). Git is fast, really fast. It's so fast that I only keep one working clone, and switch between feature branches within that same clone. Like you, when I used Subversion I would have two or three similar checkouts and would switch between them regularly as I had multiple things in progress simultaneously. It got to be pretty confusing sometimes. With Git's features like lightweight branches, the stash, and "git add -p", I find that I no longer need multiple checkouts. I can do everything in one directory, and not worry as much about losing changes that I either forgot about or accidentally overwrote.

I haven't used Git with CVS, but if its integration is anything like git-svn then it's going to be no problem.

若相惜即相离 2024-07-17 12:18:56

我们在工作中也做类似的事情。 我们基本上使用 git 中的 master 分支作为代码的单个更新的 CVS 版本; 我们在那里不进行任何开发,只是进行 CVS 更新。 然后,我们所有的开发项目都发生在我们变基的功能分支上。 当我们在 master 分支上进行 CVS 更新时,我们会将这些更改提交到 master,然后根据 master 重新调整其他开发分支的基础。

这并不理想——它使得与其他人共享分支变得困难。 但是,我们可以同时管理多个开发项目,并轻松地对它们进行分支、合并和比较。 而且,我们仅根据需要与一个 master 分支上的 CVS 交互。

We do something similar at work. We basically use the master branch in git as a single, updated CVS version of the code; we don't do any development there, just CVS updates. Then, all of our development projects happen on feature branches that we rebase. When we do CVS updates on the master branch we commit those changes to master and then rebase our other development branches against master.

It's not ideal -- it makes sharing branches with other people difficult. But, we can manage several development projects at once and do branches, merges, and diffs against them easily. And, we only interact with CVS on the one master branch, as needed.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文