hg add default behaviour...

[Giorgos Keramidas]

On 2007-08-25 12:32, Dan North <dan at tastapod.com> wrote:
> Thanks Kevin, that looks pretty cool!
>
> Actually that's one of the things that's winning me over to hg from
> darcs, is the amount of cool contrib stuff from the community.
>
> The big win for me would be if hg could track svn copy/mv or vice
> versa in my local copy, so they both carried the history of file
> renames. At the moment, whichever I use to rename, the other one gets
> out of sync or has a senior moment (involving lots of ? and ! in the
> status). It's not that big of a deal but it would be nice.

FWIW, I've had varying levels of success with "hg addremove
--similarity" for this sort of thing.  Updating from Subversion
and then doing:

    % hg addremove -s 98

tends to work pretty well if the following are true:

    * You make it a point to update to the next Subversion change.

      This way it's harder to grab multiple Subversion commits in one
      "svn up" run, which could reduce the chances of --similarity
      working when a file has been renamed *and* modified a lot after
      the rename.

    * There are no files which are renamed *and* modified a lot in one svn commit

      I haven't tried renaming a file in Subversion *and* modifying it
      before "svn commit", but if this is supported then it could mess
      the heuristics of "hg addremove -s"

These two assumptions may be two assumptions too many in some cases, but
for the Subversion trees I have pulled files from so far they seem to be
true.

- Giorgos