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

А>Мне советуют удалить бранч.
Зря

А>Что это даст?
Из плюсов — небольшую экономию места.
Из минусов — невозможность полноценно отслеживать историю изменений. Системы контроля версий нужны не только для оперативной работы — отращивания и слияния. Они дают возможность отслеживать историю всей работы — и она может понадобится даже спустя месяцы.
Например, ты отрастил ветку, сделал изменения, протестировал, заинтегрировал на транк. Всё работает вроде. Ветку через неделю удалил. Потом выяснилось, что во внесенной дельте была бага — и где теперь искать источник ошибки? Ветки больше нет.
А если на ветке были заинтегрированы изменения нескольких человек? Грохнешь — и все промежуточные результаты пропадут, будут только конечные — по факту, на транке.

В общем, удалять нельзя.

А>Просто не будет захламляться каталог branches?

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

В общем, растись на здоровье.

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

A>Грохнешь — и все промежуточные результаты пропадут, будут только конечные — по факту, на транке.
A>Разруха — она в голове, а не в папке с бранчами Не парься.

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

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

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

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

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

Z>>зачем? ... если бранч не нужен -- смело грохаем! (и как уже было верно замечено лучше делать reintegrate при последнем мерже)...
Z>>если вдруг (никогда мне лично это не надобилось) захочется ... всегда можно зачекаутить нужную ревизию репы в которой этот бранч еще был...

D>То есть бранч все-таки остается в системе и его (именно бранч, а не некую ревизию из транка, которая примерно соответствует бранчу) можно вытащить даже после удаления?

именна... ибо в svn версионируется ВЕСЬ репозиторий а не отдельные файлы\каталоги... т.е. циферка номера ревизии означает состояние всего репозитория...

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

D>Еще как минимум если бренч действительно не нужен, не надо постоянно помнить о том что он не нужен.
D>т.е если есть баг распространяющийся на все версии, то его не нужно там править. Короче меньше энтропии
D>на диске, в разработке и голове.

Никогда с таким не сталкивался.
Иногда бывает так, что конкретно сейчас некая штука кажется ненужной. А оказывается очень нужной по прошествии некоторого времени, только "поздно пить боржоми". И конкретно в разработке с этим сталкивался.
В общем, если этих бранчей не сотни, запариваться не стоит. Убрать из непрерывной интеграции — это да, а удалять из репозитория не стоит.
ИМХО, если действительно бранчей много, стоит какую-нибудь папку "archive" завести, куда перемещать неактуальные ветки.

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

D>>Иногда бывает так, что конкретно сейчас некая штука кажется ненужной. А оказывается очень нужной по прошествии некоторого времени, только "поздно пить боржоми".

А>Мы если перестаем пользоваться бранчем, то заводим для него tag.
А>А по тегу всегда можно сделать новый бранч.
А>Разве не так?
зачем? ... если бранч не нужен -- смело грохаем! (и как уже было верно замечено лучше делать reintegrate при последнем мерже)...
если вдруг (никогда мне лично это не надобилось) захочется ... всегда можно зачекаутить нужную ревизию репы в которой этот бранч еще был...

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 объединили эти две сущности.

Я смержил бранч в транк.
Больше в бранче разработка вестись не будет.
Мне советуют удалить бранч.
Что это даст?
Просто не будет захламляться каталог branches?
Или есть еще какие-то плюсы?

Еще как минимум если бренч действительно не нужен, не надо постоянно помнить о том что он не нужен.
т.е если есть баг распространяющийся на все версии, то его не нужно там править. Короче меньше энтропии
на диске, в разработке и голове.

Здравствуйте, Аноним, Вы писали:
А>Мне советуют удалить бранч.
А>Что это даст?
А>Просто не будет захламляться каталог branches?
Да. И никто нечаянно в этом бранче ничего не сделает (после reintegrate мерж трекинг перестает нормально работать).

D>Иногда бывает так, что конкретно сейчас некая штука кажется ненужной. А оказывается очень нужной по прошествии некоторого времени, только "поздно пить боржоми".

Мы если перестаем пользоваться бранчем, то заводим для него tag.
А по тегу всегда можно сделать новый бранч.
Разве не так?

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

А>Мы если перестаем пользоваться бранчем, то заводим для него tag.
А>А по тегу всегда можно сделать новый бранч.
А>Разве не так?
В SVN tag и branch — это одно и то же, так что в копировании туда-сюда смысла не видно.

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

Z>зачем? ... если бранч не нужен -- смело грохаем! (и как уже было верно замечено лучше делать reintegrate при последнем мерже)...
Z>если вдруг (никогда мне лично это не надобилось) захочется ... всегда можно зачекаутить нужную ревизию репы в которой этот бранч еще был...

То есть бранч все-таки остается в системе и его (именно бранч, а не некую ревизию из транка, которая примерно соответствует бранчу) можно вытащить даже после удаления?

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

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

А>>Мне советуют удалить бранч.
A>Зря
не зря! ну вот нафига он нужен???

А>>Что это даст?
A>Из плюсов — небольшую экономию места.
скорее всего нет чем да... ибо как мы знаем svn хранит то что было добавлено и change setы к этому... и если в бранче ничего не изменялось то проста в очередном changeset'е не окажется изменений относящихся к данному бранчу... но сам бранч (внимание!) даже удаленный никуда не пропадает!

A>Из минусов — невозможность полноценно отслеживать историю изменений. Системы контроля версий нужны не только для оперативной работы — отращивания и слияния. Они дают возможность отслеживать историю всей работы — и она может понадобится даже спустя месяцы.
не правда! все можно достать и посмотреть спустя месяцы и годы... если аккуратно документировать каммиты можно даже вспомнить чонить спустя эти годы...

A>Например, ты отрастил ветку, сделал изменения, протестировал, заинтегрировал на транк. Всё работает вроде. Ветку через неделю удалил. Потом выяснилось, что во внесенной дельте была бага — и где теперь искать источник ошибки? Ветки больше нет.

не правда! в текущей ревизии ветка удалена, но в истории все осталось и никуда не делось!

а вообще: то что было сделано в бранче было вить кудато влито! -- вот там и смотреть... для фикса ошибки заводится бага в трекере, форкается бранч (желательно чтоб в имени был номер баги), фиксим, тестим, мержим, бранч убиваем...


A>А если на ветке были заинтегрированы изменения нескольких человек? Грохнешь — и все промежуточные результаты пропадут, будут только конечные — по факту, на транке.
йолки да ничо никуда не пропадет...

A>В общем, удалять нельзя.
МОЖНО! тупо чтобы не захламлять репу и не забивать себе моск запоминая не нужную инфу и не напрягать глаза просматривая тонны бранчей...

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

Z>а вообще: то что было сделано в бранче было вить кудато влито! -- вот там и смотреть... для фикса ошибки заводится бага в трекере, форкается бранч (желательно чтоб в имени был номер баги), фиксим, тестим, мержим,

Абсолютно верный ход мыслей.

Z> бранч убиваем...

Ты ведь не убиваешь результаты прогнанных тестов? Не грохаешь отчеты, не убиваешь другие артефакты, коих на большом проекте — тонны? Так чем тебе бранчи помешали?

A>>В общем, удалять нельзя.
Z>МОЖНО! тупо чтобы не захламлять репу и не забивать себе моск запоминая не нужную инфу и не напрягать глаза просматривая тонны бранчей...

Ну то есть удалить только чтобы глаза не мозолил? В чем отличие от мозоли глаз от других результатов работы? Надо быть последовательным...

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

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

Z>>а вообще: то что было сделано в бранче было вить кудато влито! -- вот там и смотреть... для фикса ошибки заводится бага в трекере, форкается бранч (желательно чтоб в имени был номер баги), фиксим, тестим, мержим,

A>Абсолютно верный ход мыслей.

Z>> бранч убиваем...

A>Ты ведь не убиваешь результаты прогнанных тестов? Не грохаешь отчеты, не убиваешь другие артефакты, коих на большом проекте — тонны? Так чем тебе бранчи помешали?

время от времени я убиваю все что не хранится в vcs...

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

когда я сделаю свою фичу, смержу ее, и тестеры начнут с ней играться взяв очередную сборку транка (например)... я убью и свой текущий бранч и рабочую копию со всм калом который там накопился

A>>>В общем, удалять нельзя.
Z>>МОЖНО! тупо чтобы не захламлять репу и не забивать себе моск запоминая не нужную инфу и не напрягать глаза просматривая тонны бранчей...

A>Ну то есть удалить только чтобы глаза не мозолил? В чем отличие от мозоли глаз от других результатов работы? Надо быть последовательным...
я и есть последовательный -- грохаю все не нужное...

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

Z>время от времени я убиваю все что не хранится в vcs...

А руки после этого — моешь?

Z>я и есть последовательный -- грохаю все не нужное...

Ну, я у тебя на проекте не командую — так что это дело сугубо твоё

вобщем чего я хотел донести: если это чтото нужное оно должно хранится под вершин контролом... все ненужное ессно грохаем! а зачем его хранить? для истории... вот историей пусть занимается vcs а не я... не нада захламлять винчи и моск в первую очередь (винчестеры кроме того оч быстро переполняются если хранить всякий хлам)

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

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

Z>>время от времени я убиваю все что не хранится в vcs...

A>А руки после этого — моешь?
руки мою не один раз в день а также всю технику с которой работаю и рабочее место протираю периодически... люблю чистоту

Здравствуйте, Aquary, Вы писали:
A>Ну то есть удалить только чтобы глаза не мозолил? В чем отличие от мозоли глаз от других результатов работы? Надо быть последовательным...
А какую пользу ты собираешься извлечь из висящего реинтегрированного бранча? Единственная, какую я вижу — сразу видно, какие бранчи были в принципе, за все время проекта — т.е. какбы дополнительные точки входа в историю. Но (1)лично мне ни разу такая возможность не была нужна (2)многое можно смотреть по ревижн-графу (3)есть вероятность, что если нужны подобные вещи — помогут тулзы, типа fisheye.

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

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

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

D>>То есть бранч все-таки остается в системе и его (именно бранч, а не некую ревизию из транка, которая примерно соответствует бранчу) можно вытащить даже после удаления?

Z>именна... ибо в svn версионируется ВЕСЬ репозиторий а не отдельные файлы\каталоги... т.е. циферка номера ревизии означает состояние всего репозитория...

Тогда да, если бранч точно не будет использоваться, то лучше грохать.

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

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 10:28, Donz wrote:

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

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