hg add default behaviour...

Dan North dan at tastapod.com
Sat Aug 25 17:52:16 CDT 2007


Giorgos Keramidas wrote:
> 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.

Another cool feature of hg that I didn't know about :)

>   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
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20070825/45ee8ff1/attachment.htm 


More information about the Mercurial mailing list