Mercurial newbie here, I'm working on a Django project that uses Sqlite as the database. I develop templates & UI stuff while my colleague works on the back-end code. We both push changes to Bitbucket.
He is the only one who actually modifies the models and correspondingly, the SQLite file, however just by virtue of my testing开发者_开发知识库 the app, the file changes as well. I always drop my changes by doing an 'hg revert database.sqlite' after I've finished testing and before I push.
Is there a simple way for me to always stick with his version of the SQLite file so that we don't have merge issues every time we try and sync? Sort-of like an exception that says 'if there is a conflict, always use the remote version of the file'. I did see something like this in a tip somewhere, but I can't for the life of me find it again.
I agree with the comment by Matthew that the best solution is to not track this file.
However, your idea of asking Mercurial to always use the remote version is actually not that far out... :-) You do this by configuring a merge tool for this file where you tell Mercurial to use the other (remote) version in all merges:
[merge-tools]
database.sqlite = internal:other
That should make sure that you will always discard your changes to database.sqlite
when you merge. This lets you do
$ hg pull
$ hg merge
I just got another idea -- use a pre-merge hook to revert the file:
[hooks]
pre-merge = hg revert mydb.sqlite
That is pretty much equivalent to using the internal:other
merge tool from above, but you may find it conceptually simpler since it models what you are already doing.
As long as you work on a shell, there are numerous ways on having hg revert database.sqlite
executed before you commit.
with bash
:
alias hgcommit = hg revert database.sqlite;hg commit
(it's a bit cheap, I know, but thats why I like working with a shell)
精彩评论