分布式源代码控制 - 推送单个变更集
正在解决一个棘手的问题，希望得到社区的一些帮助。基本上，我们的开发团队分为两个团队，比如说“红色”和“蓝色”
3 个存储库：
1：大师
2：红色>>大师的克隆
3：蓝色>>主控克隆
每个开发人员都在他们工作的本地计算机上克隆红色或蓝色。
两个团队都在为我们的主要应用程序执行各种任务。每个团队都有一个我们的共享“主”存储库的克隆，他们在其中应用他们的变更集。变更集在该级别进行验证，此时它们已准备好推送到主服务器中。
为了简单起见，假设开发人员 A 和 B 都属于红队。
因此，当开发人员 A 推送变更集 1，然后开发人员 B 推送变更集 2 时，问题就出现了。然后变更集 1 已验证并准备好进入 Master，但变更集 2 还没有。
我想尽快将变更集 1 推送到 Master，而不是等待对变更集 2 进行验证，特别是因为变更集 3 可能会同时引入。
我们目前正在使用 Mercurial，我喜欢它 - 如果我想做的工作流程更容易，我愿意切换到 git。
我在想这个错误吗？我很感激你的帮助。
Working on a bit of a sticky problem and was hoping for some help from the community. Basically, our dev team is split up into two teams, lets say "Red" and "Blue"
3 repos:
1: Master
2: Red >> Clone of master
3: Blue >> Clone of master
Each developer is cloning red or blue on their local machine where they are working.
Both teams are working on various tasks for our main application. Each team has a clone of our Shared "Master" Repository on which they are applying their changesets. The changesets are verified at that level, at which point they are ready to be pushed into the Master.
To simplify, lets say developer A and B are both on Red team.
So the problem comes when developer A pushes changeset 1, then developer B pushes changeset 2. Then changeset 1 is verified and ready to go into Master but changeset 2 is not.
I want to push changeset 1 to Master as soon as possible, and not wait for verification to changeset 2, especially since changeset 3 could be being introduced in the meantime.
We're currently using mercurial and I like it - I would be willing to switch to git if the workflow for what I want to do would be easier.
Am i thinking about this wrong? I appreciate the help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在您描述的具体情况下：
您需要做的就是
hg push -r cset1，其中cset1是您想要的cset的修订号或节点哈希。当您使用
-r推送时，它会推送更改及其所有祖先，因此您可以推送变更集 1 而不推送变更集 2，但不能推送变更集 2 而不推送变更集1。如果您需要将它们打乱（两个但不是一个），那么您就可以使用 TransplantExtension 进行挑选，但只要您按顺序进行，您就有一个简单的选择。
（请注意，为了避免“两个而不是一个”的情况，最好的计划是让编写功能二的人首先执行
hg update 0。这样，二和一将成为兄弟姐妹（都是零的孩子） ）而不是父子关系，这更自然地反映了它们的真实关系，如果它们确实是可分离的功能，这可以通过分支显式完成，但严格使用变更集父子关系也是一种完全有效的操作模式。）In the specific case you're describing:
all you need to do is
hg push -r cset1where cset1 is the revision number or node hash of the cset you want.When you push with
-rit pushes that changes and all of its ancestors, so you can push changeset 1 without pushing changeset2, but not changeset 2 without pushing changeset 1.If you need to push them out of order (two but not one) then you're into cherry picking with the TransplantExtension, but so long as you're going in order you've got an easy option.
(Note that to avoid the "two but not one" scenario the best plan is to have whomever wrote feature two do a
hg update zerofirst. That way two and one will be siblings (both kids of zero) rather than parent-child, which more naturally reflects their true relationship, if indeed they are separable features. This can be done explicitly with branching, but doing it strictly with changeset parentage is a perfectly valid mode of operation too.)当
TeamA准备好推送更改时，您将TeamA 合并到master，当TeamB准备好时，您将TeamB 合并到master。定期下线
TeamA和TeamB应从Master获取/合并，以确保其版本具有最新代码。如果您需要更多示例，请查看 Gitorious/Github 的设置方式。每个开发人员都有自己的项目克隆，然后当他们准备好时，他们会申请合并到主存储库中。
同样的原则也适用于 Merc，关键是确保经常获取/合并到团队存储库（开发人员存储库），以确保将新代码引入他们的开发周期。
When
TeamAis ready to push changes, you merge TeamA into master, and whenTeamBis ready, you merge TeamB into master.Periodically down the line both
TeamA&TeamBShould Fetch/Merge fromMasterto make sure thier versions have the latest code.If you need more examples look at how Gitorious/Github are set up. Each developer has thier own clone of the project, then when they're ready they apply to be merged into the master repo.
This same principle can be applied to Merc, the key is making sure you fetch/merge to the Team Repos (Developer Repos) often to make sure new code is introduced to thier dev cycle.
我不熟悉 Mercurial 中的分支，但在 SVN 中你可以这样做 - 我确信有一个等效的分支。您需要设置分支，并将变更集合并到 /trunk 中。这使您可以选择要发布的修订版本，而不必只执行“svn up”并获取所有修订版本。
例如，您可以有类似的内容。
在本例中，/trunk 被假定为当前稳定代码，它将在生产环境中运行。假设您只想推送红队的修订版 100 和蓝队的修订版 110。从 /trunk 内部，您可以执行以下操作：
并且只有在这些特定修订版中所做的更改才会合并到 /trunk 中。
I'm not familiar with branching in mercurial, but here's how you'd do it in SVN - i'm sure there's an equivalent. You need to set up branches, and instead merge changesets into /trunk. This allows you to pick and choose which revisions go out, rather than just having to do "svn up" and get them all.
For example, you could have something like
In this case, /trunk is assumed to be the current stable code, which would run on production. Say you only wanted to push red team's revision 100, and blue team's revision 110. From inside /trunk, you would do:
And only the changes made in those specific revisions would be merged into /trunk.