today has been kind of a loss. I have spent a innapropriatly large amount of time doing forensic analysis of our source control. The changeset of doom is ead72eaef523553ea5155c9afe61c76e3e4fcc42 despite one of its parents having the mac/mimeTypes.rdf it does not. How Anthony managed to do that merge without the file and without noticing it is the source of much trouble. This means he accidently reverted Manish’s change.
Now anthony did not introduce this error, it was introduced earlier by some of the confused merging between Ian and Andy, but I am more troubled by somone merging and accidently reverting someone elses changes. The Ian and Andy merges were many and confusing the chance of something going wrong was high, and because in mercurial doesn’t require you to explictly remove a file (if you just rm it, then commit it is then it is gone and it doesn’t show up as a modified file in the ChangeLog).
Everybody using mercurial should have hgk
I have not been able to fully reproduce what happened. My current advice is that everyone explicitly name the changeset they are changing merging to and do a diff to make sure they are doing what they intend.
The big problem is that once you begin to branch, files that you have not touched, but somebody else on a divergent branch has touched appear to be modified and you don’t want to check in your modified (ie older files)
I wish I had a good way of making this clear to everyone, but I don’t yet. So far everything I look at implies that our tool is working as deseigned, but we all have to be release engineers and worry about how we are handeling our branches on a much deeper level than with centralized source control.
All my bugs are out of UI complete, but that doesn’t mean that I have an easy workload. I am taking Friday off, so I geuss I will need to be working on Saturday to take out some easy bugs.