LINUX.ORG.RU
решено Форум — Development  

Ветка в Mercurial, как это выглядит на диске?


0

2

Доброго времени суток! представим такую ситуацию, есть репозитарий repo в ~/projects/repo. В repo 2 папки: src(где сам код) и test(где мелкие тестовые програмульки). В нём делаем всё как полагается hg init, hg add, hg commit. Я захожу в ~/projects/repo/src/ открываю там файлик скажем test.c правлю его, потом делаю коммит. Всё это в основной ветке. Теперь я делаю новую ветку скажем feature: hg branch feature и переключаюсь на неё hg update feature. Снова вносим изменения в файлик и снова коммитим. И так может быть несколько раз. Теперь я хочу поработать со старой веткой, переключаюсь снова на default. Вопрос, что будет с моим файликом(test.c)? Ведь в этой ветке он другой, в этой ветке правок(как в ветке feature)я ещё не вносил. Т.е я зайду в папку ~/projects/repo/src/ открою мой test.c и он будет со всеми моими изменениями, что я внёс для ветки feature? Объясните на пальцах, как всё это будет выглядеть? И как работать с кодом, если я буду прыгать с ветки на ветку, что будет с файлами на диске?

★★★★★
← Есть ли смысл использовать c++ интерфейс gtkmm для библиотеки gtk+
[мнение смаллтолкеров]GNU Smalltalk →

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

post-factum ★★★★★
()
Ответ на: комментарий от post-factum

Т.е в моём случае, когда я буду «прыгать с ветки на ветку», файлик (в моём случае test.c) в директории ~/projects/repo/src/ будет каждый раз заменяться, в зависимости от того на какой я ветке? Я правильно понял?

xterro ★★★★★
() автор топика
Ответ на: комментарий от xterro

Стало понятней, спасибо :)

если собираешься плотно с ветками работать, то лучше уходи на git. на hg проще работать с клонами проектов, на git'e ветки реально сделаны функциональнее гораздо.

p.s. сам вот недавно съезжал с hg на git именно из за этого, хотя для мелких поделий с hg проще.

real_maverick ★★★
()
Ответ на: комментарий от real_maverick

> на hg проще работать с клонами проектов, на git'e ветки реально сделаны функциональнее гораздо

Почти не сталкивался с git, но часто использую hg. В чем выражается это «функциональнее гораздо»?

kamre ★★★
()
Ответ на: комментарий от real_maverick

У меня пока меленький проект, завел репу на bitbucket.org и клепаю потихоньку, супер большого числа веток не планируется, думаю максимум 2-3 ветки в будущем. Да и наверняка стандартного механизма «создал ветку - переключился в неё, поработал - смержил с основной» хватит, супер выкрутасов не понадобится... имхо

xterro ★★★★★
() автор топика
Ответ на: комментарий от marvin_yorke

Т.е. возможен один changeset как результат merge более двух веток сразу? Вроде это не так уж и важно.

Важнее то, что происходит, когда во время такого merge появляются кофликты, которые нужно вручную разрешать. Как это представляется в графическом виде? Для двух веток обычно запускается three-way merge, где слева одна ветка, справа - другая, а по середине результат.

kamre ★★★
()
Ответ на: комментарий от kamre

к сожалению не знаю, для дома тоже выбрал хг, на работе - Clearcase

marvin_yorke ★★★
()
Ответ на: комментарий от marvin_yorke

гит вроде как (лучше) мерджит несколько брэнчей за раз

По-моему, мержить несколько веток за раз - это fail структуры проекта :) Хотя сам недавно такое мержил: 

|
o    changeset:   1163:3ae72c386fa4
|\   parent:      1162:5931cf1b258f
| |  parent:      1161:e53787c2f91f
| |  user:        Balancer <balancer@balancer.ru>
| |  date:        Wed Jan 19 13:50:09 2011 +0300
| |  summary:     merge
| |
| o    changeset:   1162:5931cf1b258f
| |\   parent:      1158:441b9342a3c9
| | |  parent:      1160:01e3d1ac2899
| | |  user:        Balancer <balancer@balancer.ru>
| | |  date:        Wed Jan 19 13:47:40 2011 +0300
| | |  summary:     ++
| | |
o | |  changeset:   1161:e53787c2f91f
| | |  parent:      1159:13f94379dd25
| | |  user:        Balancer <balancer@balancer.ru>
| | |  date:        Wed Jan 19 13:37:58 2011 +0300
| | |  summary:     Дорабатываем LCML-разметку.
| | |
+---o  changeset:   1160:01e3d1ac2899
| |    user:        Balancer <balancer@balancer.ru>
| |    date:        Mon Jan 17 13:20:34 2011 +0300
| |    summary:     ++
| |
o |  changeset:   1159:13f94379dd25
| |  parent:      1157:e80431612a8b
| |  user:        Balancer <balancer@balancer.ru>
| |  date:        Sun Jan 09 20:46:56 2011 +0300
| |  summary:     ++
| |
| o  changeset:   1158:441b9342a3c9
|/   user:        Balancer <balancer@balancer.ru>
|    date:        Mon Jan 17 05:19:46 2011 +0300
|    summary:     Заготовка под использование псевдо-pure-html. Плюс накопившееся.
|

Не... У меня до 4-х веток бывало. Но только от своей лени :)

| | |
| o |    changeset:   1075:524676abf434
| |\ \   parent:      1074:89576e9e90d6
| | | |  parent:      1073:4d7440d2e77b
| | | |  user:        Balancer <balancer@balancer.ru>
| | | |  date:        Tue Nov 23 03:00:14 2010 +0300
| | | |  summary:     merge
| | | |
| | o |  changeset:   1074:89576e9e90d6
| | | |  parent:      1072:a53845409712
| | | |  user:        Balancer <balancer@balancer.ru>
| | | |  date:        Tue Nov 23 03:00:03 2010 +0300
| | | |  summary:     merge
| | | |
| o | |  changeset:   1073:4d7440d2e77b
| | | |  parent:      1070:35c23f3a79a6
| | | |  user:        Balancer <balancer@balancer.ru>
| | | |  date:        Tue Nov 23 02:59:22 2010 +0300
| | | |  summary:     ++
| | | |
| | o |  changeset:   1072:a53845409712
| |/ /   parent:      1070:35c23f3a79a6
| | |    user:        Balancer <balancer@balancer.ru>
| | |    date:        Tue Nov 23 02:53:07 2010 +0300
| | |    summary:     Ох, сколько всякой фигни... Давно с этой машины не коммитился. Неоттестированный find_all()
| | |
o | |  changeset:   1071:c270ca611acd
|/ /   user:        Balancer <balancer@balancer.ru>
| |    date:        Thu Nov 25 20:42:31 2010 +0300
| |    summary:     Ещё немного оптимизаций.
| |
KRoN73 ★★★★★
()
Ответ на: комментарий от kamre

В чем выражается это «функциональнее гораздо»?

в git есть stash, что в разработке очень сильно помогает, в hg есть аналог расширения (не помню как зовется), но не так удобно

git remote add NAME URL - добавляет тебе именованные удаленные репы, потом git push/pull по имени удобно делать, все становится гораздо более прозрачным.

git config - посмотри опции, настраивается все про все, честно говоря 90% не надо или только для крайне специфичных случаев

git merge - имеет политики мёрджа, которые (например tree) сильно облегчаю жизнь

git diff легко сравнивает репы (или ветки) и так же как и в мёрдже есть разные политики сравнения

при push fetch pull можно указать именно ветку которую забираешь, чего нельзя в hg

git log/diff - имеет статистики по комитам и изменениям, померять можно практически все

git commit - может комитеть с точностью до строк кода, при этом твои изменения локальные не пропадут и будут доступны и актуальны

расширение gitosis для групповой раздачи и управления репками

2е политики работы с submodule, на основании веток и модулей (в hg subrepos - но он несколько неадекватно себя ведет)

это вот вкратце, что подвигло перехать с hg на git

p.s. hg __гораздо__ проще git'а и для старта или маленьких проектов я бы все таки рекомендовал hg, время вхождения в git гораздо больше.

real_maverick ★★★
()
Ответ на: комментарий от real_maverick

в git есть stash, что в разработке очень сильно помогает, в hg есть аналог расширения (не помню как зовется), но не так удобно

есть hg shelve, который является полным аналогом. есть расширение Mercurial Queues, которое позволяет делать ТАКИЕ ВЕЩИ, что практически весь комплекс команд по редактированию истории репозитария git, да и могучие гитовые бренчи, становится ненужным

git remote add NAME URL - добавляет тебе именованные удаленные репы, потом git push/pull по имени удобно делать, все становится гораздо более прозрачным.

то же самое в hg

при push fetch pull можно указать именно ветку которую забираешь, чего нельзя в hg

про ветки уже сказали выше, что в hg лучше работать с клонами репозитария, а не с ветками. но если нужно именно это - в качестве параметра команды pull/push можно указать -r имя_ветки.

git log/diff - имеет статистики по комитам и изменениям, померять можно практически все

вроде бы тоже все

git commit - может комитеть с точностью до строк кода, при этом твои изменения локальные не пропадут и будут доступны и

актуальны не совсем понял, а этого нет в других vcs?

расширение gitosis для групповой раздачи и управления репками

сам не пользовался, но вроде есть mercurial-server

по остальному возражать не буду, чего нет того нет :). я к тому, что hg достаточно крутой и для немаленьких проектов. и при этом дизайн его несколько логичнее, я бы сказал, академичнее, чем у git. и кроссплатформенность нормальная есть.

Slackware-ch
()
Ответ на: комментарий от real_maverick

форматирование съехало, прошу прощения

в git есть stash, что в разработке очень сильно помогает, в hg есть аналог расширения (не помню как зовется), но не так удобно

есть hg shelve, который является полным аналогом. есть расширение Mercurial Queues, которое позволяет делать ТАКИЕ ВЕЩИ, что практически весь комплекс команд по редактированию истории репозитария git, да и могучие гитовые бренчи, становится ненужным.

git remote add NAME URL - добавляет тебе именованные удаленные репы, потом git push/pull по имени удобно делать, все становится гораздо более прозрачным.

то же самое в hg

при push fetch pull можно указать именно ветку которую забираешь, чего нельзя

в hg про ветки уже сказали выше, что в hg лучше работать с клонами репозитария, а не с ветками. но если нужно именно это - в качестве параметра команды pull/push можно указать -r имя_ветки.

git log/diff - имеет статистики по комитам и изменениям, померять можно практически все

вроде бы тоже все

git commit - может комитеть с точностью до строк кода, при этом твои изменения локальные не пропадут и будут доступны и актуальны

не совсем понял, а этого нет в других vcs?

расширение gitosis для групповой раздачи и управления репками

сам не пользовался, но вроде есть mercurial-server

по остальному возражать не буду, чего нет того нет :). я к тому, что hg достаточно крутой и для немаленьких проектов. и при этом дизайн его несколько логичнее, я бы сказал, академичнее, чем у git. и кроссплатформенность нормальная есть.

Slackware-ch
()
Ответ на: комментарий от real_maverick

p.s. hg __гораздо__ проще git'а и для старта или маленьких проектов я бы все таки рекомендовал hg, время вхождения в git гораздо больше.

Юзаю и git и hg, git в основном чисто для внешних проектов на любительском уровне, hg в личных целях. На работе внедряю hg - пациентов жалко... Как раз из-за простоты. На мой взгляд, работа с ветками в hg реализовано настолько удобно и просто, насколько это вообще возможно было создать...

I-Love-Microsoft ★★★★★
()
Ответ на: комментарий от JackyTreehorn

Тогда зачем система контроля версий, если можно каждое изменение в отдельную папочку, аналогично получается :)

xterro ★★★★★
() автор топика
Ответ на: комментарий от JackyTreehorn

> Я ваще с ветками не заморачиваюсь, даже для небольших изменений сразу делаю новый суппо^Wрепозиторий.

А разве не удобнее хранить ветви внутри одного репозитория с возможностью просмотра графического лога? Сразу же видно что и откуда пришло.

backbone ★★★★★
()
Ответ на: комментарий от backbone

Оно и так видно, когда мержишь. Правда, я часто пользуюсь rebase, тогда видно плохо :)

JackyTreehorn ★
()
Ответ на: комментарий от I-Love-Microsoft

Насколько я помню, сам Гуру советует пользоваться отдельными репозиториями. Правда, по серьезным поводам.
Может, я когда-нить до этого и дорасту :)

JackyTreehorn ★
()
Ответ на: комментарий от JackyTreehorn

а я понял Гуру иначе: он вроде не то что бы советует, но говорит о таковой возможности, которой нет у нераспределённых систем

backbone ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Есть ли смысл использовать c++ интерфейс gtkmm для библиотеки gtk+
Development
[мнение смаллтолкеров]GNU Smalltalk →