Software Configuration Management

Я и аз да попитам нещо: Какви SCM системи ползвате?

Доста хора мислят, че SourceControl и Version Cоntrol системите са достатъчни, няма нужда от SCM. ОК, ако някой е убеден в това и може да ми даде разумни стратегии за накой стандартни ситуации: бранчване и мърджване на нов девелопмент, бек-портинг на бъг фиксове, стабилизиране на релийзи, ще съм му преблагодарен.

Аз в момента работя с най-изродската SCM система, познайте коя .... (a.k.a ClearCurse) Единственото, което и признавам е, че е много добра на ауто мърджа. Иначе а мъка от всякъде. Има някакъв идеотски процес, измислен от IBM, който обаче предполага, че всяка промяна първо се планира (от Project Manager-а) и чак тогава почва да се имплементира. В реал лайф ... друг път. И респективно ние не го спазваме (процеса имам пред вид). И става манджа с грозде. Два дена мърджвам от един девелопмент стреам в един продакшън такъв и псувам грозно, всички, дето ходят правят чек-ин за два изтрити таба :-)

(Преди съм ползвал svn, CVS, VSS, но никоя от тях сама не решава проблемите)

Използвам git и mercurial. Не очаквам чудеса от SCM, затова и не се оплаквам.

The last good thing written in C was Franz Schubert's Symphony No. 9.

Според мен Mercurial ще ти свърши работа. Аз си ползвам Subversion, но то е защото изискванията ми са по-скромни.

SVN + JIRA + FishEye със стронг линк между тасковете в JIRA и къмитите в SVN.
От продукти на Rational като ClearQuest / ClearCase бягам надалеч.

OK, git и mercurial - прекрасно.
Аз също не очаквам чудеса. Но поне очаквам някаква автоматизация на процесите.

Колко човека ползвате едно и също репозитори? Има ли варинат повече от една група девелопери да разработват паралелно няколко проекта?
Ако да - как го правите - всеки си има свой бранч, сандбокс (наричай го както искаш) Tогава не си пречите, но прoблема става, ако едновременно трябва да мърдженете за релийз. Обратно, ако сте постоянно мърджнати, едно си пречите постоянно, но още по-лошо ако накрая за релийза остане само единия проект, пък другия трабва да не се рилийзва. Тогава ще работи ли първия проект без втория?

TFS.
Има си всичко.
Малко шибана е миграцията, ама то радост без болка няма:-)

"Аз ползвам" да разбирам ли, че си единствения девелопър в проекта?

Но дори и да е така, пак ше стигнеш до този проблем (примерна постановка):
Имаш ядро A, и някакви компоненти - N,M,P искаш да боцнеш 2 нови компонента: X и Y. Как ше го направиш на svn? И X и Y изискват малки разширения на ядрото A, но (хайде да е по лесно) не зависят един от друг.

Всичко в trunk-а?

Аз ти писах, че според мен за теб най-добре е Mercurial. Бачкали сме трима души с него по един и същ проект и съм много доволен. Там всеки си бранчваше нещо си и си работеше по него.
За мои нужди SVN е достатъчен. Аз всеки проект си го качвам в рипозитъри, защото може да си включат и други ленсъри в него, или просто може да изляза на кафе с лаптопа и да къмитвам оттам.
Има си кусури естествено, от които най-дразнещия е ако пейстнеш нов файл върху стар със същото име, но със свикване всичко тръгва идеално.


p.s. Ако има промени в ядрото, това което си писал, няма как да стане с SVN (освен ако програмно няма опция да се зареждат различни ядра), или поне аз не се сещам как.

ОК, не съм пробвал с Mercurial.
Но се опасявам, че "ultimate" решение на проблемите дето ме мъчат няма. То това дори е ясно, и чертата за това говори.
Дори не е толкова важно коя е сорс контрол системата (стига да не е много куца, де). По-скоро са някакви правила, тактики, техники за девелопване, дисциплина някаква дето да се спазва но ... още не мога да ги намеря.
И книжки уж съм търсил, работил сзм в много голяма интернешънъл фирма .... за момента решение няма.
И вие не казвате ...

Ами то е така и в моя случай. Ако свикнеш с нещо се организираш то същото да ти върши работа. Единствения SVC, с който не можах да свикна е майкрософтския, който се инсталираше по дифолт с VS6. Забравих му името.

Е, бате, ти къде ме прати? От IBM, та на MicroSoft ....
Викаш има си всичко. То всички имат всичко :)
Кво си ползвал преди TFS? Защо мислиш че е по-добър от някоя фрий система.
Кой фичър примерно го няма при другите системи.

Дочувам слухове за P4 в комбинация с Jenkins (Hudson). То е ясно, няма най-добро решение, но каквото и да е решение е по-добре от никакво.

Разбира се в trunk-а иначе ще станеш разноглед от версии на ядрото.

Най-добре измисли как X и Y да могат да extend-ват A без да се налага всеки път да го ръчкаш -- plugin-и дето му викат, extension-и.

[линк]

Perforce (P4) съм ги признал. Ползвал съм техни тулове, и в момента ползвам 3 way merge-a им и съм го обявил за най-якия тул за такива цели.
Но никога не съм позвал цялата им система ... :(

P.S.: Забравих да кажа, че P4Merge е фрий, т.е. инсталира се цялата система и тя няма да работи без лиценз, но diff/merge работи. Препоръчвам го, почти не греши.

Не сме много хора и нямаме проблеми. Най-големия проект, използващ scm по който съм работил е ядрото на Линукс. Там нещата мисля че са ясни -- всеки си има негов "бранч", има отговорници за подсистемите, които поддържат "бранчове" на ниво подсистема. Отговорност на merge има създателя на промяната и може да се наложи да merge многократно, докато отговорника на подсистемата благоволи да включи промяната му в неговата версия.

Иначе въпросите ти са сериозни, отговорите се съдържат в конвенции за работа извън scm. Понякпга дори се налага да говориш с колеги -- един от рисковете на професията :Р

The last good thing written in C was Franz Schubert's Symphony No. 9.

Бе разбирам ти съвета, make sense, дето се казва, ама не винаги е опция.
Много скоро trunк-a ти ще се напълни с всякакви щуротии (нашата фирма сме почти в този случай) включително и такива дето никога няма да видят бял свят и само пречат.
Значи много бранчове е лошо (да не говорим, че бранча в SVN а е турбо евтин, т.е. не струва нищо и се бранчва наистнина като промениш), а всички лайна в трънка е добре. Не съм единодушен.

Що не обратно: всеки нов модул в бранч, като се види че ше го бъде, тогава мърдж в трънка и се поддържа само там. (бранча се зарязва)

Да ве, л'уесно нема :)
Докато ровех, намерих тука един не лош пейпър. Старичък е, от 1998, ама някой неща не се променят ....
Явно ми трябва някакъв много по-подробен вариант на такъв документ.
И да успоея да убедя манагерите, че такав дисциплина трябва, пък те да нашокат репите на останалите да следват дисциплината ...

най-хубавото, което си спомням от ClearCase е, че можеш да смениш версията на VOB-a с един ред в config файла. Ама я товарехме към 100-на човека едновременно и се справяше. Проблема беше, че трябваше да я научи човек, което отнема време и имаше един човек на 1/2 работно време да се занимава с нея.
P4 също беше добра, доколкото си спомням. Работил съм и с TFS и с SVN. Всички вършат работа, ако им научиш чалъмите.

mercurial + ssh + private keys + hg-ssh + acl
всеки проект си е различно репозитори

Това е положението - свиквай

божке ...... я седни чети малко бе