转变“CVS时代”回购到带有子模块的 git 回购协议中

发布于 2025-01-06 05:44:45 字数 1206 浏览 0 评论 0原文

我们有一个非常大的古老扁平 CVS 存储库,其示例格式如下。我已将每个子目录导入为自己的 git 存储库,并具有完整的历史记录。

.
├── liba
├── libb
├── libc
├── prog1
├── prog2
└── prog3

假设这 3 个程序按以下方式使用库:

.
├── prog1
│   ├── liba
│   └── libb
├── prog2
│   ├── libb
│   └── libc
└── prog3
    ├── liba
    └── libc

因为 CVS 允许标记树的一部分 - 我们使用版本标记来标记每个库和程序版本。例如liba_4x23prog3_2x22

我们还使用发布时使用的每个版本的库来标记程序(即 liba_3x19 libc_7x88

如果我们发布了没有库标签的程序的新版本 - 标签将保留使用的程序的最早版本。
现在由于 git import 的工作方式 - 它实际上最终得到了程序的最新版本(不过不用担心)

Git 子模块似乎是一个非常好的解决方案 - 可以签出程序的版本它将所有正确版本的库作为子模块引入。

现在,由于所有当前程序都位于不同版本的库中 - 我需要在特定版本上改造子模块。

  • prog1libb_4x50 链接
  • prog2libb_4x70 链接

假设 libb_4x70 是最新版本那么 prog2 的例子很简单

git checkout prog2
cd prog2
git submodule add libb
.... done

那么如何添加带有版本(未分支)4x50 标记的 libbprog1

如果您有更好的想法,我们将不胜感激:-)

我们可能还想做的是返回程序的 3 个版本并为每个版本设置适当的子模块。既可以向后兼容,也可以作为管理人员如何工作的示例。

We have a very large ancient flat CVS repo with an example format as below. I have imported each subdir as its own git repo with full history.

.
├── liba
├── libb
├── libc
├── prog1
├── prog2
└── prog3

Lets say that the 3 programs use libraries in the following way:

.
├── prog1
│   ├── liba
│   └── libb
├── prog2
│   ├── libb
│   └── libc
└── prog3
    ├── liba
    └── libc

Because CVS allows tagging part of the tree - we tag each library and program release with a version tag. eg liba_4x23, prog3_2x22.

We also tag the program with every version of library it uses at release (ie liba_3x19 libc_7x88)

If we release a new version of the program without a library tag - the tag stays the earliest version of the program it was used.
Now due to the way the git import works - it actually ends up at the latest version of the program (not to worried about that though)

Git submodules seem to be a very good solution for this - a version of a program can be checked out and it pulls in all the right version of libraries as submodules.

Now since all current programs are at different releases of libraries - I would need to retrofit a submodule at a particular version.

  • prog1 is linked with libb_4x50
  • prog2 is linked with libb_4x70

Assuming libb_4x70 is latest version then the example of prog2 is easy

git checkout prog2
cd prog2
git submodule add libb
.... done

So how to add libb tagged with version (not branched) 4x50 to prog1?

Other advice appreciated if you have a better idea :-)

What we may also want to do is go back 3 version of the program and set the appropriate submodules for each version. For either backwards compatibility and also as an example to management on how it will work.

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

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

发布评论

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

评论(1

橘虞初梦 2025-01-13 05:44:45

子模块的想法(如此处解释)是在父模块中记录特定提交回购。

因此,您需要做的就是在添加 libb 后,签出正确的标签,然后在父存储库中记录该新状态:(

git checkout prog1
cd prog1
git submodule add libb
cd lib
git checkout libb_4x50 # make sure to make a branch 
                       # if you want to do any modification
                       # based on libb_4x50,
cd ..
git add -A .
git commit -m "fix correct libb version"

对于“分离的 HEAD ” 评论,请参阅“git 子模块更新 * 删除未提交的文件 ”)

The idea of submodules (as explained here) is to record a specific commit within a parent repo.

So all you need to do is, after adding libb, to checkout the right tag, and then to record that new state within the parent repo:

git checkout prog1
cd prog1
git submodule add libb
cd lib
git checkout libb_4x50 # make sure to make a branch 
                       # if you want to do any modification
                       # based on libb_4x50,
cd ..
git add -A .
git commit -m "fix correct libb version"

(For the "detached HEAD" comment, see "git submodule update * deletes uncommitted files")

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