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.

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