代码之家 › 专栏 › 技术社区 › jdd

使用带有非常规回购布局的git svn,其中包括任何分支都应该可以访问的目录

git-svn git

jdd · 技术社区 · 16 年前

在我工作的地方,我们对项目使用稍微非传统的SVN回购布局。看起来是这样的:

project/
  branches/
  tags/
  trunk/
  utils/

我们是一家非常小的公司,我们的大部分项目都相对较小。在一个项目上工作的每个开发人员通常都有一个整个repo的签出,并且有一些提交后挂钩,可以防止同时对多个分支进行更改。utils文件夹包含一些对每个项目都有用的脚本,包括自动化主机和在首次提取repo时为开发人员本地计算机创建apache vhost指令、一些SVN快捷方式以及一些特定于项目的东西。

这个布局对我们来说很好。

现在,我想使用git-svn,但是我很难弄清楚添加的utils文件夹是如何被开发人员访问的,不管他们正在处理哪个分支,都会转换成git。

唯一能解决这个问题的方法就是 git svn clone 整个repo,然后为 git svn fetch --ignore-paths 因此,如果我正在处理一个特定的分支,我将不会从其他分支中获取更改,然后为每个远程分支创建本地主题分支。

这样做的缺点是 主要地 必须设置这些别名——在我看来,这是一个有点难看的解决方案——但看起来至少应该有效。关于使用分支检测/集成功能 git-svn ,我不认为它可以在这里工作,因为签出分支是“破坏性的”,而且utils文件夹存在于repo的顶层。

那么,有没有更好的限制方法呢? GIT-SVN 目录中表示当前分支的内容,还是处理此方案的更干净的方法?

3 回复 | 直到 10 年前

Mark Booth 15 年前

对于您的问题的主要部分,我没有答案,但是我可能会有一个答案来回答您的“不得不设置别名--忽略路径”问题。

我工作的地方,而不是 git svn clone 得到所有的信息,我们会做以下工作:

git svn init <Svn repo url> -T trunk -b branches --ignore-paths '(ignore1|ignore2)'

然后,我们从历史上的一个合理的角度来看:

git svn fetch -r 12345:HEAD

这样我们就得到了SVN存储库的一个浅而窄的克隆。

以后我们只需要:

git svn fetch

在执行之前更新git svn repo git rebase 和 git svn dcommit 向上推到SVN回购。

Peter Bratton 16 年前

我开始写一个关于如何向Gitsvn公开utils/作为分支区域的响应,然后意识到它根本不是一个分支;它是一个完全不同的项目。也就是说,此树下的代码与分支、标签和主干树下的代码不共享任何祖先。因为每个人都在检查整个存储库,所以我想知道合并对您来说是怎样的,但这是另一回事。

如果您在这里使用git svn,您可能可以像对待标准回购一样处理这个回购。您将拥有整个存储库,但一次只能使用一个分支(这似乎是您的提交挂钩强制执行的行为)。至于utils目录,您可以考虑为此创建一个单独的git svn repo。毕竟,不管怎样,您都不会将更改合并到该区域内外,所以除了需要定期更新另一个wc之外,您不会丢失任何其他内容。

祝你好运!

javabrett 10 年前

有史以来最新的答案,但是…

我反对竞选 git svn 与您的svn repo根 -s 转换或等价物,除非你真正知道这是你想要的。这将导致一个非常“un-git”的最终存储库,其中来自不同分支的代码将在您创建的每个git分支中重复。战栗 .

你要做的是使用 -S 标准布局选项,并让 GIT-SVN 做漂亮的工作,创造合适的分支和它们的历史。

关于 utils ?它的位置和您对它的描述表明它是一个独立版本的结构。它中的更改独立于每个分支上发生的更改,否则它将存储在每个分支上。要将它引入Git,您应该首先为这个目录创建一个单独的Git克隆。然后,您有两个选择:您可以a)决定现在将它保存在Git中的每个分支中,只需将它签入您关心的每个分支的头中。您可能需要修复和重新标记旧的/重要的标签。或者b),把它作为一个独立版本的git子模块引入git,这看起来就是它。然后,您可以在每个分支中使用它,但要集中地使用它。你当然需要更新你的脚本来解释新的位置。 ./utils 不 ../utils .