Вышел Mercurial 1.0

> А как насчёт svn externals?

Ты лучше расскажи, как svn:externals-ом 1 файл пометить? Ждать следующего релиза? Жаль :(

> Как на Mercurial сделать такую _простейшую_ вещь - checkout только одного каталога проекта?

Эту операцию из современных VCS только SVN и поддерживает. Если оно остро надо - то тебе в SVN.

> А как насчёт svn externals?

forest или хуки.

А как в SVN без text-bases? Упс. И этим людям не хватает "checkout только одного каталога проекта" o_O FYI, в Mercurial репозиторий и рабочая копия часто бывают меньше, чем одна рабочая копия SVN.

Отличный RCS, динамично развивающийся. Стоит того, чтобы обратить на него внимание.

Народ, подскажите как лучше всего вставить в программу собираемую из репозитория Mercurial номер ревизии?

Или другой сценарий - допустим я привык в начало каждого исходного файла вставлять некую шапку с датой последней правки, версией файла и т.п.

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

> Народ, подскажите как лучше всего вставить в программу собираемую из репозитория Mercurial номер ревизии?

changeset или id tip-а? (changeset не обязан совпадать для кучу клонированных репозиториев)

> Народ, подскажите как лучше всего вставить в программу собираемую из репозитория Mercurial номер ревизии?

А в чем проблема вставить в make фрагмент, запускающий hg id или что-то подобное? Я так и делаю, Кстати, именно _номер ревизии_ в Mercurial неуникален.

> Или другой сценарий - допустим я привык в начало каждого исходного файла вставлять некую шапку с датой последней правки, версией файла и т.п.

Тебе лучше отучаться от этой привычки - эту информацию дают hg log и hg ann. Но если тебе эта привычка очень дорога, попробуй http://www.selenic.com/mercurial/wiki/index.cgi/KeywordExtension

Спасибо!

Да, я понимаю, привычка вредная, идущая от времён когда системы контроля версий не использовались и вся revision history писалась прямо в шапке :)

>Hg рулит.

Блин. Hg не рулит. Ночью проделал охрененный объём работы по рефакторингу фреймворка. Утром по старой привычке сделал hg up перед hg ci. Все изменения молча и без предупреждения похерились.

> Утром по старой привычке сделал hg up перед hg ci

Плохие у тебя привычки :)

> Все изменения молча и без предупреждения похерились.

Что, даже *.orig не осталось? Какая версия hg и как сконфигурированы программы для merge?

>Плохие у тебя привычки :)

У меня привычка от командной работы. Закончив очередную модификацию, сделать update (потому что пока я пишу - другие пишут что-то тоже и коммитят это), если нужно, развести конфилкты, протестировать результат и закоммитить то, что вышло.

А какие привычки по-твоему более правильные? Сперва коммитить, а потом тестировать что же получилось в общем репозитории? :)

>> Все изменения молча и без предупреждения похерились.

>Что, даже *.orig не осталось?

Нет, ничего подобного не было.

> Какая версия hg и как сконфигурированы программы для merge?

0.9.5-r1, конфигурация по умолчанию, в hgrc прописан только дефолтовый центральный репозиторий.

> А какие привычки по-твоему более правильные? Сперва коммитить, а потом тестировать что же получилось в общем репозитории? :)

Зависит. Проще всего - коммитить, сливать изменения из центра, мержить, тестировать, исправлять (если надо) и отправлять в центр. Хотя Мэтт так делать не рекомендует, мы так и делаем :) только вдобавок еще юзаем mq, чтобы избежать больших коммитов, в которых смешаны разные вещи (при работе на чем-то экзотическом типа FUSE ftpfs это дает еще один бонус - изменения сохраняются еще и в виде патчей). Еще можно забубенит Лиукс-стайл, но нам это не нужно - команда маленькая. А update - это фундаментальное зло: "CVS loses information every time there is parallel development because you are forced to merge before you check in if someone else checked in first. The state of your workspace before the merge is lost forever. Another way to say this is that if there is N-way parallel development, CVS loses N-1 events" (с) L. McVoy

Насчет уничтожения изменений - никогда такого не видел вообще O_o Битые репозитории пару раз получал, но рабочая копия всегда сохранялась.

       update [-C] [-d DATE] [[-r] REV]
man hg:


           Update the working directory to the specified revision, or the tip of the current branch if none is specified.

               If the requested revision is a descendant of the working
               directory, any outstanding changes in the working directory will
               be merged into the result. If it is not directly descended but is
               on the same named branch, update aborts with a suggestion to use
               merge or update -C instead.

               If the requested revision is on a different named branch and the
               working directory is clean, update quietly switches branches.

               See ╢hg help dates╢ for a list of formats valid for --date.

               options:
               -C, --clean  overwrite locally modified files
               -d, --date   tipmost revision matching date
               -r, --rev    revision

               aliases: up checkout co

очень странно. у меня таких эффектов ни разу не наблюдалось.

>очень странно. у меня таких эффектов ни разу не наблюдалось.

Повторить сейчас не удалось. Внесённые параллельно в два репозитория изменения автоматически замержились. Но факт остаётся фактом - сегодня утром оно по hg pull && hg up снесло массу ночных обновлений. И пару раз натыкался на такие же потери на неделе, но по мелочи, поэтому и внимания не обращал. Где-то там подводный камень есть.

KRoN73, ты уверен, что ненароком hg update -C не сделал?

Делал hg update кучу раз. Ничего никуда не пропадало.

> еще юзаем mq

Ага, mq рулит. Обычно внешние изменения добавляю так:

hg pull
hg qpop -a
hg update
hg qpush -a