如何修复 SVN 工作历史中的项目版本？
我从事的项目可能包含多个客户的多个版本。即 2.65 - 客户端 1 的版本，2.67 - 客户端 2 的版本；一般来说，2.65 和 2.67 之间的差异非常小 - 因此，不需要为每个客户端提供多个分支。 我所需要的一切 - 修复工作历史记录中的版本，如果将来需要，请签出特别选定的版本（即，当工作副本为 3.4 时签出 2.65 版本 - 并为相应的客户端添加一些更改）。
我在服务器上使用 VisualSVN，在客户端使用 TortoiseSVN。 谢谢）
I work on project, which may contains several version to several clients. I.e. 2.65 - version for client 1, and 2.67 - version for client 2; generally, differences between 2.65 and 2.67 really small - and due this, it's no need in several branches for each client.
All what I need - fix version in working history and, if need in future, checkout espessially selected version (i.e. checkout 2.65 version when working copy is 3.4 - and add some changes for corresponding client).
I use VisualSVN on server and TortoiseSVN in client.
thx)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为每个客户端使用一个分支，将所需的更改应用于每个分支，然后为每个分支创建一个新标签，有什么问题？
示例：
当前分支 client1 具有标签“2.65”，分支 client2 具有标签“2.67”。
现在，您在主干上进行了一些修复，并且只想将它们传递回分支 client1，因为 client2 不具有应用修复的功能。
将主干的更改合并到分支client1，创建一个新标签“whatever”并将此新标记版本提供给客户。
顺便说一句：TortoiseSVN 有一个集成的合并功能，但我从未使用过（也许不理解它）。在另一个项目中使用 Git 向我展示了智能（自动）合并确实可以发挥作用......
What is the problem with using a branch for every client, apply the needed changes to each branch and then create a new tag for each branch?
Example:
Currently branch client1 has the tag '2.65' and branch client2 has the tag '2.67'.
Now you do some fixes on trunk and want to pass them back to branch client1 only since client2 doesn't have the feature where the fix was applied.
Merge the changes from trunk to branch client1, create a new tag 'whatever' and give this new labeled version to the customer.
BTW: TortoiseSVN has an integrated Merge functionality that I never got working (maybe didn't understand it). Using Git in another project showed me that an intelligent (automatic) merging could really work...
您正在描述分支的典型用例之一。严重地。
但是，我猜您正在放弃分支，因为跨分支移植更改是一项困难且耗时的任务。它很慢，而且你必须解决难以理解的冲突。嗯，这不是分支的限制：这是 Subversion 的限制。显然，Subversion 没有存储足够的有关您的更改的信息，这使得正确合并变得非常困难。
据说其他现代版本控制系统比 Subversion 能更好地处理分支：git、Mercurial、Bazaar...您可能会考虑进行切换。
无论如何，即使在 Subversion 中您也可以处理并行分支。看看《Version Control with Subversion》一书中的“Branching and Merging”。 TortoiseSVN 非常方便，因为当您尝试执行合并时，它会将已移植的修订版本显示为灰色。
You are describing one of the prototypical use cases for branches. Seriously.
However, I guess that you are discarding branches because porting changes across branches is a difficult and time consuming task. It's slow and you have to fix conflicts that are hard to understand. Well, that's not a limitation of branches: it's a limitation of Subversion. Apparently, Subversion does not store enough information about your changes and that makes it really difficult to get a merge right.
Other modern version control systems are said to handle branching way better than Subversion: git, Mercurial, Bazaar... You might consider a switch.
Whatever, you can handle parallel branches even in Subversion. Have a look at the "Branching and Merging" in the "Version Control with Subversion" book. TortoiseSVN can be very handy because when you attempt to perform a merge it grays out the revisions that have already been ported.