Процес розвитку сайту

[Code_Warrior]

Цікава ідея. Особисто я за Subversion хоча і Git наче не погана річ.

[Cthulhu]

Цікава ідея. Особисто я за Subversion хоча і Git наче не погана річ.

Вони, взагалі-то, призначені для зовсім різних моделей розробки, тому їх порівнювати просто не можна; до того ж, сотні мільйонів kernel-девелоперів не можуть помилятись.

[Code_Warrior]

їх порівнювати просто не можна

А я і не порівнював Просто з Git я тільки почав розбиратися і ще не зовсім зрозумів що до чого, а от Subversion мені ближче.

[Cthulhu]

М-дя. Толку з такого голосування... пропоную зупинитись на git (як на найбільш середньому варіанті) і припинити балаган.

[Re.]

+1 hg. Ми ж не ядро розробляємо, як-не-як.

[yurchor]

Гіт чи меркуріал (ІМХО) - я так й не зміг достоту в'їхати в cvs/svn, в той час як у мережі повно мануалів типу "гіт для чайника за п'ять хвилин".

http://www.cs.put.poznan.pl/csobaniec/Papers/svn-refcard.pdf

Ніколи не розумів: на біса все виконувати з консолі, у три команди, які складаються з вдвічі більшої кількості символів, і все у проекті, у якому 1-2 розробники. Зростає крутизна?

Гілки (branches)? А що будуть випуски?

Синхронізація гілок (cherry-pickup)? А що будуть дві гілки розробки?

Як уже хочеться всього вище переліченого, тоді краще Bazaar: Canonical наробила йому тисяча і одну графічну морду з можливостями аналізу і синтезу.

А взагалі, ідіотизм крокує планетою: DVCS пхають куди треба і куди не треба. Точно як той Python. Скоро будь-який розробник hello-world вважатиме своїм обов’язком створити вісім гілок у сховищі, а щоб зібрати програму треба буде виконати серію хитромудрих команд зі звантаження даних зі сховища і переходу до версії, яку хоч якось можна зібрати.

[Cthulhu]

Пан має досвід використання різних систем контролю версій у реальних проектах? Пан може дати порівняльну характеристику, чи обґрунтовану пораду, коли і яку систему використовувати? Якщо пан не має і не може, то я попросив би пана зайнятись якимось іншим корисним ділом; тут холівари явно не доречні.

[yurchor]

M: * за провокацію флейму.

[piktor]

Гілки (branches)? А що будуть випуски?
Синхронізація гілок (cherry-pickup)? А що будуть дві гілки розробки?

Будуть. Якщо експериментами побажають займатися декілька учасників, кожен зробить собі свій ЛОУ з преферансом і поетесами.
З одного боку yurchor ніби правий - навіщо купувати дорогущий Photoshop, якщо намалювати все можна в безкоштовному Paint.NET. З іншого боку, ПЗ, необхідне для реалізації вищезапропонованих можливостей, абсолютно безкоштовне і якщо ми не використаємо і 10% можливостей того git - то і що, воно їсти не просить, аби нормально працювало те, що нам потрібно.

[Михайло Даниленко]

Власне, чого я за hg - якщо буде декілька тестових версій, то за допомогою mq (mercurial queues extension) дуже зручно підтримувати твої зміни синхронізованими зі змінами у upstream. По-перше, зміни не губляться десь в історії комітів/синхронізацій, по-друге, ці зміни не фіксовані - ви можете в будь-який момент допиляти коміт й таким чином тримати історію організовано й в чистоті до того часу, як апстрім прийме ваш патч. По-третє, при синхронізації з апстрімом репо з декількома патчами, вам доведеться розбиратися за раз лише з пов'язаними між собою змінами одного патчу, а не зі зваленими в купу змінами всіх ваших патчів vs зваленими в купу змінами апстріму, як це є при merge.
Звичайно, можна замість mq використовувати quilt (я не пробував, тому не скажу, наскільки це зручно) у зв'язці з будь-якою системою контролю версій...

[Володимир Лісівка]

Власне, чого я за hg — якщо буде декілька тестових версій, то за допомогою mq (mercurial queues extension) дуже зручно підтримувати твої зміни синхронізованими зі змінами у upstream. По-перше, зміни не губляться десь в історії комітів/синхронізацій, по-друге, ці зміни не фіксовані — ви можете в будь-який момент допиляти коміт й таким чином тримати історію організовано й в чистоті до того часу, як апстрім прийме ваш патч. По-третє, при синхронізації з апстрімом репо з декількома патчами, вам доведеться розбиратися за раз лише з повʼязаними між собою змінами одного патчу, а не зі зваленими в купу змінами всіх ваших патчів vs зваленими в купу змінами апстріму, як це є при merge.

Для сабверсії: http://savana.codehaus.org/gettingstarted.html — воно?

[Михайло Даниленко]

Мабуть воно, хоча я ніби не побачив можливості зміни вже зроблених комітів, і не зрозумів, чи можна робити декілька користувацьких гілок, що б накладалися одна на одну послідовно (власне, якщо комміти незмінні, було б добре мати можливість тримати й розробляти не пов'язані між собою модифікації окремо). Проте можливо я просто незнайомий з svn, тому погано уявляю звичайний процес розробки з її використанням, а отож не бачу можливостей/зручностей.
Edit:

P.S. Правда MQ теж має недоліки - він заснований на quilt, відповідно, використовує патчі у форматі diff, отож мабуть погано/зовсім не працюватиме з бінарними файлами на кшталт малюнків.

[noddeat]

додав ентропії до цього опитування — проголосував за всі пункти, бо сам пробував лише svn і то пару разів.

[Satan]

А що із цього потребує мінімум мороки при освоєнні?

Flame:

Perforce

освоїти так, а от користуватись не дуже. мені він не подобається. крім того він платний (хоча здається для open source безкоштовний)

швидше всього освоїти SVN

svn checkout
svn update
svn commit
svn add

цих команд вистачить на довгий час.

хоча звісно ця технологія застаріла. майбутнє за розподіленими системами. такими як Bazaar i Mercurial.

доречі чому в списку немає Bazaar ?

[Cthulhu]

хоча звісно ця технологія застаріла. майбутнє за розподіленими системами. такими як Bazaar i Mercurial.

доречі чому в списку немає Bazaar ?

Пан має досвід використання різних систем контролю версій у реальних проектах? Пан може дати порівняльну характеристику, чи обґрунтовану пораду, коли і яку систему використовувати? Якщо пан не має і не може, то я попросив би пана зайнятись якимось іншим корисним ділом; тут холівари явно не доречні.

Хто які ще страшні слова знає? Де мої cvs і darcs?

M: якщо хто хоче пофлеймити на тему різних VCS, хай створює тему в балачках. Тим, хто робить це тут, буду видавати зірки, плюси і бани. З насолодою.