问题标签 [git-svn]

我已经对我的整个 repo 进行了 git-svn checkout（以标准git svn init -t tags -b branches -T trunk $repo_url方式初始化，然后git svn fetched）。我手动svn copy $repo_url/branches/branch1 $repo_url/branches/branch2。然后我跑了git svn fetch，，git checkout -b local-branch2 branch2做了一些提交branch2，dcommit将它们编辑回 SVN 存储库，并完成了我的工作branch2。（为什么要分支一个分支？我想在 git 中本地破解这个分支，但仍然提交回 SVN 并在我工作时从几个同事那里获得帮助）。

我没有做的是将branch2工作合并回branch1. 如果 I git checkout -b local-branch1 branch1, then ，它只是将我的指针git merge branch2快进到 where is。local-branch1branch2

相反，我希望 git 重放自开始branch2到 branch1 以来所做的所有提交，以便我可以将它们中的每一个提交到 SVN 存储库。似乎有办法做到这一点，但我想不出。也许git rebase，或者git cherry-pick每个提交的一个branch2？（虽然后者有点乏味）。我宁愿不要 svn 将这两个 URL 合并在一起，因为那会造成很大的伤害。

想法？这其中的任何部分需要更多解释吗？

我有一个奇怪的布局的颠覆回购：

树干

标签

分支机构

我知道，我知道，这很愚蠢。我应该在每个项目下都有一个主干、标签和分支目录。但是，无论如何将其转换为具有历史记录的 git（针对特定项目）？

大多数 git-svn 教程都采用标准布局，并没有涵盖这种特殊情况。

谢谢！

我现在正在使用带有以下工作流程的 git-svn

随后当我处理一个功能时

现在，当我将功能 git 合并到 master 上时，需要注意一些要点，featureZ 分支中的所有单独提交都会合并为一个，这对我来说很好。

提交消息被替换为“与 featureZ 合并”。这可以通过merge fmt msg来解决。

现在我的问题是这个工作流程是否有任何问题或需要注意。我在git-svn 手册中读到使用git svn时不应该进行合并。我在工作流程中所做的是他们所指的吗？如果是这样会导致什么样的问题？一件事是我不想做一些与 SVN 主线混淆的事情。

当 git svn fetch 在我的 Subversion 存储库中找到分支时，我看到它反复检索相同的 Subversion 修订。我们使用标准的 Subversion 存储库布局，具有顶级 /trunk、/tags 和 /branches 目录（并且 git 存储库是使用 'git svn init -s' 创建的）。但是，有问题的分支通常是从主干内的子目录而不是主干创建的副本。

git svn fetch 输出通常如下所示：

我们回到修订版 1。 git svn fetch 然后继续获取修订版，直到它到达创建分支的修订版。

我究竟做错了什么？无论如何我要告诉 git svn fetch 不要检索它已经提取的修订版？

这个问题类似于this one和this one，但场景稍微复杂一些。

几年前我开始使用私有 svn 存储库（我主要用于在各种机器之间共享配置文件等）。我对存储库的布局（分支、转到等）不太小心，因此随着时间的推移它发生了很大变化。当然，这是一个错误，但现在为时已晚。最近，我将它迁移到更标准的 svn trunk/branches/tags 布局，主要使用 svn move 命令，但当然旧的历史仍然存在于存储库中（坦率地说，有点乱） .

我现在想将其永久转换为 git 存储库。我尝试过使用 git-svn，但它似乎只处理遵循一致的主干/分支/标签约定的情况（是的，您可以提供替代名称，但似乎每个名称只有一个）。我的存储库的很多历史记录都有效地位于存储库的根目录中，例如，标签/和分支/作为子目录。

处理这一切的最佳方法是什么？理想情况下，我希望我最终得到的 git 存储库至少可以以某种方式访问​​所有历史记录，即使分支和标签在 git 中没有正确表示为一流的概念。

更具体地说，svn-git 将如何处理它提供的 trunk/branches/tags 子目录之外的文件？到目前为止，我的观察是它有时会遗漏它们（绝对不行），而有时会将它们添加到新的存储库中。

任何想法将不胜感激。

我正在尝试使用 git-svn 创建一个 svn 分支。存储库是用--stdlayout. 不幸的是，它会生成一个错误，指出“源和目标似乎不在同一个存储库中”。该错误似乎是由于它不包括源网址中的用户名。

$ git svn branch foo-as-bar -m "尝试把 Foo 变成 Bar。"

将 r1173 处的 svn+ssh://my.foo.company/r/sandbox/foo/trunk 复制到 svn+ssh://svnuser@my.foo.company/r/sandbox/foo/branches/foo-as-bar ...

尝试使用不受支持的功能：Source 和 dest 似乎不在同一个存储库中（src: ' svn+ssh://my.foo.company /r/sandbox/foo/trunk'; dst: ' svn+ssh: //svnuser@my.foo.company /r/sandbox/foo/branches/foo-as-bar') 在 /home/me/.install/git/libexec/git-core/git-svn 第 610 行

我最初认为这只是一个配置问题，检查.git/config并没有表明任何不正确的地方。

我正在使用git version 1.6.3.3.

谁能解释为什么会发生这种情况，以及如何最好地解决它？

几周前，我在 git上观看了 YouTube 演示技术讲座：Linus Torvalds ，其中一句话似乎一直萦绕在我的脑海中。

在这个演示文稿中（大约 33 分钟），Linus 说了类似“有些人克隆一个 SVN 存储库，进行合并（=在 SVN 中的头痛），然后将结果推送回 SVN。”。

我的想法是：如果这是可能的，那我们为什么不将GIT的强大合并能力移植到SVN中呢？

这样，我们对 SVN 有了很大的增强，并且我们不必迁移我们的公司存储库和相关脚本，这些脚本与各种问题跟踪和持续集成系统挂钩。

我肯定错过了什么。它是什么？

我正在使用严格的签入策略在 subversion 存储库中开发一个项目，其中包括：对主干的每个提交都必须由另一个开发人员审查，并且必须在提交消息中提及。

在使用 git-svn 时，我正在做许多未经审查的增量 git 签入。他们的 git commit 消息反映了这一点。

使用 git-svn 但遵循 svn 存储库规则的最佳方式是什么？我应该将所有提交压缩成一个 svn 提交吗？我可以用审阅者信息重写每个修订的提交消息吗？我可以“手动”将每个单独的更改移动到 git master 分支并在执行 git-svn dcommit 之前修改每个更改的提交消息吗？

我有一个项目存在于两个 SVN 存储库中。第二个 SVN 存储库是通过从旧 SVN 存储库的签出中添加存储库而简单地创建的，而没有剥离 SCM 信息。文件的内容字节相同，但没有关联的 SCM 元数据。

我采用了新的 SVN 存储库并通过 git-svn 将其移植到 Git 存储库中。现在我想导入旧存储库并以某种方式让它链接新存储库，这样我就可以看到两者的历史记录。有没有一种简单的方法可以在不将两个存储库手动拼接在一起的情况下做到这一点？

Git-svn 允许将重复的文件名（只是大小写不同）添加到我们的 subversion 存储库中。

在 Windows 上，这意味着 subversion 无法签出文件，抱怨重复。

另一位开发人员从存储库中删除了错误大小写的版本。现在，当尝试执行 git-svn rebase 时，我收到“无法分离 HEAD”消息，并抱怨有问题的文件名未被跟踪且需要被覆盖。删除文件会使 git-svn 抱怨文件需要更新。

将存储库复制到具有区分大小写文件系统的机器的唯一解决方案是执行变基然后将其移回吗？

我知道 git-svn 还没有准备好在 Windows 上进行实际工作，但我想从它造成的混乱中恢复过来。