SVN：只读存储库的分支？
我可以访问某个项目的只读 SVN 存储库。
我想通过我自己的修改/添加来扩展这个项目。如果我可以完全访问此存储库，我可以简单地创建自己的开发分支。但是，我没有（也不会获得写访问权限）。
我希望将我的修改存储在（内部）存储库中，以便我可以跟踪自己的开发。
是否可以使用 SVN 建立一个可以处理这个问题的结构？
最初我正在考虑创建一个（内部）SVN 存储库，其结构如下：
trunk
- 包含使用 svn:externals 的外部存储库的副本
branch
- 我的基于主干的开发分支
但是，我很快发现基于“外部”文件夹创建分支并不简单（如果不是不可能的话？）。 我还希望能够将外部存储库中的更改合并到我自己的开发分支中。我也怀疑使用这种结构是否可能。
是否有可能让这个建筑发挥作用？或者我应该以完全不同的方式处理这个问题？非常感谢有关此问题的任何建议。
谢谢
彼得
I have access to a read-only SVN repository of a certain project.
I want to extent this project with my own modifications/additions. If I had full access to this repo, i could simply make my own development branch. However, I have not (and won't get write access).
I would like to have my modifications stored in an (internal) repository so I can keep track of my own developments.
Is it possible to set up a construction using SVN that can deal with this?
Initially I was thinking about creating an (internal) SVN repository with a the structure as below:
trunk
- containing a copy of the external repo making use of svn:externals
branch
- my development branch based upon the trunk
However, I quickly found out that it is not straightforward (if not impossible?) to create a branch based upon an 'external' folder.
I also want to be able to merge changes in the external repository into my own development branch. I also doubt whether this is possible using this construction.
Is it possible to get this construction working? Or should I deal with this in a completely different way? Any advice on this issue is greatly appreciated.
thanks
peter
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你在“谁在哪里”中犯了一个小错误
你自己的开发发生在主干中（最初 从分支（供应商分支）合并到主干的时间
此方法对于大型和复杂的上游项目有一些限制，但适用于小型|中型项目
You made small mistake in the are "Who Where"
From time to time you merge from branch (vendor-branch) to trunk
This method have some limitations for big and complex upstream-projects, but works on small|mid-sizes
是的，你可以。作为选项之一，可以使用 svnsync 复制远程存储库。但我不建议这样做，因为当您尝试合并本地存储库和远程存储库中的更改时，您会遇到麻烦。
看来您的情况非常适合使用
git-svn。它将允许使用您的本地存储库进行自己的修改/添加。问题是，您将能够使用本地 git 存储库（执行推送和拉取）跟踪自己的开发，并从远程 svn 存储库获取更改（执行更新）当你需要它的时候。但是，当然，您仍然无法提交到远程 svn 存储库，因为它具有只读访问权限。这是 关于 git-svn 的简短教程。
Yes, you can. As one of the options, it is possible to duplicate remote repository using svnsync. But I wouldn't recommend doing this because you will get into trouble when will try to merge changes in your local repository and remote repository.
It seems that your case is perfect for using
git-svn. It will allow to use your local repository for your own modifications/additions. The thing is that you will be able to keep track of your own developments using localgitrepo (doing pushes and pulls) and get changes (doing update) from remotesvnrepo when you need it. But, of course, you still will not be able to commit to the remotesvnrepo because it has read-only access.Here is a short tutorial on git-svn.
就我个人而言，我也会使用 svn:externals，但我会以不同的方式设置我的存储库
（等等）
。所有“theircode”分支都可以轻松地通过 svn 外部绑定到他们的存储库（他们的版本号）。我不会将对整个主干的控制权交给外部存储库，因为如果您决定需要将主干移动到某个方向，那么您就会被绑定在错误的位置到您无法直接控制的存储库。是的，你可以重组，但很可能当你需要做其他重要的事情时，你需要进行重组，这意味着可用时间更少，压力更大。
如果您必须“修补”他们的代码，请将其放在“您的代码”分支中，并扩展您的构建系统以将其代码复制到“源”构建区域中。然后应用补丁。不要就地修改他们的代码，这会在许多级别上自找麻烦，包括许多级别，这些级别直到为时已晚时才显现出来。
Personally, I would use svn:externals too, but I would set up my repository differently
(and so on)
All of the "theircode" branches can easily be bound through svn external to their repository (their rev number). I wouldn't give away control over the entire trunk to an external repository, because if you decide you need to move your trunk in a certain direction you are bound in the wrong place to a repository you don't have direct control over. Yes, you could restructure then, but odds are you'll need to do that restructuring right when you need to do something else important, which means more pressure under less available time.
If you must "patch" their code, put that in the "your code" branch and extend your build system to copy their code into a "sources" build area. Then apply your patches. Don't modify their code in place, it's asking for trouble on many levels, include lots of levels which aren't apparent until it's too late.