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

L> Для отслеживания бейзлайна продукта есть просто log. Каждый коммит атомарен, имеет свой номер и неизменен. Т.е. меткой является просто номер коммита — ВСЁ!

Отслеживание бэйзлайна — эт как? Бэйзлайн — это множество элементов с выбранными версиями, которые считаются стабильными. Бэйзлайны идентифицируются созданием метки — т.е. помечиванием этих самых элементов и выбраным версий каким-либо способом. Возможно, ты имел в виду идентификацию?
В SVN же идентификация бэйзлайна заключается в том, что в отдельное место — папку с определеннвм названием — копируются дирки и файлы выбранной ревизии.

А насчет того, чтобы ревизию называть меткой — ты погорячился Принято метку делать уникальным символьным обозначением бэйзлайна. Номер для этой цели мало подходит Сравни rev240, rev241 и COMPONENT_FOO_2.1, SUBSYSTEM_BAR_0.1. Буквы как-то проще воспринимаются

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

Pzz>>Вам надо как-нибудь посмотреть, как работают changeset'ы там, где они есть. Например в Perforce. Тогда Вы поймете, о чем я говорю
C>В SVN changeset'ом является каждый коммит. В принципе, этого вполне достаточно.

diff, patch, e-mail и немного шелловских скриптов тоже в принципе вполне достаточно
Source control добавляет к этому определенные удобства.

C>Ну а скоро еще и умный merging подоспеет — так вообще жизнь станет еще лучше.

Это который при следующем merge учитывает changes, уже замерженные раньше? Давно пора, кстати.

Aquary wrote:

> А насчет того, чтобы ревизию называть меткой — ты погорячился Принято
> метку делать уникальным символьным обозначением бэйзлайна. Номер для
> этой цели мало подходит Сравни rev240, rev241 и COMPONENT_FOO_2.1,
> SUBSYSTEM_BAR_0.1. Буквы как-то проще воспринимаются
А чем не нравится

> В SVN же идентификация бэйзлайна заключается в том, что в отдельное
> место — папку с определеннвм названием — копируются дирки и файлы
> выбранной ревизии.

?
Ведь если ты не знал, то копировать можно в самом репозитории, не делая
реальные копии где-либо. А потом, при необходимости, делать switch, при
этом апдейтиться будут только различающиеся файлы.

Pzz wrote:

> Это одно из мест, где true renames отличаются от copy + del.
> Переименование это операция над директорией, а не над файлом. Т.е., если
> файл меняет имя, то в истории файла меточка остается, но в истории
> директории новое имя оказывается выше меточки.
>
> Это позвляет, в частности, посмотреть diff между 2-мя метками на файле,
> даже если файл переименовывался в процесее, без необходимости угадывать
> его старое имя — фича, совершенно отсутствующая в SVN'е.
Присутствует, по крайней мере в tsvn. Просто надо галочку убрать "Stop
on copy/rename", которая по умолчанию поставлена.

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

.>Коммитишь 20 файлов. 18 закоммитилось, а 2 последних — не up-to-date —
.>облом. Пока апдейтишь, резолвишь кофликты — у других юзеров может всё
.>поломаться. svn же откатит всё.

Это я понимаю. Однако это маловероятная катастрофа. Т.е., если мне пытаются это продавать, как основное преимущество SVN перед CVS и мне захочется пофлеймить, я на это отвечу в том духе, что зато у CVS'а весь репозиторий — текстовые файлы. Если у SVN'а разнесет репозиторий, его уже хрен починишь, а с CVS'ом шансов намного больше.

Если серьезно, я предлагаю сравнивать разные системы контроля версий с точки зрения той концептуальной модели, в которой построен пользовательский интерфейс, а не с точки зрения деталей имплементации. Так вот, на мой взгляд атомарность коммитов это именно детали имплементации. Концептуальное отличие — это когда многофайловый коммит виден пользователю как нечто единое целое (не в случае аварии, а в нормальной жизни). В SVN'е это есть, но сделано достаточно по-детски.

Обидно причем, что эта недоделанность SVN'овских коммитов, это сознательная позиция авторов, а не просто недоделка.

>> L>Опять не понимаю. В SVN коммит — это самостоятельный обьект, который
>> можно посмотреть в виде списка потроганных файлов или diff-a

Хорошо, спрошу по другому. Если коммит в SVN'е это самостоятельный объект, каким интерфейсом обладает этот объект?

.>Ошибаешься. Скажем, tsvn показывает список всех файлов, притом если ты
.>"не в корне", то не попавшие файлы просто серым показываютя (или не
.>показываются вообще, если галочка не стоит).

tsvn это надстройка, которая добавляет к SVN'у от себя. Я говорю о SVN'е, а не об настройках над ним. В частности потому, tsvn живет в виндовой гуйне, а я — в линуксячей командной строке.

>> Я уже не говорю о том, что в P4 commit как объект создается еще до того,
.>Как в p4 он идентифицируется?

Номером. Тот, который существует только на клиентской машинке, по-моему называется default. Могу ошибиться — давно уж не работал с P4.

.>log message можно редактировать (если прав достаточно). А вот
.>разбивать?.. Зачем?

Очень часто решая какую-то конкретную проблему, делаешь на самом деле 2 вещи:
1) Создаешь инфраструктуру для решения этой и подобных проблем
2) Решаешь ту проблему, ради которой это все и затевалось

На мой взгляд, значительно удобнее, когда это проходит несколькими change'ми по source control'у — при условии, что каждый change сам по себе логически самодостаточен. Можно, конечно, сначала создать инфраструктуру, засубмиттить, решить проблему, засубмиттить. Но удобнее создать инфраструктуру, решить проблему, параллельно обкатав новую инфраструктуру в плане ее usability, а потом засубмиттить и то и другое отдельными commit'ами.

.>История не собственная, она тоже копируется, точнее первой точкой истоии
.>становится "скопированно из <url> ревизия <nnn>". Начало историй будет
.>одним и тем же. А продолжение — естественно разное. Переименование — то
.>же копирование, но с удалением оригинала.

Переименование это назначение нового имени старому объекту. Копирование это создание нового объекта. Это 2 разные операции.

>> Просто сравни процедуры работы с vendor branch'ами в CVS и SVN, и все
>> станет сразу понятно...
.>Да тоже самое, только в svn попроще этим пользоваться и поэффективнее
.>работает.

Поэффективнее работает копирование дерева. Merge работает так же, и делает примерно то же. Насчет поудобнее, мне лично удобнее писать метку вида LINUX_2_4_20, чем http://mysvn.mycompany.com/mydepartment/myproject/vendor/linux.2.4.20

Причем "пути" в SVN'е становятся особенно эротичными, когда компания большая и проектов много.

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

Pzz>Это я понимаю. Однако это маловероятная катастрофа. Т.е., если мне пытаются это продавать, как основное преимущество SVN перед CVS и мне захочется пофлеймить, я на это отвечу в том духе, что зато у CVS'а весь репозиторий — текстовые файлы. Если у SVN'а разнесет репозиторий, его уже хрен починишь, а с CVS'ом шансов намного больше.
Разнести fsfs-репозиторий в SVN очень сложно — так как файлы с ревизиями иммутабельны (посмотри как-нибудь как файлы репозитория в SVN выглядят).

Pzz>Обидно причем, что эта недоделанность SVN'овских коммитов, это сознательная позиция авторов, а не просто недоделка.
Я видел changeset'ы в Perforce. Приятно, но особого смысла в них я не вижу.

Pzz>Хорошо, спрошу по другому. Если коммит в SVN'е это самостоятельный объект, каким интерфейсом обладает этот объект?
Можно взять список изменений, сделать обратный merge этих изменений, посмотреть метаданные и т.п.

Собственно, для этого в SVN есть официальный API с байндингами к туче языков.

Pzz>tsvn это надстройка, которая добавляет к SVN'у от себя. Я говорю о SVN'е, а не об настройках над ним. В частности потому, tsvn живет в виндовой гуйне, а я — в линуксячей командной строке.
TSvn ничего практически не добавляет — это просто клиент для SVN. Все что можно сделать в TSvn (кроме разве что графа ревизий) можно сделать и в командной строке, просто это будет не так удобно.

Pzz>На мой взгляд, значительно удобнее, когда это проходит несколькими change'ми по source control'у — при условии, что каждый change сам по себе логически самодостаточен. Можно, конечно, сначала создать инфраструктуру, засубмиттить, решить проблему, засубмиттить. Но удобнее создать инфраструктуру, решить проблему, параллельно обкатав новую инфраструктуру в плане ее usability, а потом засубмиттить и то и другое отдельными commit'ами.
Это будет в SVN 1.5: поддержка клиентских changeset'ов: http://blogs.open.collab.net/svn/2007/05/the_subversion__1.html

Pzz>Поэффективнее работает копирование дерева. Merge работает так же, и делает примерно то же. Насчет поудобнее, мне лично удобнее писать метку вида LINUX_2_4_20, чем http://mysvn.mycompany.com/mydepartment/myproject/vendor/linux.2.4.20
Pzz>Причем "пути" в SVN'е становятся особенно эротичными, когда компания большая и проектов много.
Ага, а в CVS эротики добавляет невозможность отменить создания ветки. Поэтому годами живут названия типа PRENT_PREVIEW_BRANCH.

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

C>>В SVN changeset'ом является каждый коммит. В принципе, этого вполне достаточно.
Pzz>diff, patch, e-mail и немного шелловских скриптов тоже в принципе вполне достаточно
Ну да, добавить пару скриптов — и получится GIT.

Pzz>Source control добавляет к этому определенные удобства.
Именно.

C>>Ну а скоро еще и умный merging подоспеет — так вообще жизнь станет еще лучше.
Pzz>Это который при следующем merge учитывает changes, уже замерженные раньше? Давно пора, кстати.
Ага, с возможность делать cherry picking и т.п.

I>Наша фирма уже более года работает с CVS.
I>В принципе нас всё устраивает.
I>Я слышал что многие переходят с CVS на SVN.
I>Стоит ли переходить с CVS на SVN и почему?
Однозначно стоит. Причина — на порядок более технологичное решение. О плюсах — написано на самой странице проекта. Добавлю ещё, что в 1.5 версии, которая должна скоро зарелизиться будет добавлена мега полезная фича, merge tracking.

Pzz wrote:

> .>Коммитишь 20 файлов. 18 закоммитилось, а 2 последних — не up-to-date —
> .>облом. Пока апдейтишь, резолвишь кофликты — у других юзеров может всё
> .>поломаться. svn же откатит всё.
> Это я понимаю. Однако это маловероятная катастрофа. Т.е., если мне
> пытаются это продавать, как основное преимущество SVN перед CVS и мне
> захочется пофлеймить, я на это отвечу в том духе, что зато у CVS'а весь
> репозиторий — текстовые файлы. Если у SVN'а разнесет репозиторий, его
> уже хрен починишь, а с CVS'ом шансов намного больше.
Кибер объяснил, убить SVN репозиторий гораздо сложнее. Да и вообще
говоря, надееться на текстовость формата при сбоях — наивно.

> Если серьезно, я предлагаю сравнивать разные системы контроля версий с
> точки зрения той концептуальной модели, в которой построен
> пользовательский интерфейс, а не с точки зрения деталей имплементации.
У svn нет как такового пользовательского интерфейса, есть фактически
только API, и дефолтный command-line клиент. А пользовательских
интерфейсов у него не менее десятка.

> Так вот, на мой взгляд атомарность коммитов это именно детали
> имплементации. Концептуальное отличие — это когда многофайловый коммит
> *виден пользователю* как нечто единое целое (не в случае аварии, а в
> нормальной жизни). В SVN'е это есть, но сделано достаточно по-детски.
Мне виден. Погляди внимательнее, может и ты увидишь.

>> > L>Опять не понимаю. В SVN коммит — это самостоятельный обьект, который
>> > можно посмотреть в виде списка потроганных файлов или diff-a
> Хорошо, спрошу по другому. Если коммит в SVN'е это самостоятельный
> объект, каким интерфейсом обладает этот объект?
У него есть идентификатор, можно узнать log message, поменять его,
owner, timestamp, с ним можно мержиться, диффаться, его можно чекаутить,
свитчить и т.п.

> .>Ошибаешься. Скажем, tsvn показывает список всех файлов, притом если ты
> .>"не в корне", то не попавшие файлы просто серым показываютя (или не
> .>показываются вообще, если галочка не стоит).
> tsvn это надстройка, которая добавляет к SVN'у от себя. Я говорю о
> SVN'е, а не об настройках над ним. В частности потому, tsvn живет в
> виндовой гуйне, а я — в линуксячей командной строке.
Это не надстройка, а gui-интерфейс, фактически делающий одно —
формирующий с помощью мышки командную строку.

>> > Я уже не говорю о том, что в P4 commit как объект создается еще до того,
> .>Как в p4 он идентифицируется?
> Номером. Тот, который существует только на клиентской машинке, по-моему
> называется default. Могу ошибиться — давно уж не работал с P4.
В svn тоже номер. А он последовательный? Если так, то как разбиение
коммита работает?

> .>log message можно редактировать (если прав достаточно). А вот
> .>разбивать?.. Зачем?
>
> Очень часто решая какую-то конкретную проблему, делаешь на самом деле 2
> вещи:
> 1) Создаешь инфраструктуру для решения этой и подобных проблем
> 2) Решаешь ту проблему, ради которой это все и затевалось
>
> На мой взгляд, значительно удобнее, когда это проходит несколькими
> change'ми по source control'у — при условии, что каждый change сам по
> себе логически самодостаточен. Можно, конечно, сначала создать
> инфраструктуру, засубмиттить, решить проблему, засубмиттить. Но удобнее
> создать инфраструктуру, решить проблему, параллельно обкатав новую
> инфраструктуру в плане ее usability, а потом засубмиттить и то и другое
> отдельными commit'ами.
Дык коммить несколько раз... кто запрещает? Просто если ты уже
закоммитил, то "раскоммитить" уже нельзя, чтобы перекоммитить
скомбинировав по-другому... Точнее можно, но это останется в истории.

> .>История не собственная, она тоже копируется, точнее первой точкой истоии
> .>становится "скопированно из <url> ревизия <nnn>". Начало историй будет
> .>одним и тем же. А продолжение — естественно разное. Переименование — то
> .>же копирование, но с удалением оригинала.
> Переименование это назначение нового имени старому объекту. Копирование
> это создание нового объекта. Это 2 разные операции.
Ты яву знаешь? Вот представь себе, что ревизия это имя переменной, все
переменные final, а объект — он "где-то там".

final Object rev123 = new Object();
final Object branch1 = rev123;

Так что в svn объекты новые не создаются при копировании, а просто
создаются ссылки на них.

>> > Просто сравни процедуры работы с vendor branch'ами в CVS и SVN, и все
>> > станет сразу понятно...
> .>Да тоже самое, только в svn попроще этим пользоваться и поэффективнее
> .>работает.
> Поэффективнее работает копирование дерева. Merge работает так же, и
> делает примерно то же. Насчет поудобнее, мне лично удобнее писать метку
> вида LINUX_2_4_20, чем
> http://mysvn.mycompany.com/mydepartment/myproject/vendor/linux.2.4.20
> Причем "пути" в SVN'е становятся особенно эротичными, когда компания
> большая и проектов много.
Мелочи. Элементарно решается адекватным ui.

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

.>Revision Graph в tsvn? Работает безумно долго...
Заметь — это не нативное решение, а надстройка... Ядро системы не позволяет этого делать простыми движениями

.>но, вообще говоря, за год использования мне никогда не потребовалось это,
А вот у меня такое — каждый день Проект крупный, отслеживание веток, меток, мержей — каждодневная рутина.

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

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

.>А чем не нравится
.>

...

.>?
.>Ведь если ты не знал, то копировать можно в самом репозитории, не делая
.>реальные копии где-либо. А потом, при необходимости, делать switch, при
.>этом апдейтиться будут только различающиеся файлы.

Не нравится тем, что я не хочу иметь отдельную папку с тем, что посчитали бэйзлайном. Пусть даже в репозитории, пусть даже это фактически это линк и место никак не отъедается. Во других системах контроля версий у тебя есть дерево файлов, к каждому из которых привязано дерево версий. Т.е существует как бы 2 измерения, в каждом из которых ты работаешь в зависимости от потребностей. При необходимости эти измерения "встречаются", однако элемент и их дерево версий — разделены принципиально. В SVN же всё сводится к новым папкам.
Я уже говорил, что это классное проектное решение — всё свести к папкам, всё становится более единообразно... однако есть случаи когда это мешает. Пример уже приводили — в "чистом" SVN, без надстроек и скриптов, по взятому файлу из транка нельзя сказать — в какие метки он вошел, откуда были сделаны мержи.
Вот пример. Сколько приседаний займет в SVN подобная картина (речь для простоты об одном файле из множества имеющися):
— выпущен бэйзлайн, он прошел тесты и считается стабильным,
— есть проблема Х, для решения от бэйзлайна отрастили девелоперский бранч, частично решили на своем бранче,
— одновременно фиксят баг Y, решение опирается на фикс проблемы X.
— фикс Х интегрируют в бэйзлайн, в котором к тому времени уже обновился другими фиксами
— фикс Y перемерживают на новый бэйзлайн, дорабатывают "косметику", интегрируют в следующиую версию бэйзлайна.

Ответьте, апологеты SVN — вы не за%%%тесь проследить подобную картину только по дереву версий? Без tsvn, а просто силами ядра системы? В CVS, не говоря уже о ClearCase и P4 достаточно взять один элемент и сделать описание файла или версии — там всё будет как на ладони, все отращивания/мержи. Для того, чтобы сравнить изменения, отслеждить пути изменений файла — не надо будет скакать между виртуальными директориями АКА ветками, все операции делаются с одним файлом, лежащим во всё то же дирке.
Уверен, вы найдете способы решить описанную задачу, однако сколько усилий вы потратите?

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

.>У svn нет как такового пользовательского интерфейса, есть фактически
.>только API, и дефолтный command-line клиент. А пользовательских
.>интерфейсов у него не менее десятка.

Очень убедительный аргумент. В таком случае, POSIX API — лучшая система контроля версий в мире. Ведь из нее можбо сделать любую другую

>> Номером. Тот, который существует только на клиентской машинке, по-моему
>> называется default. Могу ошибиться — давно уж не работал с P4.
.>В svn тоже номер. А он последовательный? Если так, то как разбиение
.>коммита работает?

Разбить можно еще непосубмиченный коммит.

>> Переименование это назначение нового имени старому объекту. Копирование
>> это создание нового объекта. Это 2 разные операции.
.>Ты яву знаешь? Вот представь себе, что ревизия это имя переменной, все
.>переменные final, а объект — он "где-то там".

Мы не обсуждаем сейчас, как SVN устроен внутри. Современный UNIX при fork()'е тоже ничего не копирует, однако семантика fork'а — создание копии процесса. Вот и семантика svn copy — создание копии объекта, а не действие с именем.

То, что внутри SVN'а copy обходится без копирования, это детали реализации.

>> делает примерно то же. Насчет поудобнее, мне лично удобнее писать метку
>> вида LINUX_2_4_20, чем
>> http://mysvn.mycompany.com/mydepartment/myproject/vendor/linux.2.4.20
>> Причем "пути" в SVN'е становятся особенно эротичными, когда компания
>> большая и проектов много.
.>Мелочи. Элементарно решается адекватным ui.

Мы не обсуждаем, что с помощью кирки, лопаты и какой-то матери из SVN'а можно таки сделать нормальный продукт. Как я уже заметил выше, нормальный продукт можно сделать из голого POSIX API. Мы сейчас обсуждаем SVN как продукт.

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

.>>в отличие, скажем, от переименования (которое нафиг порушит в cvs все связи от файла к меткам).
A>Вот это уже вопрос к зрелости проекта и вообще проектированию... что это за проект, где файлы часто переименовываются?

Очень странное замечание.
1. Только убожеством системы контроля версий можно оправдать исскуственное ограничение на (не)переименовывание файлов
2. Возможно это делается и не часто, но иногда бывает нужно в любом проекте.
3. А незрелым проектам так вообще получается не стоит жить в CVS, пока не дорастут

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

К>Очень странное замечание.
К>1. Только убожеством системы контроля версий можно оправдать исскуственное ограничение на (не)переименовывание файлов
Я и не говорил, что раз в CVS этого нет, то и не надо просто это так сильно превозносят поклонники SVN, как будто это самая главая фича любой системы контроля версий

К>2. Возможно это делается и не часто, но иногда бывает нужно в любом проекте.
Вот и отлично, что есть. Но и безпереименования жить можно неплохо

К>3. А незрелым проектам так вообще получается не стоит жить в CVS, пока не дорастут
Вот этого я не говорил перегибаешь...

Aquary wrote:

> Не нравится тем, что я не хочу иметь отдельную папку с тем, что
> посчитали бэйзлайном. Пусть даже в репозитории, пусть даже это
> фактически это линк и место никак не отъедается. Во других системах
> контроля версий у тебя есть дерево файлов, к каждому из которых
> привязано дерево версий. Т.е существует как бы 2 измерения, в каждом из
> которых ты работаешь в зависимости от потребностей. При необходимости
> эти измерения "встречаются", однако элемент и их дерево версий —
> разделены принципиально. В SVN же всё сводится к новым папкам.
> Я уже говорил, что это классное проектное решение — всё свести к папкам,
> всё становится более единообразно... однако есть случаи когда это
> мешает. Пример уже приводили — в "чистом" SVN, без надстроек и скриптов,
> по взятому файлу из транка нельзя сказать — в какие метки он вошел,
> откуда были сделаны мержи.
> Вот пример. Сколько приседаний займет в SVN подобная картина (речь для
> простоты об одном файле из множества имеющися):
Кстати, на самом деле практически точно также, как в cvs.

> — выпущен бэйзлайн, он прошел тесты и считается стабильным,
svn co https://svn.company.com/project/trunk
<test, build, release baseline>

> — есть проблема Х, для решения от бэйзлайна отрастили девелоперский
> бранч, частично решили на своем бранче,
svn cp https://svn.company.com/project/trunk
https://svn.company.com/project/dev/X

svn switch https://svn.company.com/project/dev/X

<fixing bug X>
svn ci

> — одновременно фиксят баг Y, решение опирается на фикс проблемы X.
<fixing bug Y>
svn ci


> — фикс Х интегрируют в бэйзлайн, в котором к тому времени уже обновился
> другими фиксами
svn switch https://svn.company.com/project/trunk
svn merge -r 123:133 https://svn.company.com/project/dev/X
<test if works>
svn ci


> — фикс Y перемерживают на новый бэйзлайн, дорабатывают "косметику",
> интегрируют в следующиую версию бэйзлайна.
svn merge -r 133:HEAD https://svn.company.com/project/dev/X
<test if works>
svn ci

Всё. Единственное плохо — приходится номера ревизий при merge самому
отыскивать (tsvn это позволяет делать удобнее). Есть питоновый скрипт,
svnmerge.py, который это полностью автоматизирует. А в версии 1.5 это
будет родным.

> Ответьте, апологеты SVN — вы не за%%%тесь проследить подобную картину
> только по дереву версий? Без tsvn, а просто силами ядра системы? В CVS,
> не говоря уже о ClearCase и P4 достаточно взять один элемент и сделать
> описание файла или версии — там всё будет как на ладони, все
> отращивания/мержи. Для того, чтобы сравнить изменения, отслеждить пути
В cvs мержи не показываются, о cc, p4 не знаю.

> изменений файла — не надо будет скакать между виртуальными директориями
> АКА ветками, все операции делаются с одним файлом, лежащим во всё то же
> дирке.
> Уверен, вы найдете способы решить описанную задачу, однако сколько
> усилий вы потратите?
В смысле показать картину того факта, что X было замержено в trunk? В
общем можно, как минимум по логам.
А, кстати, для чего может понадобиться такой рисунок?

Aquary wrote:

> .>Revision Graph в tsvn? Работает безумно долго...
> Заметь — это не нативное решение, а надстройка... Ядро системы не
> позволяет этого делать простыми движениями
Что значит не нативное?
Что скачивать приходится с разных сайтов?

> .>но, вообще говоря, за год использования мне никогда не потребовалось это,
> А вот у меня такое — каждый день Проект крупный, отслеживание веток,
> меток, мержей — каждодневная рутина.
В смысле ты каждый день рассматриваешь картинки мерджей? Что значит
отслеживание?

> .>в отличие, скажем, от переименования (которое нафиг порушит в cvs все
> связи от файла к меткам).
> Вот это уже вопрос к зрелости проекта и вообще проектированию... что это
> за проект, где файлы часто переименовываются?
А что? Имя файла — священное и неприкосновенное животное??
Хотя да вообще-то... вспоминаю... было дело в эпоху cvs — это было
страшно менять и помню долго жили опечатки в названиях подобные
Dictonary.xml, GaleryDialog.java или InitialCod.cpp.

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

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

>> А вот у меня такое — каждый день Проект крупный, отслеживание веток,
>> меток, мержей — каждодневная рутина.
.>В смысле ты каждый день рассматриваешь картинки мерджей? Что значит
.>отслеживание?
Картинки не расссматриваю Отслеживание заключается в следующем:
— разработка ведется для нескольких линеек продуктов с общим функционалом
— каждый день десятки девелоперов подают свои изменения на интеграцию
— одно изменение может идти в разные линейки
— интеграция делается для отдельной компоненты, но отстройка ведется в рамках большого продукта с кучей компонент, зависимостей между ними и т.п.
Нужно для каждого фикса
— определять базу для бранчей/версий сделанных изменений
— интегрировать изменения в нужные линейки (мержить изменения на релизные бранчи элементов на основе общей базы, в данном случае 3-хпозиционным мержем)
— некоторые изменения нужно перемерживать между линейками (автоматически, без помощи девелоперов, выбирая только нужную дельту)

"Картинки мержей" выглядят очень сложно в графике (каждый элемент изменятся десятки раз в рамках линейки продукта, линеек — с десяток), более эффективно делать всё с командной строки + некоторые скрипты. Т.е. требуется максимум возможности для просмотра истории внесения и миграции изменений — и это при минимуме затраченных усилий, т.к. просмотреть нужно много.
В SVN подобная ситуация будет совсем не проще, чем в CVS... Одинаковая обширная задница и плюсы SVN над CVS тут никак не помогают, через CVS подобное можно было бы сделать чуть проще. ИМХО . Хотя, до заюзанного в моем случае ClearCase всё равно далеко

Кстати, в другом посте проскочило, что CVS не показывает мержи... показывает, ещё как показывает...

.>А что? Имя файла — священное и неприкосновенное животное??
Нет, зачем же надо менять имя — значит надо... Повторюсь — обычная фича... Но отнюдь не супернаворот, который привозносят по всех обзорах

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

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

Ну зачем вот это, "супернаворот", "превозносят"? Вопрос был — "какие преимущества?" Вот возможность переименовать — это преимущество, большое, маленькое, не важно. Для кого-то одна фича "супернаворот", для кого-то другая.

Aquary wrote:

> .>Что скачивать приходится с разных сайтов?
> Нет что сама система изначально почему-то этого не предусматривает
Что значит сама система? Что именно не предусматривает?
Единственное что svn command line не позволяет — нарисовать картинку
revision graph, которая как ты правильно заметил — бесполезная, ибо
слишком сложная.

> Нужно для каждого фикса
> — определять базу для бранчей/версий сделанных изменений
copy-запись в истории.

> — интегрировать изменения в нужные линейки (мержить изменения на
> релизные бранчи элементов на основе общей базы, в данном случае
> 3-хпозиционным мержем)
svn merge (или tsvn если мышой нравится щёлкать).

> — некоторые изменения нужно перемерживать между линейками
> (автоматически, без помощи девелоперов, выбирая только нужную дельту)
svn merge (или tsvn если мышой нравится щёлкать). Пожалуйста,
автоматизируй, например с помощью svn-py. Правда при мерджах возможны
конфликты... совсем без девелоперов не получится, понятное дело.

> "Картинки мержей" выглядят очень сложно в графике (каждый элемент
> изменятся десятки раз в рамках линейки продукта, линеек — с десяток),
> более эффективно делать всё с командной строки + некоторые скрипты. Т.е.
> требуется максимум возможности для просмотра истории внесения и миграции
> изменений — и это при минимуме затраченных усилий, т.к. просмотреть
> нужно много.
Что именно нужно просмотреть? В svn, если использовать svnmerge.py, то
для типичного мерджа достаточно обычно набрать "svnmerge merge", "svn ci
-F svnmerge-commit-message.txt" и ничего смотреть не надо.

> В SVN подобная ситуация будет совсем не проще, чем в CVS... Одинаковая
> обширная задница и плюсы SVN над CVS тут никак не помогают, через CVS
> подобное можно было бы сделать чуть проще. ИМХО . Хотя, до заюзанного в
> моем случае ClearCase всё равно далеко
О cc ничего не знаю...

> Кстати, в другом посте проскочило, что CVS не показывает мержи...
> показывает, ещё как показывает...
Кхм... Не помню такого. А как показывает?

> .>А что? Имя файла — священное и неприкосновенное животное??
> Нет, зачем же надо менять имя — значит надо... Повторюсь — обычная
> фича... Но отнюдь не супернаворот, который привозносят по всех обзорах
Кто превозносит? Хотя, да, для cvs это было серьёзной проблемой, так что
стоит упоминания.

К>>Очень странное замечание.
К>>1. Только убожеством системы контроля версий можно оправдать исскуственное ограничение на (не)переименовывание файлов
A>Я и не говорил, что раз в CVS этого нет, то и не надо просто это так сильно превозносят поклонники SVN, как будто это самая главая фича любой системы контроля версий

Дело в том что с точки зрения простого девелопера, у которого работа с системой контроля версий занимает 20 минут в день, у SVN не так уж много преимуществ перед CVS. Интерфейс и идеология использования похожи, некоторые просто не заметят переезда. Так вот, преимущества такие:
— возможность переименовывать файлы без потери истории
— возможность (nix-овые девелоперы поймут) добавить/убрать файлу атрибут "Executable" в любой момент, а не только в момент добавления в VCS.
— что-то ещё?

Всё остальное — атомарность коммита, zero-cost бранчевание и т.п. — это в большинстве случаев не для обычного девелопера, это чаще для CM-а или человека который исполняет его обязанности. Потому-то по форумам и создаётся впечатление что возможность переименовывать файлы — это главное преимущество.

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