Alex Alexandrov wrote:
>
> Здравствуйте, kittown, Вы писали:
>
> K>Где как. Где-то get. Разных систем контроля версий того или
> K>иного барахла немало. cvs — одна из самых слабых, про vs
> K>вообще молчу. Кто-то, как у наших буржуйских партнеров,
> K>свою написал, не найдя ничего подходящего готового.
>
> ))) И что, написал нечто лучшее CVS или Subversion?

Написал. Собственно с cvs даже сравнивать неинтересно.
Текущее базовое руководство датировано 97 годом, а похожее
на текущее состояние было уже где-то в сентябре 94, но
постоянно добавляется что-то еще сверху.

По информации от 99 года, в системе тогда хранилось уже
более 300 миллионов строк кода. Изначально дизайнилась
для мейнфреймов IBM.

> K>Что блокирующей ? Когда блокирующей ?
>
> Здесь и далее под блокирующей системой понимается невозможность
> получения рабочей копии файла для изменений одновременно несколькими
> пользователями.

Еще раз — что блокирующей ? Извлечение ?

> Если изменения в одном файле ортогональны, то никакого перетестирования
> не потребуется.

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

Отказ от этого правила дает больше проблем, чем его
выполнение. Чистая практика — никакой теории.

> Точнее, понадобится просто прогнать еще раз свои тесты (они должны
> быть автоматизированы и быстры), но проблем это не вызовет.

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

На малых системах или игрушечных задачах можно разрабоатывать
как угодно, на чем угодно, и по какому угодно принципу, все
в конце концов как-нибудь заработает и будет продано. В более
индустриальных разработках интереснее — ставки повыше, грабли
побольше, а углы срезать почти негде.

>> > Если 2 человека работают одновременно над одним файлом, то это либо
>> > багфиксы, либо неправильная организация модулей.
>
> K>Необязательно.
>
> ОК, перефразирую. Если 2 человека работают одновременно над одним местом
> в одном файле и это вызывает проблемы при коммите, то это неправильная
> организация труда.

Самая обычная несостыковка по времени. Не авария, и даже не проблема.
Есть масса случаев, когда надо менять примерно одно место в файле,
особенно когда в нем находится код для сопряжения нескольких подсистем.

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

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

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

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

> А вообще нет желания затевать флэйм по этому поводу, ибо как на РСДН это
> уже было <http://rsdn.ru/forum/Message.aspx?mid=225776&gt;

Автор: Yampolski_Nikita
Дата: 27.03.03

. Мне нравятся
> CVS и Subversion, мой опыт с SourceSafe мне не понравился.

От более-менее уважаемых людей я чаще всего слышу про Clearcase и
Perforce, оба пока не смотрел. В мелких проектах — CVS, в
средних — в зависимости от размера фирмы. Та, что у нас (PLS),
закрыта, в гугле ее можно найти только в резюме "бывших". Про
остальные системы слышал мало, и в основном на сайтах разработчиков.

Mikhail

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

LM>SS употреблял в обобщенном смысле. Просто как жить более чем одному разработчику без аналогичного инструмента?!

Жили, а многие до сих пор живут. Некоторые даже сопротивляются Помню как один очень даже квалифицированный руководитель говорил примерно следующее: "кааак, у вас люди правят чужие исходники?? да вы что! у нас каждый человек отвественен за свою часть работы, каждый разрабатывает какие-то модули системы, и у каждого модуля своя папочка на сервере, куда человек кладет свои изменения. ну и зачем нужен SS??"

Вот так вот.

"Alex Alexandrov" <20458@users.rsdn.ru> wrote in message news:1067627@news.rsdn.ru...
> Как человек, поработавший с различными системами
> контроля версий, могу сообщить, что знание
> только SourceSafe — примерно тоже самое,
> что знание только Бейсика.

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

> Сейчас работаем с CVS — красота, хотя некоторые
> нюансы тоже есть. Но работу с SS я вспоминаю,
> расстраиваясь и вздрагивая.

Детские какие-то у вас вздрагивания. И расстраивания. По удобству работы VSS (особенно при разработке ПО для Windows) не в пример лучше CVS-а. Все очень визуально, хорошо встраивается в студию, работает без "отличительных особенностей" (вспомним, например, cvs из поставки cygwin, который при commit'е херил файл).

> Это ж надо — файл зачекинить нельзя, если
> другой его зачекаутил! И ведь нормальным и логичным казалось...

Как это "нельзя"? Вполне себе можно! Чекиньте, чекаутите файлы. VSS ничему не мешает. Наоборот, потом, если потребуется, он сам merge'ить будет про чекине другим разработчиком. Или вы как-то на чекаут неправильно берете (exclusive, что ли?). Более того, демонстрация статуса checked out является четким показателем, что над этим файлом уже работает кто-то другой!!! Не то, что в cvs — черт знает, кто и что сейчас в этот файл понапишет.
У VSS-а есть два недостатка. Первый (серьезный — это то, что он сделан Microsoft.
Второй — то, что у него нет нормального интерфейса для работы через интернет.

> Так что знать лучше не названия, а подходы.
> Параллельная разработка, слияние веток, методы
> блокировки и разрешения конфликтов, атомарность коммитов и т.д.

Тут, конечно, согласен. Подходы знать нужно.
Но также имеет смысл пользоваться той системой, которая меньше других снижает производительность. В случае с VSS операции в пределах команды разработки внутри одного офиса осуществляются быстрее.
CVS — система для другого. Не для офиса.

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

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

Я разве сказал, что VSS нежизнеспособен? Я сказал, что не надо зацикливаться на нем.

SD>Детские какие-то у вас вздрагивания. И расстраивания. По удобству работы VSS (особенно при разработке ПО для Windows) не в пример лучше CVS-а. Все очень визуально, хорошо встраивается в студию, работает без "отличительных особенностей" (вспомним, например, cvs из поставки cygwin, который при commit'е херил файл).

Ну с этим я просто не согласен. Ничего у меня никогда не херилось в CVS, а вот VSS базы падали, было. По поводу удобства работы — для CVS достаточно GUI решений, но мне ближе как раз командная строка. Например, ты правишь файл и видишь сомнительное место. Можешь показать способ как в SS ты узнаешь, кто последний изменял эту строку?

SD>Как это "нельзя"? Вполне себе можно! Чекиньте, чекаутите файлы. VSS ничему не мешает. Наоборот, потом, если потребуется, он сам merge'ить будет про чекине другим разработчиком. Или вы как-то на чекаут неправильно берете (exclusive, что ли?). Более того, демонстрация статуса checked out является четким показателем, что над этим файлом уже работает кто-то другой!!! Не то, что в cvs — черт знает, кто и что сейчас в этот файл понапишет.

Да, я уже понял, что в принципе у VSS есть возможность multiple checkout. ОК. Насчет "черт знает кто в CVS понапишет" — посмотрите cvs edit, cvs watch.

SD>У VSS-а есть два недостатка. Первый (серьезный — это то, что он сделан Microsoft.
SD>Второй — то, что у него нет нормального интерфейса для работы через интернет.

А третий недостаток — что его не используют в msft, так что он мертв как продукт. CVS тоже, конечно, не жилец, но у него хотя бы замена есть (SVN).

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

K>Написал. Собственно с cvs даже сравнивать неинтересно.
K>Текущее базовое руководство датировано 97 годом, а похожее
K>на текущее состояние было уже где-то в сентябре 94, но
K>постоянно добавляется что-то еще сверху.

K>По информации от 99 года, в системе тогда хранилось уже
K>более 300 миллионов строк кода. Изначально дизайнилась
K>для мейнфреймов IBM.

Можно узнать конкретные преимущества по сравнению с CVS и, самое главное, SVN?

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

K>Отказ от этого правила дает больше проблем, чем его
K>выполнение. Чистая практика — никакой теории.

Спору нет, но если следовать твоей логике жестко, то тогда надо либо перетестировать все после любого чекина в проект. Ведь файлы тоже далеко не ортогональны в функциональном плане. И не важно, разрешены multiple checkouts или нет. Так что здравым смыслом все-таки надо руководствоваться тоже. Либо блокировать весь проект для изменения любого файла...

K>Бывает, для получения нужной аппаратуры и создания нужной
K>конфигурации требуется от нескольких дней до недели. При
K>этом компайл системы может слопать часа полтора. Примерно
K>столько же будет бегать стандартный набор тестов.

K>На малых системах или игрушечных задачах можно разрабоатывать
K>как угодно, на чем угодно, и по какому угодно принципу, все
K>в конце концов как-нибудь заработает и будет продано. В более
K>индустриальных разработках интереснее — ставки повыше, грабли
K>побольше, а углы срезать почти негде.

Мы работаем с CVS, билд у нас строится ночью гораздо больше чем полтора часа. Причин лочить файлы я ни разу не видел.

Дальнейшие ваши реплики оставлю без комментариев. Если вкратце, то я рад за вас, если вам кажется, что SourceSafe — верх совершенства. Я останусь при своем мнении, что бесплатные CVS и SVN не уступают многим дорогим коммерческим продуктам. Ваше мнение лишь доказательство того, что маркетологи не зря получают зарплату.

"Alex Alexandrov" <20458@users.rsdn.ru> wrote in message news:1069161@news.rsdn.ru...
> Я сказал, что не надо зацикливаться на нем.

Цитата из вашего сообщения:

> знание только SourceSafe — примерно тоже самое, что знание только Бейсика.

Именно против этого я возражаю. А вовсе не требую зациклиться на VSS'е. По мне так, одна фигня, с чем работать, но с VSS'ом можно это делать оперативнее. В случае, когда не требуется расширенная функциональность, VSS отлично подходит.

> Ничего у меня никогда не херилось в CVS, а вот VSS базы падали, было.

А у нас VSS базы всегда были в порядке. Тогда как в CVS файлы херились. Где ж правда, а?

> По поводу удобства работы — для CVS достаточно GUI решений,

Вы сами-то пробовали с ними работать? Попробуйте, командная строка станет еще ближе.

> Например, ты правишь файл и видишь сомнительное место.
> Можешь показать способ как в SS ты узнаешь, кто последний
> изменял эту строку?

Угу. Diff, затем смотрим, кто чекинил. Кстати, а зачем это нужно, кроме как для "надавать по башке нерадивому программеру" (что изначально есть гадкое дело).


> Насчет "черт знает кто в CVS понапишет" — посмотрите cvs edit, cvs watch.

Я просто по опыту скажу: merge'ить VSS'ом приходилось крайне редко, обычно я видел, что файл кем-то занят и принимался за другие таски. А с cvs-ом периодически приходилось воевать.

Нет, поверьте, я не голосую за VSS. Просто говорю, что one size does not fit all! И если VSS где-то требуют, значит, он там отлично подходит..

Alex Alexandrov wrote:
>
> Здравствуйте, kittown, Вы писали:
>
> K>Написал. Собственно с cvs даже сравнивать неинтересно.
> K>Текущее базовое руководство датировано 97 годом, а похожее
> K>на текущее состояние было уже где-то в сентябре 94, но
> K>постоянно добавляется что-то еще сверху.
>
> K>По информации от 99 года, в системе тогда хранилось уже
> K>более 300 миллионов строк кода. Изначально дизайнилась
> K>для мейнфреймов IBM.
>
> Можно узнать конкретные преимущества по сравнению с CVS и, самое
> главное, SVN?

Сильный SCM. From http://svnbook.red-bean.com/en/1.0/ch01.html

Some version control systems are also software configuration management
(SCM) systems. These systems are specifically tailored to manage trees
of source code, and have many features that are specific to software
development—such as natively understanding programming languages, or
supplying tools for building software. Subversion, however, is not one
of these systems. It is a general system that can be used to manage any
collection of files. For you, those files might be source code—for
others, anything from grocery shopping lists to digital video mixdowns
and beyond.

> K>Способом доказательства ортогональности изменений является то же
> K>самое перетестирование. Если ты анализом кода решил, что
> K>перетестирования не надо, но компайл не провел и код даже
> K>не запустил, то ты его сабмитить не должен.
>
> K>Отказ от этого правила дает больше проблем, чем его
> K>выполнение. Чистая практика — никакой теории.
>
> Спору нет, но если следовать твоей логике жестко, то тогда надо либо
> перетестировать все после любого чекина в проект. Ведь файлы тоже далеко
> не ортогональны в функциональном плане. И не важно, разрешены multiple
> checkouts или нет. Так что здравым смыслом все-таки надо
> руководствоваться тоже. Либо блокировать весь проект для изменения
> любого файла...

Больное место. Но даже в самом запущенном случае хотя бы smoke
test (скомпилировал-запустил) нужен. Он свалиться может от
чего угодно — хоть от кривых концов строк.

> Дальнейшие ваши реплики оставлю без комментариев. Если вкратце, то я рад
> за вас, если вам кажется, что SourceSafe — верх совершенства. Я останусь

Я где-то говорил про SourceSafe что-то хорошее ? Нет, я обсуждал
вполне конкретную функциональность. Сама по себе SS — та еще дрянь.

> при своем мнении, что бесплатные CVS и SVN не уступают многим дорогим
> коммерческим продуктам. Ваше мнение лишь доказательство того, что
> маркетологи не зря получают зарплату.

Все важное вы проглядели мимо. Во-1, все взято из практики, а не
из книг или рекламных листовок. Во-2, есть старая банальная истина,
что система подбирается под процесс, который строится под задачи.
Т.е. во многих местах будут достаточны не то что cvs/svn, а даже
убитый SourceSafe. В третьих, в SVN нет SCM, а это является
одним из наиболее полезных компонент в толстой разработке.

Mikhail

SkyDance wrote:

>> По поводу удобства работы — для CVS достаточно GUI решений,
>
> Вы сами-то пробовали с ними работать? Попробуйте, командная строка
> станет еще ближе.

Together, Eclipse при работе с cvs неудобны ?

>> Например, ты правишь файл и видишь сомнительное место.
>> Можешь показать способ как в SS ты узнаешь, кто последний
>> изменял эту строку?
>
> Угу. Diff, затем смотрим, кто чекинил. Кстати, а зачем это нужно, кроме
> как для "надавать по башке нерадивому программеру" (что изначально есть
> гадкое дело).

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

Mikhail

"kittown" <32673@users.rsdn.ru> wrote in message
news:1069376@news.rsdn.ru...
> Together, Eclipse при работе с cvs неудобны ?

Да.

> Выяснить детали, зачем были нужны конкретные изменения,
> когда это не до конца ясно

Комментарии нынче не в моде? Или религия запрещает? Или культура
разработки...?

.

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

SD>"kittown" <32673@users.rsdn.ru> wrote in message
SD>news:1069376@news.rsdn.ru...
>> Together, Eclipse при работе с cvs неудобны ?

SD>Да.

А WinCVS, TortoiseCVS?

>> Выяснить детали, зачем были нужны конкретные изменения,
>> когда это не до конца ясно

SD>Комментарии нынче не в моде? Или религия запрещает? Или культура
SD>разработки...?

Разумеется, можно и контроль версий каталогами на шаре организовать. Мы же о функциональности конкретного средства говорим, а не о возможности обходного пути.

SkyDance wrote:
>
>> Together, Eclipse при работе с cvs неудобны ?
>
> Да.

Гм. Надо будет самому еще раз посмотреть — я от
cvs вообще уже отвык.

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

Комментарии есть, но иногда не хватает. Например, когда
автор посчитал что-то слишком очевидным. Для него.

Mikhail

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

>> знание только SourceSafe — примерно тоже самое, что знание только Бейсика.

SD>Именно против этого я возражаю. А вовсе не требую зациклиться на VSS'е. По мне так, одна фигня, с чем работать, но с VSS'ом можно это делать оперативнее. В случае, когда не требуется расширенная функциональность, VSS отлично подходит.

Еще раз, я не вижу ни одного преимущества SS перед CVS/SVN. Если можно, побольше конкретики.

SD>Угу. Diff, затем смотрим, кто чекинил. Кстати, а зачем это нужно, кроме как для "надавать по башке нерадивому программеру" (что изначально есть гадкое дело).

Поясни, с чем дифф будешь делать. Со всеми предыдущими версиями?

SD>Нет, поверьте, я не голосую за VSS. Просто говорю, что one size does not fit all! И если VSS где-то требуют, значит, он там отлично подходит..

VSS требуют там, где он просто исторически сложился и другого ничего просто знать не хотят. Так держать.

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

AA>Еще раз, я не вижу ни одного преимущества SS перед CVS/SVN. Если можно, побольше конкретики.

— Когда динамично развивающийся проект включает большое количество подпроектов и директорий, то управлять им в CVS это жуткий геморрой. CVS работает только с файлами и модулями, отдельные директории внутри модуля для него ничего не значат. Переместить, скопировать, удалить, переименовать — простейший набор операций, но для директорий в CVS они выполняются странными и неудобными способами.
— В CVS нельзя зашарить файл между несколькими проектами.
— Глюки CVS до сих пор время от времени проявляются. Например как то не удалялся файл с названием "-.gif". Базы были нормальные, просто принципиально нельзя было удалить файл с таким названием.
— WinCVS имеет настолько интуитивно непонятный и неудобный интерфейс, что даже после нескольких лет использования сохраняется устойчивое отвращение. Jalindi Igloo (плагин к студии) чуть лучше, но он не реализует полный набор операций. Впрочем и для других сред плагины рулят с тем же недостатком.

AA>VSS требуют там, где он просто исторически сложился и другого ничего просто знать не хотят. Так держать.

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

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

G>- Когда динамично развивающийся проект включает большое количество подпроектов и директорий, то управлять им в CVS это жуткий геморрой. CVS работает только с файлами и модулями, отдельные директории внутри модуля для него ничего не значат. Переместить, скопировать, удалить, переименовать — простейший набор операций, но для директорий в CVS они выполняются странными и неудобными способами.
G>- В CVS нельзя зашарить файл между несколькими проектами.

Да, директории не являются метаданными в CVS. Впрочем, расшаривание файлов между проектами решается с помощью модулей.
Строго говоря, в Source Safe копирование директорий тоже странное — копируются на самом деле только файлы, входящие в каталог на момент копирования.

И опять же, в SVN все является метаданными, никаких проблем со всеми вышеописанными действиями и сурссэйфу до SVN как до луны пешком.

G>- Глюки CVS до сих пор время от времени проявляются. Например как то не удалялся файл с названием "-.gif". Базы были нормальные, просто принципиально нельзя было удалить файл с таким названием.

Нет ничего принципиально невозможного, когда у тебя есть исходники. Подебажился вечерком за чаем, сделал патч, засабмиттил, и свободное сообщество тебя не забудет...

G>- WinCVS имеет настолько интуитивно непонятный и неудобный интерфейс, что даже после нескольких лет использования сохраняется устойчивое отвращение. Jalindi Igloo (плагин к студии) чуть лучше, но он не реализует полный набор операций. Впрочем и для других сред плагины рулят с тем же недостатком.

Для CVS есть хороший SCC провайдер от компании PushOK. Правда, не бесплатный, но и не дорогой — баксов 25, кажется.
По поводу GUI — не согласен. Да, WinCVS не вполне легок в освоении, но что мешает тогда взять TortoiseCVS?

G>Не надо за всех отвечать Во многих случаях есть смысл сделать совершенно осознанный выбор в пользу VSS.

Это ваше право. Тем и хороша свобода.