视觉工作室2010年白痴清单清单 [英] idiots checklist for mercurial with visual studio 2010

问题描述

所以我是一个源代码控制傻瓜，所以请用这张清单来逗我.

我最终决定使用Mercurial + TortoiseHg +(VS2010 + HgSccPackage )+我下一个项目的窑炉.

我读了 http://hginit.com/，我玩了很多，但我没有我对源代码控制不是很了解，所以我不想在这里犯错，我目前的项目是我迄今为止最大，最有价值的项目.

这是我的清单:

创作:

1. 我在线创建了一个新的窑库.
2. 然后克隆在我的电脑上.
3. 我将整个项目文件夹(该文件夹下有多个项目的解决方案)复制到存储库中.
4. 我将此内容添加到.回购根目录中的hgignore文件.
5. 从 TortoiseHg 中，我点击添加文件
6. 我偶尔会从VS提交.
7. 当我准备好并准备好时，我就进入Sync-> Push
   (所以这很好吗?)

我在这里遇到的一个问题.我在HgScc中找不到等效的添加文件"，当我从VS-IDE添加新文件时注意到，它没有用于源代码管理的图标. (它不添加到水银中吗?)

因此，我最终通过IDE添加文件，但它们没有检查.然后经过几次提交(和其他我不记得的事情)之后，我注意到这里有一个额外的分支或其他东西:

现在，如果我尝试推动，我会得到"(did you forget to merge? use push -f to force)". (是的，我打进来的东西，但我没有即将到来的变化)

无论如何，只是一个游乐场，**我每次使用VS创建文件时都意识到使用TortoiseHG->添加文件可以解决问题吗? **(还是这里有更好的方法?)

分支:

因此，我对命名分支有些困惑，但是Kiln作为他们自己的分支/克隆对象.我在此处阅读说明

1. 因此，在线时，我可以选择在窑中在线创建分支".
2. 然后，我将在本地将其克隆为新的存储库(就像它是新的存储库一样)
3. 我将进行更改，提交，推送.
4. 然后，我将从MAIN存储库中提取并从分支存储库推送至MAIN.

因此，我在这里实际上看不到任何合并选项，我猜想Mercurial会自行处理合并吗?所以我看不到资源库浏览器中的分支吗?这是应该怎么做的吗?

最后一个问题，查看历史记录"和查看更改日志"选项之间有什么区别，它们对应于哪些hg选项?

---

更新:忘了提及我是该项目上唯一的孤独开发人员. = P

解决方案

这是您的个人问题，每节一个，对每个问题有我的看法/答案.

---

7.当我准备好并准备好时，我就进入Sync-> Push(所以这很好吗?

正确.

此工作流程中可能有所不同的一件事是，是否还有其他人也推送到同一存储库.如果有的话，有时其他人将变更集推送到了您本地没有的存储库中.当您尝试推送将在在线存储库中创建分支的分支时，该分支会被多个头"显示(如果您不明白我的意思，则应该在Mercurial上下文中查找该术语.)通常，您不会不允许这种情况发生，因此推送将被中止.

当它异常终止时，您可以将更改集从在线存储库中拉到本地存储库中，将更改集头与刚刚拉出的头合并，然后重新尝试该推送，通常会成功(除非您很不幸)而与此同时有人推得更多.)

---

关于HgSCC和添加文件，我在使用HgSCC时遇到了问题，所以我改用了VisualHg- http://visualhg. codeplex.com ，尤其是因为HgSCC的1.52版本在新文件方面似乎存在问题.如果找不到解决方案，建议您尝试VisualHG.

---

您忘记合并了吗?

您应该将所做的更改合并在一起，以使您只有一个脑袋.在该示例屏幕快照中，您有3个，即向表单2添加了按钮"，最终提交"和第2个PRJ(2)".您应该将其更新为您认为是项目中的大多数"项目，选择它，然后右键单击其他项目之一，然后在TortoiseHg中选择与...合并"，然后完成合并和提交.每个这样的merge + commit将删除1个头，因此您至少需要2个这样的合并才能恢复到1个头.

---

Kiln和Fogcreek关于如何处理分支的概念与许多其他人不同.他们建议您创建一个完全不同的分支存储库并在其中工作，而不要使用命名分支.命名分支类似于您将屏幕快照中的三个变更集(以最终提交"结尾的三个变更集)命名为添加新表单或修复大错误的分支.

因此，与其做在这里的事情不同，不是拥有3个Head，Kiln的方法"将是拥有3个克隆，每个克隆只有更改集直至其分支头.基本上，您将拥有1个repo克隆，其中的所有内容均达到添加的第二种形式"，并继续进行"second proj"，但它们之间的更改集将不存在.第二个克隆最多具有添加的第二个表单"，然后一个额外的标签为添加了第二个表单的按钮"，第三个克隆具有添加的第二个表单"，然后三个以最终提交"结尾. >

当然，最后，当进行推拉操作回到主存储库时，无论如何，您最终都会得到那些分支，但是他们建议您对较大的分支使用类似的分支存储库，例如添加大功能，模块，等

---

我猜是汞可以自行处理合并吗?

仅当您在原始存储库和分支存储库克隆中都有新的变更集时，方案中的合并才会起作用.

如果有，从分支存储库推送到原始存储库(或以其他方式拉动)会在目标存储库中添加新的目录.这就是合并将帮助您避免的事情.

这样，您的工作流程将如下:

1. 将所有更改都推送到分支存储库中(例如，由于您首先需要分支存储库的原因，大的错误修正，新功能，大的重写等原因而产生的更改集)
2. 尝试将其从分支存储库推送到原始存储库，并得到消息，这将在目标存储库中创建头，因此您将其中止.
3. 从原始存储库下拉至分支存储库.这将创造另一个头.
4. 从分支存储库拉到本地存储库，然后在此处进行合并，处理所有合并冲突，最后提交合并更改集
5. 从本地存储库推送回分支存储库
6. 在正式发布之前，将您可能希望在窑炉中进行的所有代码审查定稿
7. 从分支存储库推送到原始存储库(请注意，这与第2步相同，如果其他人(或您)同时在原始存储库中做了更多工作，请跳回第3步并重复)

---

查看历史记录"和查看更改日志"选项之间的差异

不同之处在于您所查看的内容.查看历史记录始终显示所选内容的历史记录，无论是文件还是解决方案文件本身，即.只是涉及该文件的变更集.

查看更改日志，无论您选择什么，都可以查看存储库的更改集日志.

So Im a source control idiot so please humor me with this checklist.

I finally decided to use Mercurial + TortoiseHg + (VS2010 + HgSccPackage) + Kiln for my next project.

I read http://hginit.com/ and I played around quite a bit, but I don't know much about source control so I don't want to make a mistake here, my current project is my biggest and most valuable one yet.

So here is my checklist:

Creation:

1. I create a new repo in kiln online.
2. Then clone it on my pc.
3. I copy my entire project folder (Solution with mutiple projects under that folder) into the repo.
4. I add this content into a .hgignore file in the repo root.
5. From TortoiseHg I click add files
6. I occasionally commit from VS.
7. When I'm good and ready I go Sync->Push
   (So this is all good right?)

One problem I had here is. I can't find Add Files equivalent in HgScc, I noticed when I added a new files from the VS-IDE, it doesn't have the icon for source control. (Its not added to mercurial?)

So I ended up adding files through the IDE and they didn't have a check. Then after a few commits (and other things I don't remember) I noticed there was an extra branch or something:

And now If I go try to push I get "(did you forget to merge? use push -f to force)". (And yes I hit incoming and I have NO in coming changes)

Anyway,was just a playground, ** I just realized using TortoiseHG ->Add Files everytime I created files from VS fixes things? **(Or is there a better way here?)

Branching:

So Im a little confused about named branching, but Kiln as their own branch/clone thingy. I read instructions here

1. So, Online, I have option that create a "Branch" in Kiln online.
2. Then I will clone this as a new repo locally (as if it were a new repo)
3. I will make my changes, commit, push.
4. Then I'll pull from the MAIN repo and push from my branch repo to the MAIN.

So I'm not really seeing any merge option here, Im guessing mercurial handles the merging on its own? So I'm not seeing the branch from the repository explorer? Is this how its supposed to be done?

Last question, what is the difference between the View History and View Change Log options and what hg options do they correspond to?:

---

Update: Forgot to mention I'm the only lonely developer on this project. =P

解决方案

Here's your individual questions, one per section, with my opinion/answer on each.

---

7. When I'm good and ready I go Sync->Push (So this is all good right?

Correct.

The one thing that might differ in this workflow is if there is anyone else also pushing to the same repository. If you have that, at some point someone else has pushed changesets to the repository that you don't have locally. When you try to push yours that would create a branch in the online repository, made visible by multiple "heads" (you should look up that term in Mercurial context if you don't understand what I mean by that.) Generally you don't allow this to happen, so the push will be aborted.

When it aborts, instead you would pull the changesets from the online repository down into your local one, merge your changeset head with the head you just pulled, and then reattempt the push, which would usually succeed (unless you're unlucky and someone else pushed more in the meantime.)

---

As for HgSCC and Add files, I've had problems with HgSCC so i switched to VisualHg - http://visualhg.codeplex.com, specifically because there seems to be something wrong with the 1.52 version of HgSCC regarding new files. If you can't find a solution for it, I would suggest you try out VisualHG.

---

did you forget to merge?

You should merge your changes together, so that you only have one head again. You have 3 in that example screenshot, "added button to form 2", "final commit" and "2nd prj (2)". You should update to the one you consider to be "most of your project", select it, then right-click on one of the other heads and select "Merge with..." in TortoiseHg, and complete the merge and commit. Each such merge+commit would remove 1 head, so you need at least 2 such merges to get back down to 1 head.

---

Kiln and Fogcreek has a different notion on how to handle branches than many others have. They suggest you create a completely different branch repository and work in that, instead of using named branches. A named branch would be akin to you naming the three changesets in your screenshot (the 3 that end with "final commit") as a branch for adding a new form or fixing a big bug.

So instead of doing what you've done here, having 3 heads, the Kiln "way" would be to have 3 clones, each with only the changesets up to their branch head. Basically you would have 1 repo clone with everything up to "added 2nd form", and continuing with "second proj", but the changesets inbetween would not be there. The second clone would have up to "added 2nd form", and then the one extra labelled "added button to form ", and the third would have "added 2nd form", and then the three ending with "final commit".

Of course, in the end, when pushing and pulling to get back to the main repository, you end up with those branches anyway, but they recommend you use branch repositories like that for bigger branches, like adding big features, modules, etc.

---

Im guessing mercurial handles the merging on its own?

Merging in your scenario would only come into play if you have new changesets in both the original repository and in your branch repository clone.

If you have that, pushing from branch repository to original repository (or pulling the other way) would add new heads in your target repository. This is what merging would help you avoid.

In this way, your workflow would like follows:

1. Push all the changes you have to your branch repository (ie. the changesets resulting from the reason you needed the branch repository in the first place, big bugfix, new feature, big rewrite, whatever)
2. Try to push from branch repository to original repository, getting message that this will create heads in the target repository, so you abort that.
3. Pull from original repository down into branch repository. This will create another heads.
4. Pull from branch repository to your local repository, and do the merge here, handling any and all merge conflicts, finally committing your merge changeset
5. Push from local repository back to branch repository
6. Finalize any code reviews you might want to do in Kiln before you make it official
7. Push from branch repository to original repository (note this is the same as step 2, if someone else (or you) have done more work in the original repository in the meantime, jump back to step 3 and repeat)

---

difference between the View History and View Change Log options

The difference is just what you view it on. View History always shows the history for whatever you have selected, be it a file or the solution file itself, ie. just changesets involving that file.

View Changelog views the changeset log for the repository, regardless of what you have selected.

这篇关于视觉工作室2010年白痴清单清单的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！