Здравствуйте, Аноним, Вы писали:

D>>В SVN tag и branch — это одно и то же, так что в копировании туда-сюда смысла не видно.

А>По договоренности tag — неизменяемая ветка. Коммитить туда нельзя.

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

Здравствуйте, Donz, Вы писали:

D>Здравствуйте, Аноним, Вы писали:

D>>>В SVN tag и branch — это одно и то же, так что в копировании туда-сюда смысла не видно.

А>>По договоренности tag — неизменяемая ветка. Коммитить туда нельзя.

D>Ну да. Точно также можно договориться не коммтить в тот или иной бранч. Хотя чуть труднее следить за исполнением договоренностей.
а для этого есть commit хуки и всякие ACL -- посылать нафиг всех кто пытаецо закоммитить куда не положено

Здравствуйте, Кодёнок, Вы писали:

Кё>Это верно. Ты вот очень извращенно представляешь себе, как VCS работают.

Камрад, я с кучей VCS работал, и занимался процессом контроля версий и всем что с ним связано порядка 5 лет. Так что это не извращенное понимание, это понимание процесса "сверху", исходя из практик, общепринятых в отрасли. Звучит пафосно но на SVN свет клином не сошелся.
Если есть какая-то фича SVN, позволяющая воскрешать удаленные ветки (взяв предыдущую ревизию), то это не значит, что так и надо делать.

Кё>Современные сделаны так, чтобы из них ничего никуда пропасть не могло. Удаленный бранч никуда не исчезает. Можно в любой момент восстановить, продолжить, откатить, история изменений смотрится одной командой совершенно безотносительно, есть ли головной ревизии ссылка на этот бранч или нет.

Да забудь про ревизии. Я серьезно. И отойди на минуту от идеологии SVN.
Система контроля версий — она для хранения версий. Если что-то тебе в ней мозолит глаза — это проблема не количества бранчей, а системы контроля, которая вываливает тебе этих бранчей несметное количество.
Ты разве удаляешь запросы на изменения (багрепорты или как ещё они называются в твоей системе отслеживания ошибок), когда бага пофиксена? Записи ведь уже не нужны — ну так давайте и их грохать, зачем захламлять базу? Конечно, эти записи останутся в репликах БД, которые постоянно делаются админами — и можно будет восстановить. Но надо ли их вообще удалять?

Кё>Есть же общеизвестные правила:
Кё>- не комментируйте ненужный код, а удаляйте насовсем — он все равно сохранен в VCS
Кё>- не помечайте файлы NOT USED, не оставляйте пустых файлов и папок, а удаляйте насовсем — их всегда можно восстановить

Всё верно.

Кё>"не оставляйте ненужных бранчей" — просто логическое продолжение того же самого

Не верно. Логично тогда вообще удалять всё, что не является актуальным более 2-3 недель, как это делает камрад zaufi из этой же ветки. У каждого свой стиль работы, с этим не поспоришь. Однако для меня, как для СМ-инженера, это кощунство

Кё>Держать проект в чистоте и порядке — это очень огромный плюс, который перевесил бы немало минусов, если бы они были.

Содержи, кто тебе мешает. Но сохранение истории изменений — это разве не сохранение порядка?

Здравствуйте, Mr.Cat, Вы писали:

MC>А какую пользу ты собираешься извлечь из висящего реинтегрированного бранча? Единственная, какую я вижу — сразу видно, какие бранчи были в принципе, за все время проекта — т.е. какбы дополнительные точки входа в историю.

Скажу на примере своего опыта. Я проработал 3 года интегратором на крупном проекте с порядка 100-150 участниками по всему миру, использовали IBM Rational ClearCase. Так вот на таких проектах возможность просмотреть все бранчи (без выдергивания предыдущих ревизий и прочих приседаний) — пригождалась постоянно.
Потому что даже спустя 2-3 месяца возникала необходимость посмотреть кто внёс дельту, по какому запросу на изменение он это сделал, откуда делал слияние исходников, был ли сделан upmerge и на какой baseline, куда ещё пошли изменения с этой же ветки. Кстати, мёрж с одной ветки на разные релизные ветки — это достаточно распространенная распространенная практика, и не только на крупных проектах. И необходимость проследить историю веток и мёржей без просматривания разного количества предыдущих ревизий — это жесткая необходимость.
В случае с удалением бранчей из текущей ревизии подобная модель разработки была бы очень трудоемкой.

On 28/01/2010 00:55, Aquary wrote:

> Кё>Это верно. Ты вот очень извращенно представляешь себе, как VCS работают.
> Камрад, я с кучей VCS работал, и занимался процессом контроля версий и
> всем что с ним связано порядка 5 лет. Так что это не извращенное
> понимание, это понимание процесса "сверху", исходя из практик,
> общепринятых в отрасли. Звучит пафосно но на SVN свет клином не сошелся.
> Если есть какая-то фича SVN, позволяющая воскрешать удаленные ветки
> (взяв предыдущую ревизию), то это не значит, что так и надо делать.
Они не воскрешаются, а достаются из истории. В svn в принципе ничего нельзя уничтожить.

Попиарю git ещё.. он показывает всю историю мерджей в виде красивого графа, так что сами ветки не нужны. После слияния ветки история тоже сливается.

А вообще, у Линуса Т. проект поболее 5 лет и исходников, и участников проекта думаю на порядок или даже два больше, чем у было у тебя. И не смотря на это, удалять ветки там можно очень легко, мало того, там можно и историю редактировать — удалять ревизии и т.п. (супер штука — rebase).
Если бы сохранялись все ветки Линукса — оно бы загнулось быстро.

> Да забудь про ревизии. Я серьезно. И отойди на минуту от идеологии SVN.
> Система контроля версий — она для *хранения версий*. Если что-то тебе в
> ней мозолит глаза — это проблема не количества бранчей, а системы
> контроля, которая вываливает тебе этих бранчей несметное количество.
> Ты разве удаляешь запросы на изменения (багрепорты или как ещё они
> называются в твоей системе отслеживания ошибок), когда бага пофиксена?
Конечно, переводишь её в состояние closed, что равнозначно удалению в svn. Логическое удаление называется.

> Записи ведь уже не нужны — ну так давайте и их грохать, зачем захламлять
> базу? Конечно, эти записи останутся в репликах БД, которые постоянно
> делаются админами — и можно будет восстановить. Но надо ли их вообще
> удалять?
Для восстановления удалённого в svn не нужно звать админов, как и для поиска закрытых багрепортом достаточно пошарить по истории.

> Не верно. Логично тогда вообще удалять всё, что не является актуальным
> более 2-3 недель, как это делает камрад zaufi из этой же ветки. У
> каждого свой стиль работы, с этим не поспоришь. Однако для меня, как для
> СМ-инженера, это кощунство
Дык в svn удаление логическое. Может в clear case это было проблемой, я не знаю эту систему. Но, по-моему, это страшный динозавр, не удивлюсь, что там всё плохо.

> Кё>Держать проект в чистоте и порядке — это очень огромный плюс, который
> перевесил бы немало минусов, если бы они были.
> Содержи, кто тебе мешает. Но сохранение истории изменений — это разве не
> сохранение порядка?
В svn историю испортить можно только прямым доступом к файлам репозитория.

Здравствуйте, ., Вы писали:

.>Если бы сохранялись все ветки Линукса — оно бы загнулось быстро.

Ну, если б git загнулся от подобной нагрузки — это говорило бы не в пользу git Потому как Линус напирал на то, что уж он-то теперь сделал по-настоящему правильную систему и остальные нервно курят. В пристнопамятной презентации он как только не ругал SVN и CVS, приговариявая, что уж у него-то SVN done right.

.>Дык в svn удаление логическое. Может в clear case это было проблемой, я не знаю эту систему. Но, по-моему, это страшный динозавр, не удивлюсь, что там всё плохо.

ClearCase не трож! Там всё отлично. Идеология отличается от SVN — и многие не могут переварит данного факта. Просто они для разных задач сделаны, соответственно, идеологии тоже отличаются.

.>В svn историю испортить можно только прямым доступом к файлам репозитория.

Короче, главное, чтобы задачи разработчиков и интеграторов решались как можно менее затратно. Если кому-то удобно удалять — на здоровье.

Здравствуйте, Donz, Вы писали:

А>>По договоренности tag — неизменяемая ветка. Коммитить туда нельзя.

D>Ну да. Точно также можно договориться не коммтить в тот или иной бранч. Хотя чуть труднее следить за исполнением договоренностей.

К слову, в большинстве системах контроля версий — метки и ветки принципиально разные сущности. Метки — вешаются на версию, а ветки — отращиваются от версий. В CVS, Perforce, Clearcase — как и в других — в tag нельзя ничего закоммитить даже теоретически.

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

On 28/01/2010 02:19, Aquary wrote:

> Ну, если б git загнулся от подобной нагрузки — это говорило бы не в
> пользу git Потому как Линус напирал на то, что уж он-то теперь сделал
Нет, git вряд ли загнётся, он железный. А вот разработчики/интеграторы бы загнулись с мульёнами веток и мерджей.

> по-настоящему правильную систему и остальные нервно курят. В
> пристнопамятной презентации он как только не ругал SVN и CVS,
> приговариявая, что уж у него-то SVN done right.
Как мне кажется, он оказался прав. Хотя идеология там тоже сильно другая. В лучших традициях линукса, user friendly in unix way: система дружественная, но дружбу ещё нужно заслужить.

Здравствуйте, Aquary, Вы писали:

A>К слову, в большинстве системах контроля версий — метки и ветки принципиально разные сущности. Метки — вешаются на версию, а ветки — отращиваются от версий. В CVS, Perforce, Clearcase — как и в других — в tag нельзя ничего закоммитить даже теоретически.

A>Это к вопросу о правилах и их соблюдении. Лучше сделать так, чтобы пользователь не смог сделать ошибки, чем теоретически давать такую возможность и постоянно следить, чтобы никто не делал лишнего (путем создания договоренностей или спец.хуков). Но это так... к слову, ибо наболело

Я в курсе и тоже не понимаю, нафига в SVN объединили эти две сущности.

On 28/01/2010 10:28, Donz wrote:

> Я в курсе и тоже не понимаю, нафига в SVN объединили эти две сущности.
На самом деле дизайн svn это позволил, не плодить лишние сущности. Скажем, в cvs это было бы невозможно. Тег в классическом понимании в svn можно сделать с помощью externals или обычного текстового файлика, т.к. это по сути url в репозитории + номер ревизии (в cvs для этой функциональности требуется новая отдельная фича — тег, иначе никак). Но для удобства использования и простоты просто рекомендуют создать директорию tags и не париться.

Здравствуйте, Donz, Вы писали:
D>Я в курсе и тоже не понимаю, нафига в SVN объединили эти две сущности.
Все суть папки — порой удобная штука. Например, позволяет без дополнительных плясок (1)чекаутить только то, что нужно и (2)иметь в ФС сразу дерево рабочих копий (с разных веток) без необходимости свитча.