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