VSS check-in

[Sabina]

Интересно какие вообще существуют правила (VSS check-in routine) в разных компаниях?

У нас постоянно приходится иметь дело с тем, что кот-нибудь вытащит кучу файлов и потом их по одному check-ает in c интервалом в полчаса.
То есть если кому приспичило cделать getLatestVersion, то может и не компилироваться.

Неужели трудно вытащить файлы, которые надо, исправить что хочется, протестировать и потом сразу check-in один за другим?
Просто просьбы не работают, вот думаю может какую-нибудь routine написать.

Cабина

[CTAC_P]

Помнится, мы просто снимали read-only атрибут руками и потом, когда файл освобождался, запихивали свои изменения в VSS.

[Sabina]

Помнится, мы просто снимали read-only атрибут руками и потом, когда файл освобождался, запихивали свои изменения в VSS.

Тоже чревато. Тогда надо Show Diff аккуратно проглядывать, чтобы чью-нибудь работу не затереть.

Cабина

[uncle_Pasha]

То есть если кому приспичило cделать getLatestVersion, то может и не компилироваться.

Дык, это не VSS. Подход стоит поменять.
Последняя версия и не обязана компилиться (особенно в больших проектах, это просто невозможно). Компилиться должна последняя стабильная версия - на нее можно поставить label. И если есть необходимость вытащить что-то компилящееся - надо брать версию по label, а не последнюю.
Далее, работа строиться в зависимости от возможностей репозитория (private, task, integration branches, merge&integration policies, etc), но упомянутое выше - базовые возможности, которые существуют в любом репозитории (даже в самых элементарных - CVS, VSS, PVCS, etc), и должны использоваться.

Удачи!

[Vovka]

Последняя версия и не обязана компилиться (особенно в больших проектах, это просто невозможно). Компилиться должна последняя стабильная версия - на нее можно поставить label. И если есть необходимость вытащить что-то компилящееся - надо брать версию по label, а не последнюю.

Это что, каждый день (точнее, каждую ночь) по новой метке что-ли ставить?

[uncle_Pasha]

Это что, каждый день (точнее, каждую ночь) по новой метке что-ли ставить?

Если integration build каждую ночь - да. Это что, проблема?

Стратегии могут быть разными - от новой метки на весь код/использование различных меток на разнык компоненты и запись использованных компонент в файл конфигурации/метки только на измененный код (incremental baseline).
В противном случае, как Вы сохраните конфигурацию?
Правило простое: если Вы в любой момент в будущем можете воспроизвести билд (и конфигурацию - настройки системы, структуру базы и т.п.) и система появится рабочей, как она была после оригинального билда - основная задача выполнена. Это означает, что Вы знаете что именно Вы строили.

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

Удачи!

[Big Cheese]

Последняя версия и не обязана компилиться (особенно в больших проектах, это просто невозможно). Компилиться должна последняя стабильная версия - на нее можно поставить label. И если есть необходимость вытащить что-то компилящееся - надо брать версию по label, а не последнюю.

Это что, каждый день (точнее, каждую ночь) по новой метке что-ли ставить?

Может, и не каждый день, но на каждый build - определенно надо. Насколько я знаю, во многих (особенно - больших) компаниях принята практика daily (nightly) builds, по-этому новые метки ставятся ежедневно.

[Vovka]

Это что, проблема?

Да нет - точнее, не знаю просто.

У нас source control вообще больная тема, такие вот муки терпим:
1. Используется база от VSS со своей оболочкой, ибо VSS удалённо, как говорят, работать не умеет по-нормальному.
2. Для редактирования гетимся, ручками снимаем R/O, потом мёржимся.
3. Вчекинивать можно только в первой половине дня, ибо потом тестовый билд.
4. С хотфиксами вообще песня. Из-за ограничения в размере базы VSS (она вроде как после 2Gb по-нормальному не работает), хотфиксы в отдельной БД, так что когда фиксишь баги, иной раз одно и то же в несколько VSSок вчекиниваешь.

Вот так.

[Vovka]

Насколько я знаю, во многих (особенно - больших) компаниях принята практика daily (nightly) builds, по-этому новые метки ставятся ежедневно.

Да у нас то же самое, но метки мы только на "релизы" ставим.

[uncle_Pasha]

Да у нас то же самое, но метки мы только на "релизы" ставим.

Если тестерам тоже только "релизы" выставляются, то это нормально.
Зачем только тогда билдиться каждую ночь?

Удачи!

[uncle_Pasha]

4. С хотфиксами вообще песня. Из-за ограничения в размере базы VSS (она вроде как после 2Gb по-нормальному не работает), хотфиксы в отдельной БД, так что когда фиксишь баги, иной раз одно и то же в несколько VSSок вчекиниваешь

Это стандартная история для тулзов класса CVS/VSS/PVCS, связанная не столько с ограничениями по базе (2GB source code - это очень много), сколько с бедными функциональными возможностями для параллельной разработки.

Я бы попытался оценить эти потери времени в деньгах (за 2-3 года). Очень может оказаться, что лицензии нормального репозитория стоят дешевле

Удачи!

[Sabina]

Последняя версия и не обязана компилиться (особенно в больших проектах, это просто невозможно). Компилиться должна последняя стабильная версия - на нее можно поставить label.
И если есть необходимость вытащить что-то компилящееся - надо брать версию по label, а не последнюю...

Ага, теперь многое проясняется У нас всего 5 программистов и поэтому все происходит так стихийно. 3 очень даже опытных, но они видимо приспособились и выдергивают из VSS только то, что им надо.
Я тоже так в основном делаю, но вот пришлось в связи с переходом на телекомьют, скачать все за раз. А мне (как интерну-самоучке ) даже в голову не пришло попробовать брать все из стабильного билда.

Сабина

[Sabina]

Это что, каждый день (точнее, каждую ночь) по новой метке что-ли ставить?

Если integration build каждую ночь - да. Это что, проблема?

У нас так и есть, но он где-то процентов 10% валится. Именно потому, что кто-нибудь забыл сделать check-in или наоборот сделал его слишком рано. Причем это 2 конкретных товарища

А перед тем как сделать стабильный билд, командир VSS всех обходит и уточняет все ли checked in и проч.

Сабина

[Big Cheese]

Это что, проблема?

У нас source control вообще больная тема, такие вот муки терпим:
1. Используется база от VSS со своей оболочкой, ибо VSS удалённо, как говорят, работать не умеет по-нормальному.
2. Для редактирования гетимся, ручками снимаем R/O, потом мёржимся.
3. Вчекинивать можно только в первой половине дня, ибо потом тестовый билд.

2 - сочуствую...IMO, shared checkout is a must для нормальной системы...
3 - это лечится установкой build labels. Вообще, я согласен с uncle_Pasha - в чем смысл билда, который потом нельзя (или геморройно) воспроизвести?

[CTAC_P]

Помнится, мы просто снимали read-only атрибут руками и потом, когда файл освобождался, запихивали свои изменения в VSS.

Варварство... Если мне не изменяет память, в VSS 6.0 уже был куда более цивилизованный путь организовать multiple checkouts и merge.

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

[Boriskin]

У нас было так - два дерева в VSS, одно final, другое dev. В первом чекаутишь файлы, с кот. работаешь (багфикс/фича/етс) (множественный/одиночный - по барабану), создаешь отдельный проект во втором дереве для этого дела и все изменения вносишь только в dev tree. Когда все готово - чекинишь в final, при этом это твоя responsobility проверить что все тип топ в смысле мержа,верисий и конфликтов. Введение подобного подхода в купе с верификацией code changes другим девелопером из тима позволило уменьшить кол-во build breaks примерно раз в 5 - по старинке, когда каждый сам чекинил что хотел и как хотел, 1 - 2 раза в неделю build лежал, с новым процессом это стало случаться раз в 2-3 недели...

ЗЫ Build делался ессно с final, который локился каждый вечер часов в 10...

[CTAC_P]

Может быть, но у меня работа была несколько специфичная - искать баги и тыкать носом.

(злостный офф-топик): Коллега?

Мне обычно дают тонну кода кое-как работающего под Windows и "все что надо сделать" это запихать всю эту мутотень в железяку.

[Sabina]

Sabina, please excuse me for off-topic again.

Всегда, пожалуйста. Мне-то что, лишь бы модератор не ругался

Сабина

[Sabina]

Комментарий на злобу дня:

Сегодня делала checkin - checkout парочки популярных файлов и вдруг вылезли ошибки при компилляции.
Один коллега изменил методы в бинах с set/getMACAddress() на set/getMacAddress(). Причем своего кода у него там с lower case на пять копеек, так он же не поленился, слазил во все бины и вытекающие из них методы и везде поправил на lower case.

Насколько я помню правила naming в Java, аббревиатуры оставляют upper case. И потом MAC Address - это звучит, а что такое Mac Address ,
А самое главное - какую он каку кинул тем, кто по кускам get latest делает.

Или я не права ?

Сабина

ЗЫ. А тут еще емейл пришел от 10pm билда - build failed с рекодным количеством ошибок - 16, и все в файлах этого самого товарища...
Ну как вот еще с такими бороться?

[Dmitry67]

Это еще ничего
Я как то поставил себе тут русскую "локаль"
И сделал check in. У всех пошли ошибки
Оказывается, после моего checkin французские буковки с аксантами éèà итд стали русскими

[Boriskin]

ЗЫ. А тут еще емейл пришел от 10pm билда - build failed с рекодным количеством ошибок - 16, и все в файлах этого самого товарища...
Ну как вот еще с такими бороться?

Вариантов много
1) Ломатель приносит коробку донатов. (мне приходилось пару раз )
2) Ломатель получает переходящий приз - пейджер, на который посылается мессага в случае следущего build-break и держатель которого обязан явиться на работу для починки проблем независимо от времени суток (один из тимов в MS)
3) ....

[Vovka]

Я бы попытался оценить эти потери времени в деньгах (за 2-3 года). Очень может оказаться, что лицензии нормального репозитория стоят дешевле

Да были мысли такие, были.
Однажды даже эвалюировали другую систему - Perforce (как она, считается "нормальной"?). На пару месяцев перетащили туда одну из VSSок. Вроде понравилось, никто сильно против не был - а всё равно всё заглохло - сказали, что дорого слишком.

[uncle_Pasha]

Однажды даже эвалюировали другую систему - Perforce (как она, считается "нормальной"?). На пару месяцев перетащили туда одну из VSSок. Вроде понравилось, никто сильно против не был - а всё равно всё заглохло - сказали, что дорого слишком.

Сколько у Вас пользвателей? За счет лицензионной политики Perforce (per-user-account licenses), это, пожалуй, самое дорогое решение при количестве клиентов более 15-20.

Удачи!