CODEWITHSUNDEEP
mercurialtortoisehg
Philip
Philip

Reputation: 3799

Mercurial - handling filename conflicts

Some Context:

I'm trying to implement K. Scott Allen's technique for database schema versioning and, due to the continuous development of this particular project, have chosen to use a simpler 1.sql, 2.sql, 3.sql, ..., n.sql numbering scheme instead of the versioning scheme that is mentioned there.

However, this often leads to the scenario where a change to the schema in two different branches results in the same new file, {n+1}.sql being created.

I'm using Mercurial as my version management software, specifically TortoiseHG on Windows with the default diff software. When I merge a development branch into stable, Mercurial detects a conflict, but offers to merge the two files. Ideally, one of them needs to be renamed to {n+2}.sql.

This can be done in two ways: firstly, one could defer the commit on the merge and edit the files there. However, at this stage, the merged file {n+1}.sql is a messy combination of some or none of either file.

The second method is to undo the merge, go to the development branch, rename the file, recommit, re-merge.

My Question:

Is it possible to get Mercurial to treat files that were each created in separate branches differently to files that were merely modified in different branches when it comes to merging?

Ideally, if I were faced, post-merge, pre-commit with {x+1}.sql and {x+1}.sql.mergebranch then it would be clear which file needed to be renamed and life would be simpler.

Upvotes: 1

Views: 32

Answers (1)

planetmaker
planetmaker

Reputation: 6044

There's two options, one more difficult, the other a bit more hasslesome.

The first is to find and configure or create a diff tool which handles the merges of those files as you see fit. You can also define specific diff tools for specific file types. So this is what you might want to look for

Alternatively, and a bit hackish, you can simplify your current process for the merge. Execute the merge and prior to commit fix it:

  • revert the {x+1}.sql to the previous version: hg revert -rHASH1 {x+1}.sql
  • create the 2nd sql file: hg cat -rHASH2 {x+1}.sql > {x+2}.sql

where HASH1 and HASH2 are the changesetIDs of the two parents of the merge.

Upvotes: 0

Related Questions