http://bugs.grommit.com/show_bug.cgi?id=418
------- Comment #10 from richlowe at richlowe.net 2008-03-26 01:16 PDT ------- (In reply to comment #9) > (In reply to comment #8) > > > I don't think it's identical to it. > > Right. I remembered the exact scenario after I filed comment #7. > The Mercurial equivalent would be "hg mv foo bar; hg add foo". > > I did some quick tests to see how bad our exposure was. If the target > file existed in one of the changesets that the diff spans, there's a > problem. So if the deletion happens in rev N, then "hg diff -g -r > <N+1>:tip" will be okay, but "hg diff -g -r N:tip" will not show the > copy/rename. (Which I think is the same as what you said.) > > How does backup work if there are multiple changesets? Is each one > exported individually? Uncommitted changesets are exported as a diff, committed changesets as a bundle, so we are only diff -g'ing one logical set of change > Still, given that this scenario isn't going to be likely, I'm thinking > it should not be a stopper, at least not for the initial putback. > > By the way, the release announcement for 1.0 mentioned > > * improved copy/rename handling in diffs, status, and merge > > Do we have any more information on this? I'm still trying to figure out a couple of things in relation to that, it's better in a bunch of cases, but possibly slightly worse (at least for us) in one. The problem mentioned here is still present. -- Configure bugmail: http://bugs.grommit.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
