Вот интересно, часто в вакансиях требуют наличие опыта работы с 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 работали, то смело можете писать, что имеете опыт.
Здравствуйте, valmond, Вы писали:
V>Вот интересно, часто в вакансиях требуют наличие опыта работы с SourceSafe. V>В чем тут дело? Под этим подразумевается, что человек работал в команде, которая следит за своим хозяйством? Тогда непонятны требования знать что-то конкретное (типа 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 немного
мутит воду, но обычно здравый смысл побеждает.
Здравствуйте, 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. Могу сказать, что и там и там есть свои плюсы и минусы, но для разработки вполне можно использовать как первую систему, так и вторую.
Здравствуйте, 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)
Здравствуйте, 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>и заняться временно чем-то другим. Не так уж часто нужно.
А если кто-то заблокировал и в отпуск ушел? А если люди в разных часовых поясах? Да и просто, зачем блокировать, если можно обойтись без этого?
А вообще нет желания затевать флэйм по этому поводу, ибо как на РСДН это уже было
Здравствуйте, 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)
