使用 Mercurial 时，在内部发布产品测试版本并保留“此版本中的内容”列表的流程？
我需要一些具体的想法。
我们正在考虑更改我们的版本控制系统，我希望我们使用 Mercurial。它将减轻与某些内部流程相关的许多痛苦，同时也会带来一些挑战。
这些挑战之一是我们当前使用的版本控制系统不是分布式版本控制系统，因此具有每个变更集修订号的概念，我们已在内部使用了这一概念。
基本上，当程序员在我们的案例管理系统中检查修复案例的最终更改时，Visual Studio 会响应该变更集编号，然后程序员将其附加到案例中，基本上说“如果您正在运行一个版本我们产品的最后一个版本号具有该值或更高值，那么您就拥有该版本中的所有更改。”
然而，对于 Mercurial 来说这是行不通的，因为修订号可以并且将会随着来自不同分支的提交而改变。
所以我想知道如何才能得到类似的东西。
请注意，这与发布管理无关。发布受到更多的控制，但正在进行的测试更加流畅，因此我们希望避免让测试人员不断尝试找出他列表中的测试用例在他正在测试的版本中是否真正可用。
基本上，我需要测试人员能够查看他们正在测试的版本是否具有与测试用例相关的更改。
我正在考虑以下内容：
- 程序员提交，并获取变更集的哈希值
- 程序员将其附加到我们的案例跟踪器中的案例
- 构建过程必须标记（不是以 Mercurial 方式）版本，以便它知道哪个变更集它是由我构建的，
- 我必须能够轻松获取我们的产品构建所用的变更集的哈希值，在用于我们的构建机器的存储库的变更集日志中查找它，然后弄清楚产品变更集是否是与测试列表中的每个案例相同或者是其祖先。
所以我有两个问题：
- 这是一个可行的方法吗？我并不反对创建一个易于处理的 Web 应用程序
- 有谁知道可以帮助我的替代流程吗？我研究过标记，但似乎标记最终会增加合并压力，这是我想要的吗？ （即添加/移动标签最终作为提交，需要与系统的其余部分合并）
- 是否有任何东西可以帮助我开箱即用，即有人制作或知道，已经有这样的事情了吗？
- 还有其他想法吗？
I need some concrete ideas for this.
We're looking at changing our version control system, and I'd like for us to use Mercurial. It would ease a lot of pain related to some internal processes, as well as pose some challenges.
One of those challenges is that the version control system we're currently using is not a distributed one, and thus has the concept of revision numbers for each changeset, which we've used internally.
Basically, when the programmer checks in the final change that fixes a case in our case management system, Visual Studio responds with which changeset number this became, and the programmer then affixes that to the case which basically says "If you're running a version of our product with the last version number this value, or higher, then you have all the changes in that version."
However, with Mercurial that doesn't work, as revision numbers can and will change as commits come in from different branches.
So I'm wondering how I can get something similar.
Note, this is not about release management. Releases are much more controlled, but on-going tests are more fluid, so we'd like to avoid having a tester continuously trying to figure out if the test-cases on his list are really available in the version he's testing on.
Basically, I need the ability for someone testing to see if the version they're testing on has the changes related to a test-case, or not.
I was considering the following:
- The programmer commits, and grabs the hash of the changeset
- The programmer affixes this to the case in our case tracker
- The build process will have to tag (not in the Mercurial way) the version so that it knows which changeset it was built from
- I have to make it easy to take the hash of the changeset our product was built from, look it up in the changeset log of the repository that is used for our build machine, and then figure out if the product changeset is the same as, or an ancestor of, each case in the test list.
So I have two questions:
- Is this a feasible approach? I'm not adverse to creating a web application that makes this easy to handle
- Does anyone know of an alternate process that would help me? I've looked at tagging, but it seems that tagging ends up adding merge pressure, is that something I want? (ie. adding/moving a tag ends up as a commit, which needs to be merged with the rest of the system)
- Is there anything out there that would help me out of the box, that is, have someone made, or know of, something like this already?
- Any other ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您正在寻找与您的构建流程相关的轻量级标记流程，这样说是否正确？
我不喜欢程序员抓住最后一个哈希值并将其粘贴到其他地方的想法 - 听起来像是那种你不能依赖的手动过程。您能否围绕程序员将案例编号添加到其提交消息中构建一个流程，以便稍后可以将提交链接到原始案例？当案件被标记为“已关闭”时，您可以获取针对该案件的所有提交。
许多案例控制系统都有这个 - Fogbugz，例如。
Is it right to say that you're looking for a lightweight tagging process linked to your build process?
I'm not keen on the idea of the programmer grabbing the last hash and sticking it somewhere else - sounds like the sort of manual process that you couldn't rely on happening. Would you be able to build a process around programmers adding the case number to their commit message so something could later link the commit to the original case? When the case was marked as "closed" you could pick up all commits against the case.
Lots of case control systems have this - Fogbugz, for example.
bitbucket 和 google code 都保留一个分支时间线，直观地显示合并的内容、合并者和合并时间。我怀疑这可能就是您想要做的：这是解决问题 4 的一种非常简单的方法。
我不知道他们是如何做到这一点的，但是工具就在那里。 BitBucket 提供商业代码托管。
Both bitbucket and google code keep a branching timeline, that shows visually what has been merged, by who, and when. I suspect that this might be what you want to do: it's a very simple way to resolve issue 4.
How they do that, I don't know, but the tools are out there. BitBucket offers commercial code hosting.