Mercurial и перемещение файла.

ага, git.

Хм. Сейчас специально проверил. Если делать через hg addremove, то --similarity срабатывает как заявлено. Т.е. после переименования файла выполнение hg addremove детектирует переименование файла, и аннотации показываются правильно. Если же коммитить сразу через hg commit -A, аннотация показываются неправильно.

Видимо, как вариант, можно попробовать заняться правкой истории с выполнением на коммитах переименования hg addremove.

Надо было использовать систему контроля версий вместо hg

в hg неизменность истории не баг, а заявленная фича. Потому наверное никак, надо сразу было нормально переносить (hg addr)

банально переместили файлы, переименовали каталоги.

т.е. не использовали hg mv ?

в hg неизменность истории не баг, а заявленная фича. Потому наверное никак, надо сразу было нормально переносить (hg addr)

Минутку, что такое hg addr? Почему я об этой штуке не знаю? :) Неужели оно правильно отработает переименование файла в 100 Мб и размер репозитория не вы вырастет на 100 Мб?

т.е. не использовали hg mv ?

А оно думаешь не отрабатывает как банальное удаление и добавление? :)

Минутку, что такое hg addr?

$ hg help addr
hg addremove [ПАРАМЕТР]... [ФАЙЛ]...

добавить все новые, удалить все отсутствующие файлы

    Добавляет все новые и удаляет все отсутствующие файлы из хранилища.

    Новые файлы игнорируются, если они подходят под любой шаблон в
    ".hgignore". Аналогично команде "add", изменения фиксируются при следующей
    фиксации.

    Используйте параметр -s/--similarity, чтобы найти переименованные файлы.
    Если этот параметр больше 0, то производится сравнение каждого удалённого
    файла с каждым добавленным, и если они достаточно похожи, то это
    фиксируется как переименование. Этот параметр принимает в качестве
    параметра "процент похожести" от 0 (отключено) до 100 (файлы должны быть
    одинаковыми). Этот способ нахождения переименованных файлов может
    оказаться затратным. После использования этого параметра можно
    использовать "hg status -C" чтобы проверить, какие файлы были
    идентифицированы как перемещенные или переименованные. Если этот параметр
    не задан, обнаруживаются только переименования идентичных файлов
    (--similarity = 100).

    Возвращает 0, если все файлы были успешно добавлены.

параметры:

 -s --similarity ПОХОЖЕСТЬ считать файлы переименованными исходя из степени их
                           похожести (от 0 до 100)
 -I --include ШАБЛОН [+]   добавить файлы, имена которых соответствуют данным
                           шаблонам
 -X --exclude ШАБЛОН [+]   не добавлять файлы, имена которых соответствуют
                           данным шаблонам
 -n --dry-run              ничего реально не делать, просто напечатать вывод

параметры, помеченные [+], могут указываться многократно

"hg -v help addr" - показать глобальные параметры

Почему я об этой штуке не знаю? :) Неужели оно правильно отработает переименование файла в 100 Мб и размер репозитория не вы вырастет на 100 Мб?

УМВР. Может когда-то давно были баги, или вы как-то не так делали. Я не знаю...

УМВР. Может когда-то давно были баги, или вы как-то не так делали. Я не знаю...

Надо попробовать, а то вопят «у hg не работает переименование файла и растет репозиторий» :)

А в каком месте ТС было важно переименовывать стометровые файлы?

После mv (и после addremove, но см. параметр --similarity) инфа о переименовании сохраняется и blame/annotate работает нормально.

Надо попробовать, а то вопят «у hg не работает переименование файла и растет репозиторий» :)

наверное они юзают hg add, она да, только добавляет. Если переименовать ./a → ./b, то оно добавит ./b, а ./a так и останется в репах. Также и если переименовать, изменить, и добавить, то с параметром -s100(дефолт) она добавит новый.

просто создатели mercurial'а хотели, что-бы оно и в маздае хорошо работало, а в маздае как-то черезжопно реализовано переименование. Ну вот погнались за двумя зайцами, и получилось как всегда. В смысле, когда-то давно эта фигня не очень хорошо работала.

Ты эксперт по hg, может у тебя есть рецепт русских названий в файлах между маздаем и макакосью и линупсом? (прошу прощения ТС-а что влез в чужую тему, но думаю всем меркуриальщикам было бы интересно)

Надо было использовать систему контроля версий вместо hg

+1

Ты эксперт по hg, может у тебя есть рецепт русских названий в файлах между маздаем и макакосью и линупсом?

нет, извини. Я каждый день юзаю hg, но у меня только Linux'ы. И везде utf-8.

Я слышал об этой проблеме, но не вдавался особо. Вроде кто-то на UFO решал. Может даже решил.

Какие есть варианты? можно както указать hg что этот файл не появился не из неоткуда, а был перемещен, и показать коммиты из первоисточника?

Вариантов без конвертации репозитория уже нет (а про hg mv или hg addremove уже сказали).

Тоесть мне нужно взять и ковырятся в истории? Что для этого лучше? Или лучше не стоит?

Про addr я уже вкурсе, но беда в том что, основная масса разработчиков делает пермещения в TortoiseHg, а оно, я так понимаю, делает без -s ключика, что и получилось в итоге...

Тоесть мне нужно взять и ковырятся в истории? Что для этого лучше? Или лучше не стоит?

Я думаю, что лучше не стоит - хэши поплывут, а это может оказаться полным абзацем.

Но всё же... если история полностью линейная, можно попробовать наделать патчей, накладывать их и вызывать hg addremove -s 95; если история нелинейная, можно покурить hg convert - у него есть опция указания переименования файлов вручную.

основная масса разработчиков делает пермещения в TortoiseHg

/me .oO( лохе епт )

а оно, я так понимаю, делает без -s ключика

Гугл говорит, что это настраивается: http://stackoverflow.com/questions/1295735/tortoisehg-copy-similarity-feature

Возможно, проблема в чем-то другом.

Есть такое расширение, evolve. Позволяет отдельные коммиты обновлять без правки истории, т.е. никаких проблем с чужими клонами. Правда, про конкретно переименование примеров нет.

Способ посмотреть, будет ли работать blame, если бы файл переместили нормально — hg up <до переименования>, сделать hg mv <file1> <file2>, потом смержить этот коммит в основную ветку (т.е. hg up <previous head> && hg merge). Рекомендую потренироваться на кошках.

Это с прошлым. А проблему с будущими переименованиями может решить настройка TortoiseHg, как уже сказали.

git не записывает, а угадывает переименование/копирование

искаробочным hg histedit, да

тут выше писали, что поплывут хэши, поэтому проще всего будет клонировать исправленный репозиторий заново (ну или посносить во всех клонах старые changesetы — это правильнее, но неоправданно дольше)