设置 SVN 进行原子提交和限制访问
我们目前正在工作中进行讨论，我正在寻找一些有关 SVN 设置的建议。
我们的模式是，我们将各种项目签入 SVN，其中一些项目依赖于其他项目。例如 FooWebServices 依赖于 FooCommons。
如果我正在开发一个需要更改 FooWebServices 和 FooCommons 的功能，我希望能够在这两个项目之间进行原子提交。如果我搞砸了，并且 FooWebServices 的提交失败，那么整个蜡球就会失败。这样我就不会搞砸任何其他开发人员，也不会在追踪我遇到的任何问题时不得不返回更改。 CI 服务器似乎也经常感到困惑。
我可以对我们的存储库的根（然后是其下的 FooWebServices 和 FooCommons）进行浅层签出并获得此行为。然后我可以获得原子提交行为。
情况很复杂，因为我们还有承包商在储存库工作。目前他们无法检查 root 的浅表副本，因此他们无法获得该行为。
我想进行一些设置，以便承包商可以检查 root、FooWebServices 和 FooCommons，而不能检查其他任何东西。我还想阻止他们浏览根目录来查看我们未授予他们访问权限的项目。
这可能吗？我是否使问题过于复杂并且甚至不需要原子提交？
We're having a discussion at work currently and I was looking for some advice on SVN setup.
Our pattern is that we have a variety of projects checked into SVN, some of these projects depend on others. For example FooWebServices depends on FooCommons.
In the case where I'm working on a feature that requires changes in FooWebServices and FooCommons I want to be able to do an atomic commit across those two projects. If I've screwed up somehow and the commit fails for FooWebServices the whole ball of wax fails. That way I'm not screwing up any other devs or having to go back out changes while I track down whatever issue I had. The CI server also seems to be getting confused pretty frequently.
I can do a shallow checkout of the root (then FooWebServices and FooCommons under that) of our repo and get this behavior. Then I can get that atomic commit behavior.
The situation is complicated in that we have contractors also working in the repository. Currently they cannot check out a shallow copy of root so they can't get that behavior.
I'd like to set things up so that the contractors can check out root, FooWebServices, and FooCommons, and nothing else. I'd also like to prevent them from browsing root to seeing the projects we haven't granted them access to.
Is this possible? Am I overcomplicating the problem and atomic commits aren't even necessary?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为这太复杂了——而且是耦合的。
您不应该建立双向关系；不如果你这样做，你就会遇到更大的问题。 （在这种情况下，它们实际上只是一个项目。）
应该避免循环。通过适当放置的接口将它们分开。
对于相关项目来说，更好的方法可能是具有单向依赖关系。如果项目 A 依赖于 B，您可以处理项目 B，提交更改，然后创建一个添加到项目 A 的 JAR 文件。
这种方法的优点在于，对 A 的更改不需要强制部署 B；只需部署 B 即可。它可以通过继续使用旧的 JAR 来接受对 A 的更改，直到升级的时机成熟。
I think it's too complicated - AND coupled.
You should not have a bi-directional relationship; if you do, you've got bigger problems. (They really are just one project in that case.)
Cycles should be avoided. Break them up with well-placed interfaces.
A better approach for related projects might be to have a one-way dependency. If project A depends on B you can work on project B, commit changes, then create a JAR file that's added to project A.
The beauty of this approach is that changes to A need not force a deployment of B; it can accept changes to A when it can by continuing to use the old JAR until the time is right to upgrade.