人们如何管理对多个 (Mercurial) 存储库中存储的通用库文件的更改?

发布于 2024-08-16 08:52:48 字数 377 浏览 5 评论 0原文

这也许不是 Mercurial 独有的问题,但这是我最近使用最多的 SCM。

我从事多个项目,并且倾向于从以前的项目中复制库或实用程序的源代码,以便在启动新项目时占据优势。当我想将我在最新项目中所做的所有更改合并回这些共享库文件的“主”副本时,问题就出现了。

由于存储在不相交存储库中的文件将具有不同的版本历史记录,因此如果我只是将文件复制回主存储库(甚至在两个独立项目之间),Mercurial 将无法执行智能合并。

我正在寻找一种简单的方法来保留更改历史记录,以便我可以将库文件合并回主文件,同时保留最少的外部记录(这是我较少使用 SVN 的原因之一,因为合并需要记住副本的时间)跨分支制作)。

也许我需要对我的存储库进行更多的前期组织,以便为将来合并回公共母版做好准备。

This is perhaps not a question unique to Mercurial, but that's the SCM that I've been using most lately.

I work on multiple projects and tend to copy source code for libraries or utilities from a previous project to get a leg up on starting a new project. The problem comes in when I want to merge all the changes I made in my latest project, back into a "master" copy of those shared library files.

Since the files stored in disjoint repositories will have distinct version histories, Mercurial won't be able to perform an intelligent merge if I just copy the files back to the master repo (or even between two independent projects).

I'm looking for an easy way to preserve the change history so I can merge library files back to the master with a minimum of external record keeping (which is one of the reasons I'm using SVN less as merges require remembering when copies were made across branches).

Perhaps I need to do a bit more up-front organization of my repository to prepare for a future merge back to a common master.

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

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

发布评论

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

评论(3

迷途知返 2024-08-23 08:52:48

三种解决方案,选择您最喜欢的:

  1. 将所有项目放入一个存储库中。
  2. 为共享代码创建一个单独的存储库,并为每个项目创建不同的存储库。
  3. 一个包含子存储库的存储库:https://www.mercurial-scm.org/wiki/subrepos,将所有公共代码保留在一个子存储库中,并为每个项目保留不同的子存储库。

在没有共同祖先的存储库之间复制实际文件永远不会是最佳选择,因为不会保留历史记录。

Three solutions, pick your favorite:

  1. Put all projects into one repository.
  2. Make a separate repository for shared code and different repository for each project.
  3. One repository with Subrepositories: https://www.mercurial-scm.org/wiki/subrepos, keep all common code in one subrepo and different subrepos for each project.

Copying actual files between repositories with no common ancestors will never be optimal as history is not preserved.

爱格式化 2024-08-23 08:52:48

我建议您不要“复制源代码”做法,而是对自定义库使用二进制分发。这些二进制文件与源代码一起签入。

  • 减少构建时间
  • 无需跟踪库的所有副本中的更改的开销
  • 您可以在不同的项目中使用同一库的不同版本。

编辑:对于一般“通用”或“工具箱”库的问题,请阅读 这篇文章来自 ayende。

I'd recommend against your "copy the sourcecode" practice but use binary distribution for your custom libraries instead. These binaries are checked in along the sourcecode.

  • reduces build-time
  • no overhead of tracking changes in all copies of the library
  • you can use different versions of the same library in different projects.

EDIT: And for the issue with "common" or "toolbox" libaries in general, read this post from ayende.

梦里兽 2024-08-23 08:52:48

使用移植扩展

use the transplant extension

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