Why do > for fname in wctx.files() > if fname not in wctx: > continue
instead of > for fname in wctx.modified() + wctx.added() ? Is the sort() implied by files() important? (The "fname not in" clause is intended to exclude files removed in the working context, right?) Per this comment in the bug report: > Note that the issue with git-formatted diffs only occurs if the > destination file already existed *at the time you did a copy or rename > over it*, not (to the best of my knowledge), if a file has ever > previously existed by that name. ...then shouldn't you also be excluding removals from the "fname in p" part of: > if rn: > for p in pctxs: > if fname in p: > ret.append((rn[0], fname)) Otherwise, if a versioned file was removed in both parent changesets, and you copy/rename onto it, you'll return it incorrectly, right? Also, don't you want a "break" after the ret.append here? --Mark On Thu, 8 May 2008, Richard Lowe wrote: > Date: Thu, 08 May 2008 15:03:36 -0400 > From: Richard Lowe <richlowe at richlowe.net> > To: scm-migration-dev at opensolaris.org > Subject: [scm-migration-dev] Please review #418 > > > Hey all, > > I need code review for: > #418 git formatted hg diffs can lose copies/renames > > http://cr.opensolaris.org/~richlowe/scm_418 > > Note, that while the synopsis may suggest otherwise, this only relates > to dealing with this in Backup, such that a backup/restore of such a > workspace does not lose information. > > I'd expect the number of possible victim workspaces to be very very > low, you need a rename or copy over an existing, versioned, file and > that change needs to have not yet been committed when you take the > backup. > > I'm not particularly attached to either the filename or method name > involved here... > > Thanks, > > -- Rich > _______________________________________________ > scm-migration-dev mailing list > scm-migration-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/scm-migration-dev >
