Subversion 是否支持分支别名
subversion 中是否有一种方法可以指定特定路径是不同路径的别名，并且能够在条件发生变化时更新该别名？我可以锁定路径以防止路径发生更改吗？
我正在研究存储库结构，我想做的是具有以下路径：
- /versions/1.0 - 先前版本（已锁定）
- /versions/1.1 - 先前版本（锁定）
- /versions/1.1.1 - 当前版本（解锁用于补丁开发）
- /versions/1.1.2 - 下一个次要版本（解锁用于开发）
- /versions/1.2 - 下一个主要版本（已解锁以供开发）
- /patch - /versions/1.1.1 的别名，签入出现在两者中地点
- /subrelease - /versions/1.1.2 的别名，签入出现在两个地方
- /trunk - /versions/ 的别名1.2，签入出现在两个地方
目标是保持主干移动以跟上大多数开发人员的工作位置。在我们发布几次并且 1.2 上线后，结构将是：
- /versions/1.0 - 先前版本（锁定）
- /versions/1.1 - 先前版本（锁定）
- /versions/1.1.1 - 先前版本（已锁定）
- /versions/1.1.2 - 先前版本（已锁定）
- /versions/1.2 -当前版本（解锁用于补丁开发）
- /versions/1.2.1 - 下一个次要版本（解锁用于开发）
- /versions/1.3 - 下一个主要版本（解锁用于开发）
- /patch - /versions/1.2 的别名，签入出现在两个地方
- /subrelease - /versions/1.2.1 的别名，签入出现在两个地方
- /trunk - 别名 /versions/1.3，签入出现在两个地方
我知道我可以在自己的机器上执行此操作，但在源代码管理中强制执行此操作为每个人提供了一套通用的术语来使用。
Is there a way in subversion to specify that a specific path is an alias for a different path, with the ability to update that alias as conditions change? Can I lock paths to prevent changes in them?
I'm working on a repository structure and what I'd like to do is have the following paths:
- /versions/1.0 - Previous Release (Locked)
- /versions/1.1 - Previous Release (Locked)
- /versions/1.1.1 - Current Release (Unlocked for patch development)
- /versions/1.1.2 - Next Minor Release (Unlocked for development)
- /versions/1.2 - Next Major Release (Unlocked for development)
- /patch - Alias for /versions/1.1.1, Checkins appear in both places
- /subrelease - Alias for /versions/1.1.2, Checkins appear in both places
- /trunk - Alias for /versions/1.2, Checkins appear in both places
The goal is to keep trunk moving to keep up with where most developers are working. After we release a couple times and 1.2 goes live, the structure would be:
- /versions/1.0 - Previous Release (Locked)
- /versions/1.1 - Previous Release (Locked)
- /versions/1.1.1 - Previous Release (Locked)
- /versions/1.1.2 - Previous Release (Locked)
- /versions/1.2 - Current Release (Unlocked for patch development)
- /versions/1.2.1 - Next Minor Release (Unlocked for development)
- /versions/1.3 - Next Major Release (Unlocked for development)
- /patch - Alias for /versions/1.2, Checkins appear in both places
- /subrelease - Alias for /versions/1.2.1, Checkins appear in both places
- /trunk - Alias for /versions/1.3, Checkins appear in both places
I know I could do this on my own machine, but mandating this in source control gives everyone a common set of verbiage to work with.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
据我所知，您可以使用 svn:externals 实现类似的效果属性 使一个文件夹充当另一个文件夹的别名。如果您不需要同时提交两个版本/分支，那么它应该可以工作。
To the best of my knowledge, you can achieve something similar to this using the svn:externals property to make a folder act as an alias to another. If you never have to commit in two versions/branches at once, it should work.
抱歉，不支持别名。然而，复制整棵树又快又容易。您可以不创建 version/1.2 等，然后在时机到来时将主干复制到 version/1.2，或者只在 version/1.2 中工作。或者，您可以管理两者，但使用一个过程在两者之间复制提交，例如，一旦它们通过了持续集成服务器上的所有测试，它就会将提交从主干复制到 1.2。
锁定：您可以编写服务器端提交挂钩来防止提交到特定路径，并在其中添加您的路径以锁定它们。然而，服务器或默认客户端都没有内置支持。一些客户端（例如 TortoiseSVN）会将包含“标签”的路径视为应该锁定，并警告您是否要提交它们，但这纯粹是客户端和特定于客户端的。
There's no support for aliases, sorry. It is quick and easy to copy whole trees, however. You can either not create version/1.2 etc. and then just copy trunk to version/1.2 when the time comes, or instead just work in version/1.2. Alternatively you could manage both but use a process to copy commits between the two, e.g. once they had passed all the tests on your continuous integration server it copies commits from trunk to 1.2.
Locking: you can write a server-side commit hook to prevent commits to specific paths and add your paths there to lock them. There's no built-in support in either the server or default client however. Some clients e.g. TortoiseSVN will treat paths containing 'tags' as should-be-locked and warn you if you're going to commit to them, but that's purely client-side and client-specific.