Здравствуйте, kittown, Вы писали:
K>Хитрое это слово, checkout. Перед глазами живой пример, где K>checkout как раз означает "извлечь и залочить". Операция K>извлечения без лочки называется иначе.
Как? В CVS это называется как раз check out.
K>Но работать без лочки — вешалка. Понаделал изменений, протестил, K>собрался сабмитить, а там уже кто-то успел что-то всерьез поменять K>и надо заново все тестить. Поэтому народ специально лочит, а K>система не позволяет лок обойти.
А Вы с какой системой работаете сейчас? С блокирующей? И что, раньше работали с неблокирующей и было хуже?
Если 2 человека работают одновременно над одним файлом, то это либо багфиксы, либо неправильная организация модулей. Багфиксы перекрываются относительно редко. В любом случае, между неблокирующей моделью с возможностью редких конфликтов и блокирующей моделью с необходимостью курить бамбук, если кто-то взял файл для фикса на 3 строки, я выбираю первый.
[ Posted via RSDN@Home 1.1.4 beta 4 (303) listening to silent ]
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, valmond, Вы писали:
V>Вот интересно, часто в вакансиях требуют наличие опыта работы с SourceSafe. V>В чем тут дело? Под этим подразумевается, что человек работал в команде, которая следит за своим хозяйством? Тогда непонятны требования знать что-то конкретное (типа VSS).
По моему опыту — в требования пишется то, что используется в конкретном месте. Знать именно эот — совершенно не важно. Другое дело что вот как-то на собеседование приходил программист (несколько лет опыта), который на вопрос про системы контроля версий интимно спросил собеседующих: "А вот скажите, положа руку на сердце, вы знаете хоть одну контору, где какой-то котроль версий реально используют?"
Здравствуйте, valmond, Вы писали:
V>Вот интересно, часто в вакансиях требуют наличие опыта работы с SourceSafe. V>В чем тут дело? Под этим подразумевается, что человек работал в команде, которая следит за своим хозяйством? Тогда непонятны требования знать что-то конкретное (типа VSS).
Как человек, поработавший с различными системами контроля версий, могу сообщить, что знание только SourceSafe — примерно тоже самое, что знание только Бейсика. Сейчас работаем с CVS — красота, хотя некоторые нюансы тоже есть. Но работу с SS я вспоминаю, расстраиваясь и вздрагивая. Это ж надо — файл зачекинить нельзя, если другой его зачекаутил! И ведь нормальным и логичным казалось...
Так что знать лучше не названия, а подходы. Параллельная разработка, слияние веток, методы блокировки и разрешения конфликтов, атомарность коммитов и т.д.
[ Posted via RSDN@Home 1.1.4 beta 4 (303) listening to silent ]
It's kind of fun to do the impossible (Walt Disney)
Alex Alexandrov wrote: > > Как человек, поработавший с различными системами контроля версий, могу > сообщить, что знание только SourceSafe — примерно тоже самое, что знание > только Бейсика. Сейчас работаем с CVS — красота, хотя некоторые нюансы > тоже есть. Но работу с SS я вспоминаю, расстраиваясь и вздрагивая. Это ж > надо — файл зачекинить нельзя, если другой его зачекаутил! И ведь > нормальным и логичным казалось...
Хитрое это слово, checkout. Перед глазами живой пример, где
checkout как раз означает "извлечь и залочить". Операция
извлечения без лочки называется иначе.
Но работать без лочки — вешалка. Понаделал изменений, протестил,
собрался сабмитить, а там уже кто-то успел что-то всерьез поменять
и надо заново все тестить. Поэтому народ специально лочит, а
система не позволяет лок обойти.
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Как человек, поработавший с различными системами контроля версий, могу сообщить, что знание только SourceSafe — примерно тоже самое, что знание только Бейсика. Сейчас работаем с CVS — красота, хотя некоторые нюансы тоже есть. Но работу с SS я вспоминаю, расстраиваясь и вздрагивая. Это ж надо — файл зачекинить нельзя, если другой его зачекаутил! И ведь нормальным и логичным казалось...
Дело не в SourceSafe, а в знании матчасти. В SourceSafe же администратор может поставить галочку "multiple checkouts" (или что-то в этом роде) и файлы прекрасно checkout-ятся любым количеством человек.
Я работал и с CVS несколько лет и два года с SourceSafe. Могу сказать, что и там и там есть свои плюсы и минусы, но для разработки вполне можно использовать как первую систему, так и вторую.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Alex Alexandrov, Вы писали:
AA>>Самым большим аргументом против SS для меня является то, что его не используют внутри Microsoft, компании, которая больше других исповедует принцип eat your own dog's food.
J>А что они используют, если не секрет?
До некоторой степени докрученный Perforce. Правда, информация полуторагодовалой давности, так что могло уже и измениться что-то. Но уж на SS они точно вряд ли перешли...
[ Posted via RSDN@Home 1.1.4 beta 4 (303) listening to silent ]
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, 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).
It's kind of fun to do the impossible (Walt Disney)
"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 где-то требуют, значит, он там отлично подходит..
Здравствуйте, SkyDance, Вы писали:
>> знание только SourceSafe — примерно тоже самое, что знание только Бейсика.
SD>Именно против этого я возражаю. А вовсе не требую зациклиться на VSS'е. По мне так, одна фигня, с чем работать, но с VSS'ом можно это делать оперативнее. В случае, когда не требуется расширенная функциональность, VSS отлично подходит.
Еще раз, я не вижу ни одного преимущества SS перед CVS/SVN. Если можно, побольше конкретики.
SD>Угу. Diff, затем смотрим, кто чекинил. Кстати, а зачем это нужно, кроме как для "надавать по башке нерадивому программеру" (что изначально есть гадкое дело).
Поясни, с чем дифф будешь делать. Со всеми предыдущими версиями?
SD>Нет, поверьте, я не голосую за VSS. Просто говорю, что one size does not fit all! И если VSS где-то требуют, значит, он там отлично подходит..
VSS требуют там, где он просто исторически сложился и другого ничего просто знать не хотят. Так держать.
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, 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.
Это ваше право. Тем и хороша свобода.
It's kind of fun to do the impossible (Walt Disney)
Вот интересно, часто в вакансиях требуют наличие опыта работы с SourceSafe.
В чем тут дело? Под этим подразумевается, что человек работал в команде, которая следит за своим хозяйством? Тогда непонятны требования знать что-то конкретное (типа VSS).
Здравствуйте, valmond, Вы писали:
V>Вот интересно, часто в вакансиях требуют наличие опыта работы с SourceSafe. V>В чем тут дело? Под этим подразумевается, что человек работал в команде, которая следит за своим хозяйством? Тогда непонятны требования знать что-то конкретное (типа VSS).
Думаю если использовал аналогичный инструмент, то проблем не будет при устройстве на работу. А команда из более одного человека без SS это .... КАК?
Слежка за сурсами без этого инструмнта\подобных в групповом проекте невозможна\крайне трудоемка
Здравствуйте, LuciferMoscow, Вы писали:
LM>Думаю если использовал аналогичный инструмент, то проблем не будет при устройстве на работу. А команда из более одного человека без SS это .... КАК?
А запросто, есть и CVS, Subversion, ClearCase и т.п.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, LuciferMoscow, Вы писали:
LM>>Думаю если использовал аналогичный инструмент, то проблем не будет при устройстве на работу. А команда из более одного человека без SS это .... КАК? К>А запросто, есть и CVS, Subversion, ClearCase и т.п.
SS употреблял в обобщенном смысле. Просто как жить более чем одному разработчику без аналогичного инструмента?!
Здравствуйте, LuciferMoscow, Вы писали:
LM>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, LuciferMoscow, Вы писали:
LM>>>Думаю если использовал аналогичный инструмент, то проблем не будет при устройстве на работу. А команда из более одного человека без SS это .... КАК? К>>А запросто, есть и CVS, Subversion, ClearCase и т.п. LM>SS употреблял в обобщенном смысле. Просто как жить более чем одному разработчику без аналогичного инструмента?!
А теперь смотрим оригинальны пост:
... непонятны требования знать что-то конкретное (типа VSS).
Здравствуйте, valmond, Вы писали:
V>Вот интересно, часто в вакансиях требуют наличие опыта работы с SourceSafe. V>В чем тут дело? Под этим подразумевается, что человек работал в команде, которая следит за своим хозяйством? Тогда непонятны требования знать что-то конкретное (типа VSS).
Это значит, что они используют именно VSS. И ничего больше.
Здравствуйте, valmond, Вы писали:
V>Вот интересно, часто в вакансиях требуют наличие опыта работы с SourceSafe. V>В чем тут дело? Под этим подразумевается, что человек работал в команде, которая следит за своим хозяйством? Тогда непонятны требования знать что-то конкретное (типа VSS).
Данное требование, как правило, является следствием не совсем грамотного составления вакансии. На самом деле люди хотят знать, умеете ли вы работать с системами типа VSS. В большинстве случаев "знание" сводится к тому, чтобы вы понимали, что такое VSS и зачем он нужен, умели делать Check-In, Check-out, подключать проекты в VSS, делать откат версии и т.п. Я редко встречал использование VSS в качестве реального контроллёра версий и, ИМХО, такая функция VSS достаточно уникальна для каждой конторы. Так что если вы хоть когда-нибудь с VSS работали, то смело можете писать, что имеете опыт.
Smetanin wrote: > > V>Вот интересно, часто в вакансиях требуют наличие опыта работы с > SourceSafe. > V>В чем тут дело? Под этим подразумевается, что человек работал в > команде, которая следит за своим хозяйством? Тогда непонятны требования > знать что-то конкретное (типа VSS). > > По моему опыту — в требования пишется то, что используется в конкретном > месте. Знать именно эот — совершенно не важно. Другое дело что вот > как-то на собеседование приходил программист (несколько лет опыта), > который на вопрос про системы контроля версий интимно спросил > собеседующих: "А вот скажите, положа руку на сердце, вы знаете хоть одну > контору, где какой-то котроль версий реально используют?"
Это в хумор, и опыт делить надвое или натрое. С системами
контроля версий все цивильно. А вот про вумные методологии
проектирования разговор был бы куда интересней...
Здравствуйте, kittown, Вы писали:
K>Smetanin wrote: >> >> V>Вот интересно, часто в вакансиях требуют наличие опыта работы с >> SourceSafe. >> V>В чем тут дело? Под этим подразумевается, что человек работал в >> команде, которая следит за своим хозяйством? Тогда непонятны требования >> знать что-то конкретное (типа VSS). >> >> По моему опыту — в требования пишется то, что используется в конкретном >> месте. Знать именно эот — совершенно не важно. Другое дело что вот >> как-то на собеседование приходил программист (несколько лет опыта), >> который на вопрос про системы контроля версий интимно спросил >> собеседующих: "А вот скажите, положа руку на сердце, вы знаете хоть одну >> контору, где какой-то котроль версий реально используют?"
K>Это в хумор, и опыт делить надвое или натрое. С системами K>контроля версий все цивильно. А вот про вумные методологии K>проектирования разговор был бы куда интересней...
Вы не поверите, но я повидал и RUP под линейкой Rational, и XP без парного кодинга. Обе компании успешные и продолжают расти.
>> > По моему опыту — в требования пишется то, что используется в
конкретном >> > месте. Знать именно эот — совершенно не важно. Другое дело что вот >> > как-то на собеседование приходил программист (несколько лет опыта), >> > который на вопрос про системы контроля версий интимно спросил >> > собеседующих: "А вот скажите, положа руку на сердце, вы знаете
хоть одну >> > контору, где какой-то котроль версий реально используют?" > > K>Это в хумор, и опыт делить надвое или натрое. С системами > K>контроля версий все цивильно. А вот про вумные методологии > K>проектирования разговор был бы куда интересней... > > Вы не поверите, но я повидал и RUP под линейкой Rational, и XP без > парного кодинга. Обе компании успешные и продолжают расти.
Вначале — безотносительно технологий, про "успешные и
продолжают расти". Если компания не раззорилась, то это
не значит, что ее дела идут хорошо. Это может значить
только то, что она умудряется избегать опасных решений
или ей до сих пор удавалось избегать негативных последствий,
а так или иначе достигаемый результат с запасом покрывает
умеренные расходы. Компания вполне может работать при этом
на 10% своего потенциала, расходуя 90% времени впустую,
учитывать один только факт выживания недостаточно.
Мой коммент вверху был не про процесс разработки,
а про зкотические школы дизайна, вроде известной
чуши, будто моделируемый объектами программы
мир должен иметь сходство с реальным, или вроде
технологий визуального конструирования логики
с последующей кодогенерацией — это работает
только на тривиальных примерах.
С процессами разработки все несколько проще, как
и с системами контроля версий. Правда XP немного
мутит воду, но обычно здравый смысл побеждает.
Здравствуйте, gribunin, Вы писали:
G>Здравствуйте, Alex Alexandrov, Вы писали:
AA>>Как человек, поработавший с различными системами контроля версий, могу сообщить, что знание только SourceSafe — примерно тоже самое, что знание только Бейсика. Сейчас работаем с CVS — красота, хотя некоторые нюансы тоже есть. Но работу с SS я вспоминаю, расстраиваясь и вздрагивая. Это ж надо — файл зачекинить нельзя, если другой его зачекаутил! И ведь нормальным и логичным казалось...
G>Дело не в SourceSafe, а в знании матчасти. В SourceSafe же администратор может поставить галочку "multiple checkouts" (или что-то в этом роде) и файлы прекрасно checkout-ятся любым количеством человек.
G>Я работал и с CVS несколько лет и два года с SourceSafe. Могу сказать, что и там и там есть свои плюсы и минусы, но для разработки вполне можно использовать как первую систему, так и вторую.
И какие есть минусы у CVS по сравнению с SS? Я с ходу могу назвать только один факт: SS умеет хранить дельты бинарных файлоы, CVS хранит все целиком. Но и это назвать проблемой я не могу.
В общем, работать, конечно, можно и с SS, если:
— не идет речь о кросс-платформенной разработке (про SS для Unix я слыхал, но ни разу не видел человека, использующего это).
— устраивает поддержка бранчей, имеющаяся в SS.
— в случае распределенной разработки устраивает файл-серверное решение, т.е. необходимость иметь network share с данными репозитория. HTTP, SSH не получится.
Самым большим аргументом против SS для меня является то, что его не используют внутри Microsoft, компании, которая больше других исповедует принцип eat your own dog's food.
[ Posted via RSDN@Home 1.1.4 beta 4 (303) listening to silent ]
It's kind of fun to do the impossible (Walt Disney)
Alex Alexandrov wrote: > > Здравствуйте, kittown, Вы писали: > > K>Хитрое это слово, checkout. Перед глазами живой пример, где > K>checkout как раз означает "извлечь и залочить". Операция > K>извлечения без лочки называется иначе. > > Как? В CVS это называется как раз check out.
Где как. Где-то get. Разных систем контроля версий того или
иного барахла немало. cvs — одна из самых слабых, про vs
вообще молчу. Кто-то, как у наших буржуйских партнеров,
свою написал, не найдя ничего подходящего готового.
> K>Но работать без лочки — вешалка. Понаделал изменений, протестил, > K>собрался сабмитить, а там уже кто-то успел что-то всерьез поменять > K>и надо заново все тестить. Поэтому народ специально лочит, а > K>система не позволяет лок обойти. > > А Вы с какой системой работаете сейчас? С блокирующей? И что, раньше > работали с неблокирующей и было хуже?
Что блокирующей ? Когда блокирующей ? Простое вытаскивание сорса
не блокирует — конкретный снапшот сорсов связан с конкретной
веткой и конкретным временем, он не может изменяться при
повторном извлечении. Не помню как с этим в cvs. А вот при
желании изменить — нормальный человек сам заблокирует. Потому
как если ему вдруг придется делать merge, то ему еще и
перетестирование делать придется. Непротестированный код
нельзя сабмитить вообще.
> Если 2 человека работают одновременно над одним файлом, то это либо > багфиксы, либо неправильная организация модулей.
Необязательно.
> Багфиксы перекрываются > относительно редко. В любом случае, между неблокирующей моделью с > возможностью редких конфликтов и блокирующей моделью с необходимостью > курить бамбук, если кто-то взял файл для фикса на 3 строки, я выбираю > первый.
И снова — когда и что блокирующий ? Если нужный файл кем-то
заблокирован для изменений, можно его спросить до каких пор
и заняться временно чем-то другим. Не так уж часто нужно.
Здравствуйте, Alex Alexandrov, Вы писали:
AA>Самым большим аргументом против SS для меня является то, что его не используют внутри Microsoft, компании, которая больше других исповедует принцип eat your own dog's food.
Здравствуйте, kittown, Вы писали:
K>Где как. Где-то get. Разных систем контроля версий того или K>иного барахла немало. cvs — одна из самых слабых, про vs K>вообще молчу. Кто-то, как у наших буржуйских партнеров, K>свою написал, не найдя ничего подходящего готового.
))) И что, написал нечто лучшее CVS или Subversion? Я вообще с опаской отношусь к людям, которые затевают писать свой Version Control или Bug Tracking. Работать надо, своим делом заниматься, а не поделки на коленке лепить.
K>Что блокирующей ? Когда блокирующей ?
Здесь и далее под блокирующей системой понимается невозможность получения рабочей копии файла для изменений одновременно несколькими пользователями.
K> А вот при K>желании изменить — нормальный человек сам заблокирует. Потому K>как если ему вдруг придется делать merge, то ему еще и K>перетестирование делать придется. Непротестированный код K>нельзя сабмитить вообще.
Если изменения в одном файле ортогональны, то никакого перетестирования не потребуется. Точнее, понадобится просто прогнать еще раз свои тесты (они должны быть автоматизированы и быстры), но проблем это не вызовет.
>> Если 2 человека работают одновременно над одним файлом, то это либо >> багфиксы, либо неправильная организация модулей.
K>Необязательно.
ОК, перефразирую. Если 2 человека работают одновременно над одним местом в одном файле и это вызывает проблемы при коммите, то это неправильная организация труда.
K>И снова — когда и что блокирующий ? Если нужный файл кем-то K>заблокирован для изменений, можно его спросить до каких пор K>и заняться временно чем-то другим. Не так уж часто нужно.
А если кто-то заблокировал и в отпуск ушел? А если люди в разных часовых поясах? Да и просто, зачем блокировать, если можно обойтись без этого?
А вообще нет желания затевать флэйм по этому поводу, ибо как на РСДН это уже было
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>
. Мне нравятся > CVS и Subversion, мой опыт с SourceSafe мне не понравился.
От более-менее уважаемых людей я чаще всего слышу про Clearcase и
Perforce, оба пока не смотрел. В мелких проектах — CVS, в
средних — в зависимости от размера фирмы. Та, что у нас (PLS),
закрыта, в гугле ее можно найти только в резюме "бывших". Про
остальные системы слышал мало, и в основном на сайтах разработчиков.
Здравствуйте, 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 — система для другого. Не для офиса.
Здравствуйте, 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 не уступают многим дорогим коммерческим продуктам. Ваше мнение лишь доказательство того, что маркетологи не зря получают зарплату.
It's kind of fun to do the impossible (Walt Disney)
Alex Alexandrov wrote: > > Здравствуйте, kittown, Вы писали: > > K>Написал. Собственно с cvs даже сравнивать неинтересно. > K>Текущее базовое руководство датировано 97 годом, а похожее > K>на текущее состояние было уже где-то в сентябре 94, но > K>постоянно добавляется что-то еще сверху. > > K>По информации от 99 года, в системе тогда хранилось уже > K>более 300 миллионов строк кода. Изначально дизайнилась > K>для мейнфреймов IBM. > > Можно узнать конкретные преимущества по сравнению с CVS и, самое > главное, SVN?
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, а это является
одним из наиболее полезных компонент в толстой разработке.
SkyDance wrote:
>> По поводу удобства работы — для CVS достаточно GUI решений, > > Вы сами-то пробовали с ними работать? Попробуйте, командная строка > станет еще ближе.
Together, Eclipse при работе с cvs неудобны ?
>> Например, ты правишь файл и видишь сомнительное место. >> Можешь показать способ как в SS ты узнаешь, кто последний >> изменял эту строку? > > Угу. Diff, затем смотрим, кто чекинил. Кстати, а зачем это нужно, кроме > как для "надавать по башке нерадивому программеру" (что изначально есть > гадкое дело).
Выяснить детали, зачем были нужны конкретные изменения, когда это не
до конца ясно. Как раз на днях пришлось вычислять автора и вопрошать.
Здравствуйте, SkyDance, Вы писали:
SD>"kittown" <32673@users.rsdn.ru> wrote in message SD>news:1069376@news.rsdn.ru... >> Together, Eclipse при работе с cvs неудобны ?
SD>Да.
А WinCVS, TortoiseCVS?
>> Выяснить детали, зачем были нужны конкретные изменения, >> когда это не до конца ясно
SD>Комментарии нынче не в моде? Или религия запрещает? Или культура SD>разработки...?
Разумеется, можно и контроль версий каталогами на шаре организовать. Мы же о функциональности конкретного средства говорим, а не о возможности обходного пути.
It's kind of fun to do the impossible (Walt Disney)
SkyDance wrote: > >> Together, Eclipse при работе с cvs неудобны ? > > Да.
Гм. Надо будет самому еще раз посмотреть — я от
cvs вообще уже отвык.
>> Выяснить детали, зачем были нужны конкретные изменения, >> когда это не до конца ясно > > Комментарии нынче не в моде? Или религия запрещает? Или культура > разработки...?
Комментарии есть, но иногда не хватает. Например, когда
автор посчитал что-то слишком очевидным. Для него.
Во многих случаях есть смысл сделать совершенно осознанный выбор в пользу VSS.
