Mercurial 发布管理
我正在使用 Mercurial 进行源代码控制。我想要一个主开发分支，然后有与“v1.0”“v1.01”和“v2.0”对齐的时间点，这样我就可以随时拉下“v2.0” ”并碾碎其上的一些错误。我听到有人说我需要标签，有人说我需要书签，有人说我需要命名分支，还有人说我只需要维护多个克隆存储库。
从我的角度来看，多个克隆的存储库似乎是一个糟糕的选择，因为我喜欢 DVCS 的一件事是，一旦您克隆“该”存储库，您就拥有所有过去的历史记录，并且如果您的中央服务器烧毁，可以从某人的笔记本电脑完全恢复。如果你的存储库被分散到各处，我觉得你会失去这个好处，除非你希望人们克隆 5 个存储库并在本地计算机上维护它们。这让我很担心，因为大多数人都说这是一个好方法，但从逻辑上讲，这对我来说没有意义。 （我知道这不是进行备份的正确方法，但在不返回服务器的情况下无法完全访问存储库的一部分对我来说似乎很奇怪）
所以对我来说，将所有内容放在一起的方法必须是标签，命名分支或书签。但是，我似乎无法区分这些。人们倾向于将书签解释为“有点像标签，但有一些注意事项”，并将分支命名为某种移动标签，可能最好用克隆来完成。
我真的很喜欢 git 风格的分支（单个存储库，它的多个分支），但是，我不想诉诸奇怪的插件或黑客让它看起来像 git。我想了解正确的善变方式。
奖励：“小规模”分支如何融入其中，即您想在自己的分支中开发一个小功能？
I am using mercurial for source control. I want to have a main dev branch, and then have points in time that align with say "v1.0" "v1.01" and "v2.0", so that at any time I can pull down say "v2.0" and crush some bugs on it. I have heard some people say I need tags, some say I need bookmarks, others say I need named branches, and still others say I just need to maintain multiple cloned repositories.
From my point of view, multiple cloned repos seems like a poor choice because one thing I like about DVCS is that once you clone "the" repo, you have all past history and can totally restore from someones laptop if your central server burns down. If your repo is split up all over the place, I feel like you lose this benefit, unless you expect people to clone 5 repos and maintain them on their computers locally. This concerns me because the majority of people say that this is a good way to do it, yet it logically doesn't make sense to me. (I understand this is not a proper way to do backups, but not having full access to a part of the repo without going back to the server seems odd to me)
So to me, the way to keep everything together must be either tags, named branches, or bookmarks. However, I can't seem to differentiate these. People tend to explain bookmarks as "kinda like tags, with some caveats" and named branches as some kind of a moving tag that is probably better done with clones.
I really like git style branching (single repo, multiple branches off of it), however, I do not want to resort to weird plugins or hacks to make it look like git. I want to understand the proper mercurial way.
Bonus: how do "small-scale" branches fit into the mix, i.e. you want to work on a small feature in its own branch?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
命名分支 - 在您所做的每个提交中，都有一个字段是该提交所针对的分支。除此之外，具有命名分支的存储库和具有多个头的存储库之间没有区别。当您合并命名分支时，就像常规合并一样，分支名称取自当前活动的分支。这很可能正是您想要的长期 v1.x 分支。
书签 - 浮动标签，就像存储库中的提示一样。仅限本地，除非您进行某种边带同步。适合做功能分支或需要跟踪正在发生的事情但不需要与他人共享的事情。
标签 - 命名提交很好，如果您需要确切地知道 v1.0 发布了什么，
我会使用名称分支来开发 1.x 分支、2.x 分支等。然后使用标签来标记实际发布的版本1.0、1.1 将在 1.x 树上完成，然后 1.1 版本将成为其中内容的标签。我不会将书签作为流程的一部分，因为您必须手动同步它们。（请注意，在较新版本的 Mercurial 书签中，可以远程同步，但仍然需要用户干预。）
Named Branch - in each commit you make there is a field for which branch the commit is against. Other than that there is no difference between a repo with a named branch and a repo with multiple heads. When you merge named branches it is just like regular merging and the branch name is taken from your currently active branch. This is more than likely what you want for long term v1.x branch.
bookmarks - floating tags much like tip in your repository. Local only unless you do some sort of side band synch. Good for doing feature branches or something where you need to keep track of what is going on but don't need to share with others.
Tags - A named commit good if you need to know exactly what was released at v1.0
I would use name branches for development a 1.x branch a 2.x branch etc. Then use a tag to label what actually went out as version 1.0, 1.1 would be done on the 1.x tree then 1.1 release would be a tag of what was in it. I wouldn't make bookmarks part of the flow since you have to synch them manually.(Note in newer versions of mercurial bookmarks can be synched remotely though it still takes user intervention.)
我从来不理解将存储库克隆为匿名分支的想法。
hg Branch feature-name是我喜欢的滚动方式。I've never understood the idea of having cloned repos as anonymous branches.
hg branch feature-nameis how I like to roll.Mercurial 或 Git 等 DVCS 可以轻松克隆存储库。这并不意味着您将其用于发布管理工作流程。
每个人都拥有完整的 Mercurial 存储库只是 DVCS 的副作用。这意味着当主存储库丢失时会存在冗余。
您可以使用 DVCS，这样您就可以拥有一个主存储库，您可以在其中推送更改并从中提取更改，就像客户端-服务器 VCS（颠覆）一样，并具有可以离线工作的附加优势。
对于您的发布管理工作流程，您仍然应该查看
对于每个主题，SO 都有足够的讨论。
以下提供了有关分支的详细简要信息带有克隆、书签和命名分支
DVCS like Mercurial or Git makes it easy to clone a repo. That does not mean you use it for purpose of your release management workflow.
That every one has complete mercurial repo is only a side effect of DVCS. It means that there is a redundancy when the main repository is some how lost.
You could work with DVCS in a way that you could have a master repository where you could push changes and pull changes from, just like a client-server VCS (subversion) with the added advantage that you could work offline.
For your release management workflow, you should still look at
There are enough discussion on SO on each of these topics.
The following provides a good brief information on branching with clone, bookmark and named branches
我建议您标记每个发行版本。
如果您需要发布对先前版本的错误修复，您将首先创建一个命名分支或基于版本标签克隆一个新存储库。一旦您解决了错误，您就可以将错误修复合并回您的主开发分支。
无论您使用命名分支还是克隆分支，都并不重要，因为结果是相同的：错误被修复，修复程序发布到以前的版本，修复程序被合并到主开发分支中。阅读其他答案，尝试这两种方法，然后使用您喜欢的方法。就我个人而言，我对这些长期发布分支使用命名分支，以便每个应用程序版本的所有历史记录都存储在单个存储库中。
所以...将每个版本和分支标记为“按需”。
I recommend you tag each release version.
If you need to release a bug fix to a previous version, you would first create either a named branch or clone a new repository based on the version tag. Once you've worked the bug you would merge the bug fix back into your main development branch.
It really doesn't matter whether you use a named branch or a clone as the result is the same: the bug is fixed, the fix is released to the previous version, the fix is incorporated into the main development branch. Read other answers, give both methods a try, and use the one you prefer. Personally, I use named branches for these long-lived release branches so that all the history of each application release is stored in a single repository.
So... tag each release and branch "on demand".
您需要标签来标记 v1.0、v1.01 和 v2.0 等版本。对于分支开发（错误修复、功能分支等），您可以使用书签——它们现在在协作使用中得到了很好的支持（请参阅 http://mercurial.aragost.com/kick-start /en/bookmarks/#sharing-bookmarks）。如果您需要拥有长期存在的分支（即它们在可预见的将来将位于存储库中），请使用命名分支。它们将是一个不错的选择，例如拥有 v1、v2、... 开发分支。
您可以单独使用书签或单独使用命名分支来短期和长期分支，但在可能的情况下首选书签正在成为标准做法。
另请参阅mercurial：混合命名分支和书签以快速了解以及关于书签和命名分支有何不同的图形答案。
You need tags to mark the releases of v1.0, v1.01, and v2.0 etc. For branchy development (bugfixing, feature branches etc.), you can use bookmarks--they are by now very well supported in collaborative use (see http://mercurial.aragost.com/kick-start/en/bookmarks/#sharing-bookmarks). If you need to have long-lived branches (i.e. they will be in the repo for the foreseeable future) use named branches. They would be a good choice e.g. for having v1, v2, ... branches of development.
You could use solely bookmarks or solely named branches for both short-lived and long-lived branches, but it's becoming standard practice to prefer bookmarks when you can.
See also mercurial: mix named branches and bookmarks for a quick and graphical answer on how bookmarks and named branches are different.