我可以拥有一个既是 git 工作区又是 svn 工作区的工作区吗？
我现在已经检查了位于 svn 存储库中的代码库的本地工作副本。这是一个我使用 Eclipse 进行开发的大型 Java 项目。当然，Eclipse 以它自己的方式动态构建所有内容，所有二进制文件最终都在 [project root]/bin 中。对于开发来说，这对我来说完全没问题，但是当构建在构建服务器上运行时，它看起来有很大不同（maven 构建、二进制文件最终位于不同的目录结构中，等等）。
有时我需要在本地开发系统上重新创建构建服务器环境来调试构建或您拥有的东西，因此我通常最终将全新的工作副本下载到新的工作区中并从那里运行构建（防止混乱我的开发工作区）与所有构建工件并弄脏工作副本）。当然，有时我有兴趣在我还不想签入的代码上运行完整的构建，因此我将手动将“开发”工作区复制到“构建”工作区。除了花费大量额外时间复制许多我实际上不需要的文件（只是将新文件覆盖在旧文件上）之外，这也搞乱了我的 svn 元数据，这意味着我无法检查“构建”中的更改工作区”工作副本，我经常最终不得不重新下载代码以使其恢复到已知状态。
所以我想我将我的 svn 工作副本制作为本地 git 存储库，然后将 svn 工作副本/git master 中的开发中代码“签出”到本地构建工作区中。然后我可以构建、恢复我的更改，并在构建工作区中拥有版本控制工作副本的所有优点。然后，如果我需要对构建进行更改，请将它们推回 git master（这也是一个 svn 工作副本），然后将它们签入主 svn 存储库。
|-------------|
|main svn repo| <------- |---------------------|
|-------------| |svn working copy | <------- |--------------------|
| (svn dev workspace/ | | non-svn-versioned |
| git master) | | build workspace |
|---------------------| | (git working copy) |
|--------------------|
将所有内容都切换到 git 显然会更好，但是，大公司，太多人使用 svn，更改所有内容成本太高，等等。我们现在坚持使用 svn 作为主要存储库。
顺便说一句，我知道 Eclipse 有一个 Maven 插件，我主要想知道是否有一种方法可以维护一个既是 git 工作副本又是 svn 工作副本的工作空间。实际上任何分布式版本控制系统都可能工作（hg 可能吗？）。建议？其他人如何处理这种必须管理“开发”构建过程和“生产”构建过程的情况？
I have checked out now a local working copy of a codebase that lives in an svn repo. It's a big Java project that I use Eclipse to develop in. Eclipse of course builds everything on the fly, in it's own way with all the binaries ending up in [project root]/bin. That's perfectly fine with me, for development, but when the build runs on the build server, it looks quite a lot different (maven build, binaries end up in a different directory structure, etc).
Sometimes I need to recreate the build server environment on my local development system to debug the build or what have you, so I usually end up downloading an entirely new working copy into a new workspace and running the build from there (prevents cluttering my development workspace with all the build artifacts and dirtying up the working copy). Of course sometimes I'm interested in running the full build on code that I don't want to check in yet, so I will manually copy over the "development" workspace onto the "build" workspace. Besides taking a lot of extra time copying a lot of files that I don't actually need (just overlaying the new over the old), this also screws up my svn metadata, meaning that I can't check in changes from that "build workspace" working copy, and I often end up having to re-download the code to get it back into a known state.
So I'm thinking I make my svn working copy a local git repo, then "check out" the in-development code from the svn working copy/git master, into the local build workspace. Then I can build, revert my changes, have all the advantages of a version controlled working copy in the build workspace. Then if I need to make changes to the build, push those back into the git master (which is also a svn working copy), then check them into the main svn repo.
|-------------|
|main svn repo| <------- |---------------------|
|-------------| |svn working copy | <------- |--------------------|
| (svn dev workspace/ | | non-svn-versioned |
| git master) | | build workspace |
|---------------------| | (git working copy) |
|--------------------|
Just switching everything to git would obviously be better, but, big company, too many people using svn, too costly to change everything, etc. We're stuck with svn as the main repo for now.
BTW, I know there is a maven plugin for Eclipse and everything, I'm mainly interested to know if there is a way to maintain a workspace that is both a git working copy and an svn working copy. Actually any distributed version control system would probably work (hg possibly?). Advice? How does everybody else handle this situation of having to manage both a "development" build process and a "production" build process?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
将 git repo（svn repo 的副本）克隆到另一个 git repo 的想法是可行的。
从 Git1.7.0 开始，您可以将此方法与稀疏结帐 如果您不想从第一个 Git 存储库中签出所有内容。
The idea of cloning a git repo (copy of a svn repo) into another git repo can work.
Since Git1.7.0, you can associate this approach with sparse checkout if you do not want to checkout everything from your first Git repo.