mercurial (hg)

[drBatty]

тут занялся изучением сабжа, возникло несколько вопросов:

1) у меня есть программа на С, в ней каталог src, и именно его я считаю репозиторием для hg. Это правильное решение? Или надо делать не так? И что делать со временным файлами в этом каталоге? Отключить их так:
hg addr -X *.bak
?
или можно и как-то это задавать? (в конфиге например)

2) хотелось-бы, что-бы после удачного завершения make версия сохранялась-бы... Это наверное что-то надо в Makefile прописать? или есть другое решение?

ЗЫЖ извините за тупые вопросы, лет пять назад использовал VSS, да и то - не много...

[deadhead]

ЗЫЖ извините за тупые вопросы, лет пять назад использовал VSS, да и то - не много...

Mercurial: The Definitive Guide

Файлы исключеия можно задать в .hgignore.

[drBatty]

Mercurial: The Definitive Guide

ага. спасибо. клонировал 18 метров чего-то. буду изучать... жаль по-русски нету...

PS: вот нашёл интересное по теме:
http://mercurial.selenic.com/wiki/TipsAndTricks

[drBatty]

Подскажите пожалуйста:

У меня есть репозиторий А, и я сделал его клон Б.

Затем эти репозитории развивались и комментились независимо.

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

И теперь я и не знаю, как мне быть: даже если стереть эту проблемную строчку в Б, hg всё равно не даёт мне слить ветки, говорит, что не закоммитеная. И закомминить не даёт. Что делать? Хотелось-бы всё-же слить ветки (что будет с проблемной строкой меня не слишком волнует - её я перепишу заново).

ЗЫЖ вышла новая стабильная версия сабжа: date: Wed Apr 07 16:55:01 2010 +0200

[deadhead]

hg resolve?

[/dev/random]

Попробуйте, например, сделать в Б "промежуточный" коммит, который можно будет слить с А.

[drBatty]

hg resolve?

тоже не получается :(

Попробуйте, например, сделать в Б "промежуточный" коммит, который можно будет слить с А.

дык не даёт комменты делать - как я понял голова из А самая новая...

Код: Выделить всё

@ 7: горлова из А
|
|
|   o 6: голова из б
|   |
|   |
|   |
|   |
|   o 5
|   |
|/
o 4
|

такое в Б...

[/dev/random]

Ну так переключитесь на голову из Б. Или я вас не так понял?

[drBatty]

Ну так переключитесь на голову из Б. Или я вас не так понял?

э... простите ламера... а как?

[/dev/random]

hg update -C голова_из_Б

Учтите, что вы потеряете незакоммиченные изменения.

[drBatty]

hg update -C голова_из_Б

Учтите, что вы потеряете незакоммиченные изменения.

а... там "важных" файлов всего 2: Makefile & main.cpp :)
и в каждом 10 строк :)
жаль они на другом компе, сейчас попробую воспроизвести...

[drBatty]

hg update -C голова_из_Б

Учтите, что вы потеряете незакоммиченные изменения.

ага. теперь понятно. Спасибо.

ЗЫЖ незакоммиченые изменения всегда можно сохранить в файл командой hg diff >i.diff

[t.t]

1) у меня есть программа на С, в ней каталог src, и именно его я считаю репозиторием для hg. Это правильное решение? Или надо делать не так?

Зависит исключительно от того, есть ли за пределами src файлы, которые нужно версифицировать.

2) хотелось-бы, что-бы после удачного завершения make версия сохранялась-бы... Это наверное что-то надо в Makefile прописать? или есть другое решение?

Наверняка есть и другие, но через мейкфайл, пожалуй, самое "правильное".

[drBatty]

hg update -C голова_из_Б

хм... данная история имеет продолжение:

• я создал 2 клона, и работал с ними в разное время и на разных компьютерах
• через некоторое время я выполнил с "главной" версии hg pull второй_вариант, и у меня опять ничего не получилось:
  три файла конфликтовали.
• откатился в главной ветке, удалил файлы из репок и сделал коммит
• тоже самое со второй веткой
• потом всё успешно слил
• потом исправил код так, что-бы он не портил эти конфликтные файлы.
• затем добавил эти файлы

Похоже, есть способ проще? Вот только какой?

[t.t]

drBatty, может быть, вот это поможет:
http://mercurial.selenic.com/wiki/TutorialConflict
Возможно, предварительно стоит прочитать предыдущую часть:
http://mercurial.selenic.com/wiki/TutorialMerge
Она есть и по-русски (следующую пока не перевели).

[drBatty]

Она есть и по-русски (следующую пока не перевели).

я читал. про разрешение конфликтов там нет.

http://mercurial.selenic.com/wiki/TutorialConflict

а здесь коротенько есть. но я не понял...

[t.t]

Она есть и по-русски (следующую пока не перевели).

я читал. про разрешение конфликтов там нет.

http://mercurial.selenic.com/wiki/TutorialConflict

а здесь коротенько есть. но я не понял...

А что именно непонятно? Там ведь всё просто. Или наоборот: слишком просто? Т.е. недостаточно раскрыто для применения на реальной проблеме? Если так, попробуйте посмотреть hgbook, в частности Merging conflicting changes, а также, возможно, Dealing with tricky merges.

[drBatty]

в частности Merging conflicting changes, а также, возможно, Dealing with tricky merges.

ага. теперь понял.
пойду потренируюсь...

[drBatty]

2) хотелось-бы, что-бы после удачного завершения make версия сохранялась-бы... Это наверное что-то надо в Makefile прописать? или есть другое решение?

Наверняка есть и другие, но через мейкфайл, пожалуй, самое "правильное".

я тут подумал, что промежуточных коммитов будет слишком много. настолько, что придётся делать отдельный репозиторий "testing". Похоже так все и делают...

[t.t]

2) хотелось-бы, что-бы после удачного завершения make версия сохранялась-бы... Это наверное что-то надо в Makefile прописать? или есть другое решение?

Наверняка есть и другие, но через мейкфайл, пожалуй, самое "правильное".

я тут подумал, что промежуточных коммитов будет слишком много. настолько, что придётся делать отдельный репозиторий "testing". Похоже так все и делают...

За всех не скажу, а у нас в рабочих проектах планируется иметь как минимум три постоянных ветки. Условно их можно назвать, скажем, release, testing и current. В последней будет, собственно, "неприкрытый" рабочий процесс; во вторую будет попадать только тот код, который передаётся тестировщикам; а в первую -- прошедший тесты и подготовленный к выпуску в виде очередной версии прошивки. Вполне вероятно, что для некоторых проектов в процессе реальной работы дерево ещё немного разрастётся.

[drBatty]

За всех не скажу, а у нас в рабочих проектах планируется иметь как минимум три постоянных ветки. Условно их можно назвать, скажем, release, testing и current.

угу. а внести эти "ветки" в один репозиторий нет никакой возможности? или они и так в одном?

[t.t]

2) хотелось-бы, что-бы после удачного завершения make версия сохранялась-бы... Это наверное что-то надо в Makefile прописать? или есть другое решение?

Наверняка есть и другие, но через мейкфайл, пожалуй, самое "правильное".

я тут подумал, что промежуточных коммитов будет слишком много. настолько, что придётся делать отдельный репозиторий "testing". Похоже так все и делают...

За всех не скажу, а у нас в рабочих проектах планируется иметь как минимум три постоянных ветки.

Сразу сам не заметил, потому специально подчеркну: я говорил именно про отдельные ветки, а не отдельные репозитории.

[t.t]

За всех не скажу, а у нас в рабочих проектах планируется иметь как минимум три постоянных ветки. Условно их можно назвать, скажем, release, testing и current.

угу. а внести эти "ветки" в один репозиторий нет никакой возможности? или они и так в одном?

Насчёт "внести" не знаю. Их надо изначально оттуда не выносить.

[t.t]

Да, ссылки насчёт веток забыл. Всё та же hgbook. Для начала: Revision history, branching, and merging, затем Working with multiple branches. И в качестве advanced reading можно просмотреть всю главу Managing releases and branchy development.

[drBatty]

А что именно непонятно? Там ведь всё просто. Или наоборот: слишком просто?

а на самом деле всё действительно очень просто: достаточно поставить kdiff3, и прописать его в ~/.hgrc
после чего можно с лёгкостью разрешать любые конфликты. Не менее удобнее это делать и с помощью vim. Попробовал оба способа - всё просто примитивно и писать об этом нечего. По выше перечисленным ссылкам рассказано как это всё сделать.

tp://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html""]Managing releases and branchy development[url].

PS: ссылка побилась...

[t.t]

А что именно непонятно? Там ведь всё просто. Или наоборот: слишком просто?

а на самом деле всё действительно очень просто: достаточно поставить kdiff3, и прописать его в ~/.hgrc
после чего можно с лёгкостью разрешать любые конфликты. Не менее удобнее это делать и с помощью vim. Попробовал оба способа - всё просто примитивно и писать об этом нечего. По выше перечисленным ссылкам рассказано как это всё сделать.

Да, я имел ввиду, что описание из туториала уже даже излишне упрощено. А mercurial мне тем и нравится, что ничего сложного (после прочтения документации) в нём нет, что для столь мощного инструмента как dvcs даже удивительно.

tp://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html""]Managing releases and branchy development[url].

PS: ссылка побилась...

Спасибо, поправил.

[drBatty]

А mercurial мне тем и нравится, что ничего сложного (после прочтения документации) в нём нет, что для столь мощного инструмента как dvcs даже удивительно.

я сам в шоке (особенно после знакомства с VSS, которая должна быть вообще-то проще) :)

[t.t]

А mercurial мне тем и нравится, что ничего сложного (после прочтения документации) в нём нет, что для столь мощного инструмента как dvcs даже удивительно.

я сам в шоке (особенно после знакомства с VSS, которая должна быть вообще-то проще)

VSS это вообще очень показательный пример того, как ms умееть взять в целом хорошую концепцию и испоганить даже не то что до неузнаваемости, а почти до чего-то противоположного (да ещё и за деньги).

[deadhead]

туториал от Joel Spolsky

[t.t]

туториал от Joel Spolsky

Он чем-то примечателен по сравнеию с hgbook, не подскажете?