There’s nothing in particular in DVCSs that makes merging easier. It’s simply cultural: a DVCS wouldn’t work at all if merging were hard, so DVCS developers invest a lot of time and effort into making merging easy. CVCS users OTOH are used to crappy merging, so there’s no incentive for the developers to make it … Read more
Update to the stiging branch and create a new branch off of it. Then close the old branch. In summary: hg update stiging hg branch staging hg commit -m”Changing stiging branch to staging.” hg update stiging hg commit –close-branch -m”This was a typo; use staging instead.” hg push –new-branch
As mentioned in Git FAQ, it will detect similar content based on an heuristic. Git has to interoperate with a lot of different workflows, for example some changes can come from patches, where rename information may not be available. Relying on explicit rename tracking makes it impossible to merge two trees that have done exactly … Read more
WARNING: a “dummy merge”, as is recommended by @Martin_Geisler, can really mess you up, if later you want to do a true merge of the two branches. The dummy merge will be recorded, and say that you merge into the branch you did the dummy merge to — you will not see the changes. Or … Read more
From my answer to a different question: Distributed version control systems (DVCSs) solve different problems than Centralized VCSs. Comparing them is like comparing hammers and screwdrivers. Centralized VCS systems are designed with the intent that there is One True Source that is Blessed, and therefore Good. All developers work (checkout) from that source, and then … Read more
VonC has the answer you’re looking for, the Rebase Extension. It is, however, worth spending a second or two thinking about why neither mq nor rebase are enabled by default in mercurial: because mercurial is all about indelible changesets. When I work in the manner you’re describing, which is nearly daily, here’s the pattern I … Read more
Subversion has locks, and they aren’t just advisory. They can be enforced using the svn:needs-lock attribute (but can also be deliberately broken if necessary). It’s the right solution for managing non-mergeable files. The company I work for stores just about everything in Subversion, and uses svn:needs-lock for all non-mergeable files. I disagree with “locks are … Read more
I always use a combination of .hgignore and BeforeBuild (in the .csproj file) for things like this. In one of my pet projects, I have the following setup: App.config contains my real hardcoded user id and password for testing. App.config.example is identical, but with fake data like “dummy_user” and “dummy_pw”. App.config is not part of … Read more
The biggest difference is how the branch names are recorded in the history. With named branches the branch name is embedded in each changeset and will thus become an immutable part of the history. With clones there will be no permanent record of where a particular changeset came from. This means that clones are great … Read more
Here’s the cheat sheet on the commands: hg update changes your working copy parent revision and also changes the file content to match this new parent revision. This means that new commits will carry on from the revision you update to. hg revert changes the file content only and leaves the working copy parent revision … Read more