mercurial

问题 I'm a Git user trying to use Mercurial. Here's what happened: I did a hg backout on a changeset I wanted to revert. That created a new head, so hg instructed me to merge (back to "default", I assume). After the merge, it told me I still had to commit. Then I noticed something I did wrong when resolving a conflict in the merge, and decided I wanted to have everything as before the hg backout , that is, I want this uncommited merge to go away. On Git this uncommited stuff would be in the index

问题 I'm trying to figure out how to merge branches from a separate repo into the current. I have the following: PJT1 - contains branches default and foodog PJT2 - contains branch default from PJT2, I do the following: $ hg fetch -y ../PJT1 -r foodog -m "this is a test" Now, if I look in PJT2, I see the correct files and changes. However, I if I do hg branches , I get the following: [someone@myhome pjt2]$ hg branches foodog 1:c1e14fde816b default 0:7b1adb938f71 (inactive) and hg branch reveals the

问题 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 : I create a new repo in kiln online. Then clone it on my pc. I copy my entire project

问题 My team's just starting out with Mercurial and a central repository. We have Hudson building the tip of the "default" branch - which is basically our mainline. We had a check-in policy with our old VCS that code reviews, testing, etc. must be done before you check-in to the mainline. So, let's say you are working on feature X. You work on some stuff, basing it off of "default", and then you commit a partial feature as a checkpoint. Locally your "default" is now broken -- you haven't shared it

问题 I use Mercurial for game development, and I'm trying to use the LargeFiles extension included in Mercurial 2.0 to keep track of large binary assets. Unfortunately there isn't a whole lot of documentation on the extension, so I'm not sure how people are expected to use it. For example, is there any way to safely clean out the .hg/largefiles directory? If I'm on the tip revision, and expect to always have internet access, then I don't need the old versions of largefiles cluttering up the

问题 I've recently started getting into Git on a personal project, and I can see how a DVCS might benefit us at work (which is a large enterprise software company, currently running Perforce). Feature work in my team for example mostly consists of developers creating their own branches; sometimes these are shared between small teams of developers. I think it would be more efficient in this instance to use a DVCS. In the more general case, though, I'd be interested to hear from people that use a

问题 We started using Mercurial a several weeks ago. Most developers follow this workflow: work on a feature commit -m "Worked on feature ABC" pull -u If branch merge commit -m "Merge" push Today, one of our developer suggested that we do: work on a feature pull -u if branch merge commit -m "Worked on feature ABC" push That way, we have a lot less "Merge" changesets in the log. Some of us think it's just a matter preference. Some of us think one is better than the other. We don't have much

问题 Does anyone know how to setup Mercurial to use p4merge as the merge/diff tool on OS X 10.5? 回答1: This will work for merging: Place this into your ~/.hgrc (or, optionally, your Mercurial.ini on Windows): [merge-tools] p4.priority = 100 p4.premerge = True # change this to False if you're don't trust hg's internal merge p4.executable = /Applications/p4merge.app/Contents/MacOS/p4merge p4.gui = True p4.args = $base $local $other $output Requires Mercurial 1.0 or newer. Clearly you'll need to

问题 If I have a bunch of uncommitted changes and want to set it aside while working on something else instead, and then later (f.i. after several days) come back to it and proceed working. What would be the easiest workflow to accomplish this? (So far I have only experience with Mercurial's basic functionality). My usual method was to create a new branch using clone, but there might be better ways. 回答1: You have a handful options: Shelve the items. This saves the changes and removes them from the

问题 I am just trying to my head round Mercurial, so this may be a daft question.. Open I wish to have more than one version of a program compiled on my machine, for example, I may need to single step both the “working versions” and the “bracken” version in a debugger until I find way the behave differently. I also like to checkout to a clean workspace after I have done a check, so I can check (by doing a build) that I have not forgot to add a file. This is easy to do in most source code control