git-svn 是否支持每个子目录的不同修订版本？
我有一个当前正在使用 Subversion 的存储库，但我想在本地使用 Git。所以我用 git-svn 检查了它：
git svn clone http://localserver/svn/repo
现在，在 repo 中，我有几个目录：
repo/
trunk/
A/
B/
C/
tags/
branches/
存储库当前版本为 100。我想在 repo/trunk/B 中签出版本 90，然后创建一个整个存储库的标记，因此 repo/trunk/A 为 rev 100，repo/trunk/B 为 rev 90，repo/trunk/C< /code> 是 rev 100。
在 svn 中我会做
cd repo/trunk/B
svn update -r90 .
是否有使用 git-svn 的等效项，然后我可以制作一个标记来捕获当时整个存储库的状态吗？
我尝试了这个：
cd repo/trunk/B
git svn find-rev r90 # yields 18376729f51b71212d94dcba239a2482cda9f3c8
git checkout 18376729f51b71212d94dcba239a2482cda9f3c8 .
据我所知，repo/trunk/B中的文件已根据git status更改，但其他子目录中的文件没有更改。这是正确的方法，还是有更“正确”的方法？
I have a repository that is currently using Subversion, but I'd like to use Git locally. So I've checked it out with git-svn:
git svn clone http://localserver/svn/repo
Now, inside repo, I have a few directories:
repo/
trunk/
A/
B/
C/
tags/
branches/
The repository is currently at revision 100. I'd like to checkout revision 90 inside repo/trunk/B and then make a tag for the whole repo, so that repo/trunk/A is rev 100, repo/trunk/B is rev 90, and repo/trunk/C is rev 100.
In svn I'd do
cd repo/trunk/B
svn update -r90 .
Is there an equivalent using git-svn, and can I then make a tag that captures the state of the entire repository at that moment?
I tried this:
cd repo/trunk/B
git svn find-rev r90 # yields 18376729f51b71212d94dcba239a2482cda9f3c8
git checkout 18376729f51b71212d94dcba239a2482cda9f3c8 .
And as far as I can tell, the files in repo/trunk/B have changed according to git status, but files in other subdirectories have not changed. Is this the right way to go about it, or is there a more "correct" way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
正如您上面提到的，您可以使用 git checkout 手动对 trunk/B 中的文件执行此操作。不过，文件内容现在将显示为已修改，如果您运行 git commit，您将把旧文件的内容作为新文件重新提交。
这通常不是 git 的操作方式，而且我敢说这通常也不是你真正想要用 svn 做的事情。使用 git，您希望整个工作树同步移动，因此，大多数情况下不支持部分签出或将子树更新到不同版本。
当出现这种情况时，您应该问自己
A、B和C是否真的是不同的“项目”。当您标记时，是将它们标记在一起，还是将A的文件与B的文件分开标记？那么分支呢？我发现当您包含项目所需的所有文件但仅此而已时，git 存储库效果最好。将存储库限制在项目级别会增加一些簿记工作，但也有助于提高灵活性。这就是为什么您会在 StackOverflow 上看到许多讨论使用 git 子模块和子树（两个不同的概念）来管理存储库组的帖子。As you have mentioned above, you can use
git checkoutto do this manually for the files intrunk/B. The file contents will now show as modified, though, and if you rangit commit, you would be resubmitting the old files' contents as new files.This is generally not how git operates, and I'd venture to say that this is generally not what you really want to do with svn either. With git, you want the whole work tree to move together in lockstep, and as a result, support for partial checkouts or updating a subtree to a different version is nonexistent for the most part.
When this sort of scenario comes up, you should ask yourself whether
A,B, andCare really different "projects". When you tag, do you tag them together, or would you just tagA's files separately fromB's? What about branching? I've found that git repos work best when you include all the files that are necessary a project but no more than that. Limiting repositories to the project level increases some bookkeeping but also helps with flexibility. This is why you'll see many posts around StackOverflow discussing the use of git submodules and subtrees (two distinct concepts) for managing groups of repositories.