将git-svn与非常规的repo布局一起使用，其中包含应该可供任何分支机构访问的目录 [英] Using git-svn with an unconventional repo layout that includes a directory that should be accessible to any branches

问题描述

在我工作的地方，我们为项目使用了一个非常规的svn回购布局。它看起来像这样：

 项目/ 
 branches / 
 tags / 
 trunk / 
 utils / 
  

我们是一家非常小的公司，我们的大部分项目都相对较小。每个在项目上工作的开发人员通常会检查整个repo，并且有一些post-commit挂钩可以防止一次对多个分支进行更改。 utils文件夹包含一些对每个项目都有用的脚本，包括像首次执行回购时自动执行HOSTS和为开发者本地机器创建apache vhost指令等一些事情，几个svn快捷方式和一些特定项目的东西。

现在，我想使用git-svn，但我无法弄清楚如何添加开发人员可以访问的utils文件夹，而不管他们正在使用哪个分支将转换为git。

解决这个问题的唯一可能的方法就是将整个repo放到 git svn clone 中，然后为<$ c设置一些别名$ c> git svn fetch --ignore-paths 这样，如果我在特定分支上工作，我不会从其他分支获取更改，然后为每个远程创建本地主题分支分支。

这样做的缺点是大多数不得不设置这些别名 - 在我看来，这是一个有点难看的解决方案 - 但似乎至少应该起作用。至于使用 git-svn 的分支检测/集成功能，我不认为它可以在这里工作，因为检出一个分支是破坏性的，并且该utils文件夹存在于回购的顶层。

那么，是否有限制 git-svn 东西到代表当前分支的目录，或者一般处理这种情况的更简洁的方法？

我不'你的问题的主要部分有一个答案，但我可能有一个你必须使用--ignore-paths'设置别名的问题。

Where我工作，而不是做一个 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 rebase 和 git svn dcommit 推回到svn repo。

Where I work, we use a slightly unconventional svn repo layout for projects. It looks like this:

project/
  branches/
  tags/
  trunk/
  utils/

We're a pretty small company, and most of our projects are relatively small. Each developer working on a project usually has a checkout of the whole repo, and there are some post-commit hooks that prevent changes being made to multiple branches at once. The utils folder contains some scripts that are useful for each project, including things like automating HOSTS and apache vhost directive creation for a developers local machine when the repo is first pulled, a few svn shortcuts, and some project-specific stuff.

This layout works pretty well for us.

Now, I'd like to use git-svn, but I'm having trouble figuring out how the addition of that utils folder that is accessible to a developer regardless of what branch they're working on would translate into git.

The only possible way to deal with this that I've been able to figure out would be to git svn clone the whole repo, and then set up some aliases for git svn fetch --ignore-paths so that if I'm working on a specific branch, I wouldn't be fetching changes from other branches, and then create local topic branches for each remote branch.

The downside of doing this is mostly having to set up those aliases -- it's a somewhat ugly solution, in my opinion -- but it seems like it should work at least. As for using the branch detection/integration capabilities of git-svn, I don't think that it could work here because checking out a branch is "destructive", and that utils folder exists at the top level of the repo.

So, is there either a better way of restricting git-svn stuff to the directory that represents the current branch, or a cleaner way of handling this scenario in general?

解决方案

I don't have an answer for the main part of your question, but I might have one for your 'having to set up aliases with --ignore-paths' problem.

Where I work, instead of doing a git svn clone and getting everything, we do the following:

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

then we fetch from a reasonable point in the history:

git svn fetch -r 12345:HEAD

That way we get a shallow, narrow clone of the svn repository.

Then in the future we just need to do:

git svn fetch

to update the git svn repo before doing git rebase and git svn dcommit to push back up to the svn repo.

这篇关于将git-svn与非常规的repo布局一起使用，其中包含应该可供任何分支机构访问的目录的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！