配置Azure负载平衡器和NAT规则(Configuring Azure load balancer and NAT rules)

 我要拿你的图表重新整理一下： 
 
                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/--\
              /           /      /                          \
     /------------alpha--/------/---\                        \
    /                                \                        \
------------trunk--------------------(a)----------------------(b)------------------>
 
 首先，删除trunk ，因为你没有使用它。 是的，你正在融入后备箱，但你永远不会从中取出代码。 相反， beta来自alpha ， gamma来自beta 。 不妨将所有这些努力都归并到你从未真正使用过的代码行中： 
 
                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/
              /           /      /                      
     /------------alpha--/------/                    
    /                                      
trunk
 
 现在，让我们理清你的图表，以便主要的发展路线很好而且直线： 
 
trunk-alpha-------beta-----------------------gamma-------------------------->
            \           /      /       \                /
             \---alpha-/------/         \---beta-------/
 
 最后，翻转一切... 
 
             /-alpha-\-----\            /--beta-------\
            /         \     \          /               \
trunk------/--(beta)---\-----\--------/-(gamma)---------\------(gamma)-------->
 
 有你的箱子！ 
 
 我知道你在做什么。 你不是在中继线上编码，因为中继线假设代表你的发行版。 在您的原始图中，主干上有两个版本。 要点（a）将分支alpha合并回主干，并将Point（b）合并分支Beta返回主干。 这代表你的Release Alpha和Release beta。 
 
 但是，这就是标签的用途！ 您在发布中制作标签，并且您的标签现在代表您的发布。 而且，它更好，因为标签会保留文件的历史记录。 
 
 假设您在Point（b）处转到主干并记录特定文件。 您在Point（b）处看到该文件，并且您在Point（a）处看到另一个版本。 但是，您不知道该文件在点（a）和点（b）之间是如何变化的。 事实上，你甚至不知道是谁发布了对特定更改负责。 
 
 但是，如果您在分支上执行了一个标记而不是将代码合并回主干，那么您将会看到该文件的整个历史记录都返回到该文件的第一个版本。 Subversion的日志命令（如果你不使用--stop-on-copy开关）将带你从标签下降到分支测试版并返回到主干。 
 
 啊，你说，但是我怎么能看到版本alpha和版本beta之间的区别？ 在我的计划中，我可以看看后备箱的历史！ 
 
 但是，如果您需要查看一个版本与另一个版本之间的所有更改，则可以轻松地在两个标签之间进行差异。 而且，由于它们是标签，因此找到实际发行版本要容易得多，而不是试图弄清哪个版本的trunk表示您的发行版本。 
 
 所以，你确实有一个后备箱，但你不会那么称呼它。 

I'm going to take your chart and reorganize it a bit:
 
                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/--\
              /           /      /                          \
     /------------alpha--/------/---\                        \
    /                                \                        \
------------trunk--------------------(a)----------------------(b)------------------>
 
First, remove trunk, since you're not using it. Yes, you're merging back into the trunk, but you never take code out of it. Instead, beta comes from alpha and gamma comes from beta. Might as well save yourself all that effort merging back into a code line you never really use:
 
                                          /-----gamma-----/(3)---------->
                                         /               /
               /----beta---/(1)---/(2)--/---beta--------/
              /           /      /                      
     /------------alpha--/------/                    
    /                                      
trunk
 
Now, let's straighten out your chart, so that the main development line is nice and straight:
 
trunk-alpha-------beta-----------------------gamma-------------------------->
            \           /      /       \                /
             \---alpha-/------/         \---beta-------/
 
And, finally flip over everything...
 
             /-alpha-\-----\            /--beta-------\
            /         \     \          /               \
trunk------/--(beta)---\-----\--------/-(gamma)---------\------(gamma)-------->
 
There's your trunk!
 
I know what you're doing. You're not coding on trunk because trunk is suppose to represent your release. In your original diagram, there are two versions on trunk. Point (a) where you merge branch alpha back to trunk, and Point (b) where you merge branch beta back to trunk. This represents your Release alpha and Release beta.
 
However, that's what tags are for! You make a tag on a release, and your tag now represents your release. And, it's better because a tag preserves the history of your file.
 
Let's say you go to your trunk at Point (b) and take a log of a particular file. You see the file at Point (b) and you see another version at Point (a). But, you have no idea how that file was changed between point (a) and point (b). In fact, you don't even know who's release responsible for a particular change.
 
However, if you did a tag off the branch instead of merging your code back to trunk, you'd see the entire history of that file all the back to the very first version of the file. Subversion's log command (if you don't use the --stop-on-copy switch) will take you from the tag down to branch beta and back to trunk.
 
Ah, you say, but how can I see the differences between release alpha and release beta? In my scheme, I can look at the history of the trunk!
 
However, if you need to see all the changes between one release and another, you could easily just do a diff between two tags. And, sine they're tags, it's much easier to find the actual release version instead of trying to figure out which version on trunk represents your which release.
 
So, you do have a trunk, but you just don't call it that.