Новая система управления версиями от разработчиков Ubuntu

Расскажите мне неразумному, а зачем нужна децентрализованная системы управления версиями?

Я всегда думал, что репозиторий, это чтобы собрать все исходники в одном месте, и держать их там в актуальном состоянии. А тут кажется предлагается ровно противоположное...

о_О Базааар! =)

надо будет заценить

А по ссылке сходить, не?

According to Canonical, a centralized VCS may work fine for proprietary, tightly controlled projects, but it doesn't work well for open-source or outsourced projects where programmers are often scattered across the globe. The company also claims that "Bazaar has been used successfully by commercial projects with hundreds of developers spanning multiple continents."

без базара, заценим базар!

http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html 1.1.3 Central vs distributed VCS

> Я всегда думал, что репозиторий, это чтобы собрать все исходники в одном месте, и держать их там в актуальном состоянии.

А вы просто неправильно думали. VCS предназначены совершенно для иного, а именно - для совместной работы над проектом. В ряде случаев децентрализованная система гораздо удобнее.

Уже черти сколько времени живёт в dev-util/bzr... надо будет обновить, поглядеть...

Сходил по ссылке. интересная вещь. Жаль что к kdevelop'y плугинчика нету.

+1 shaplov-у... по-моему как назвали так и получится - будет полный базаар и бардаак... идея, видимо, была в том, чтобы сильно упростить мержинг.

Вообще-то этой новой системе три года скоро исполнится. :) А в версии 1.0 основное изменение - новый формат репозитория, который, по обещаниям, всех порвёт по производительности.

чета теперь каждый ламер новую CVS пишет

зачем спрашивается? svn, git, bazaar... народ на велосипеды чегойта тянет зверски

Децентрализованая система нужна для того, чтобы переложить бремя покупки резиновых хардов с плеч бедных недоедающих эксплуататоров и манагеров на зажравшихся индусов? :)

>чета теперь каждый ламер новую CVS пишет

Сэр, имхо вы немного не в теме. Git/bazaar/mercurial концептуально отличаются от централизованных VCS вроде CVS или Subversion. Распределенные системы управлениями версиями намного лучше подходят для opensource-разработок, чем традиционные. И пишутся они отнюдь не ламерами:).

> без базара, заценим базар!

За базар ответишь!

А чем лучше? А то как:
"
А - А армяне лучше чем грузины
Г - ...
А - А армяне лучше чем грузины
Г - ???
А - А армяне лучше чем грузины
Г - Да чем лучше то? Чем?
А - Чем грузины!
"

> but it doesn't work well for open-source or outsourced projects

Хотелось бы таки понять почему doesn't work well. О том и спросил... По карйней мере именно об этом думал когда спрашивал.

> Хотелось бы таки понять почему doesn't work well. О том и спросил...

Попробуй долго поработать там, где нет канала к твоему серверу VCS. Или попробуй поработать так, чтобы до определенного момента результатов твоей работы никто не видел.

> в версии 1.0 основное изменение - новый формат репозитория

Это какой по счёту - 3-й или 4-й?

> по обещаниям, всех порвёт по производительности.

"Ошибка в ДНК" (c)

>Хотелось бы таки понять почему doesn't work well. О том и спросил..

затем, что никто тебе не даст просто так доступ на запись в официальный репозитарий

> Децентрализованая система нужна для того, чтобы переложить бремя покупки резиновых хардов с плеч бедных недоедающих эксплуататоров и манагеров на зажравшихся индусов? :)

Хи-хи-хи, как смешно! Конечно, если не знать, что в современных VCS, типа Mercurial, производится дифференциальное bz2-сжатие, в результате чего репозиторий обычно по размерам не сильно больше рабочей копии.

>Или попробуй поработать так, чтобы до определенного момента результатов твоей работы никто не видел.
Делаешь форк отдельногой ветки и вперёд, даже доступ к серверу при этом не нужен. Нужен только на момент комита.

BTW, я с вами(хотя могу и ощибаться) уже кажется спори по этому поводу, доказывая, что в 99% случаев достаточно к примеру Subversion.

DVCM нужен(по моему личному опыту), если у вас многоуровневый комит.
К примеру совсем дикие вьетнамцы комитят всё на сервера китайцам, котрым идусы отусорсят проекты, когда сами не успевают их делать. Потом китайцы убирают камменты на вьетнамском, заменя их на камменты на китайском и на какую-то хрень на языке, который они считают английским и коммитят это на идусские сервера. Индусы убирают каменты на китайском и заменяют их на каменты на английском, хинди, суахили и ещё примерно сотне живых языков. Так как китайского и той хрени, которую китайцы написали на латинскими буквани они не понимают, то читать это потом интересно и познавательно с любой точки зрения, кроме как с программистской. Потом всё это идёт на сервера оутсорсинговой конторы, которя добавляет туда красивые хедеры из каментов и пытается это запустить. Так как нихрена не работает, по этот комит заказчику не идёт или идет уже с изменениями, которые позволили проекту хотя бы запускаться.

Если это не ваш случай, то тот-же Subversion значительно удобнее. Следуйте принкипу KIS! Keep It Simple!

>>Или попробуй поработать так, чтобы до определенного момента результатов твоей работы никто не видел.

> Делаешь форк отдельногой ветки и вперёд

Расскажи подробнее о том, как именно сделать "форк отдельногой ветки".

> BTW, я с вами(хотя могу и ощибаться) уже кажется спори по этому поводу

Возможно (кстати, можно на "ты" :))

> доказывая, что в 99% случаев достаточно к примеру Subversion.

Видимо, я из оставшегося 1%

> Следуйте принкипу KIS! Keep It Simple!

DVCS следуют этому принципу гораздо строже, чес централизованные. Ты ни разу не отвечал, почему нельзя сделать "svn ci", когда нет связи с сервером?

это надо понимать bazaar-ng переименовали? штука хорошая, но принципиальной ценности децентрализованных vcs-ок для групповой работы, я признаться так и не вкурил..

Какая же она новая? Релиз ее да. Но не новая, факт.

Если все трудятся в одном здании и домой работы не берут, то можно обойтись и перфорсом.

>Расскажи подробнее о том, как именно сделать "форк отдельногой ветки".

>Ты ни разу не отвечал, почему нельзя сделать "svn ci", когда нет связи с сервером?

Проблемы могут быть неприятными, но легко решаемы.

Локальная копия есть? есть. Делаем svn import - и опа, подняли локальный мини-репозиторий. В нём поработали, сохранили несколько версий. Работы нашей никто не видит :)

Затем, когда появилась надобность добавить свои наработки в общий репозиторий или же поднялся сервер из дауна, делаем svn diff 1:HEAD, и затем из начальной рабочей копии svn merge. Ну вот и всё :).

> Делаем svn import - и опа, подняли локальный мини-репозиторий. В нём поработали, сохранили несколько версий. Работы нашей никто не видит :)

> Затем, когда появилась надобность добавить свои наработки в общий репозиторий или же поднялся сервер из дауна, делаем svn diff 1:HEAD, и затем из начальной рабочей копии svn merge. Ну вот и всё :).

То есть ты вручную эмулируешь работу DVCS. Удачи тебе в этом достойном и благородном деле :D (кстати, специально для тебя - всё, о чем ты говоришь, давно уже автоматизировано, google svk, google submaster).

Хотя... у меня есть еще один вопрос: предположим, во время разработки твоего форка в транке появилось что-то новое, что ты хотел бы влить в свой форк. Твои действия?

>Уже черти сколько времени живёт

+1, базар-вокзал не новая -- уже версия 1.0 давно вышла =)

> народ на велосипеды чегойта тянет зверски

Хотим много велосипедов хороших и разных (с)

> принципиальной ценности децентрализованных vcs-ок для групповой работы, я признаться так и не вкурил..

принципиально: легкость порождения новых веток, легкость сливания изменений между ЛЮБЫМИ ветками (необязательно родственными). Можно, как говорилось, сделать кучу репозиториев в том же svn, сливать скриптами перекачки или svk , но это будет "закат солнца вручную" и ручное разруливание номеров ревизий в разных репозиториях/перенумерование и т.п.

например, в git -- есть удобная команда rebase, которая сама посчитает дельту ветки от базовой версии, и донакатит эти изменения в ствол.

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

или наоборот, подгрузить изменения из форка в ствол, сохранив свои измененения в форке и обновления в стволе.

>Расскажи подробнее о том, как именно сделать "форк отдельногой ветки".
??? А что непонятно? как branch создать?

>Видимо, я из оставшегося 1%
Запросто. Я же не писал, что никто не дожен им пользоваться.
Особенн актуально DVCS в open source проектах.

>DVCS следуют этому принципу гораздо строже, чес централизованные.
как минимум на одно действие больше, когда проталкиваешь изменения на другой сервер.

>Ты ни разу не отвечал, почему нельзя сделать "svn ci", когда нет связи с сервером?
Нет ни разу не отвечал. Я думаю, это потому, что никто не страшивал :)

> как минимум на одно действие больше, когда проталкиваешь изменения на другой сервер.

Сообщаю: bzr умеет делать checkout и commit точно так же, как и svn.

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

>или наоборот, подгрузить изменения из форка в ствол, сохранив свои измененения в форке и обновления в стволе.

А что за проблемы с этим могу возникнуть? Я только так и работаю и других заствляю. Это стандартный цикл разработки:
1.Fork a branch
2.change
3.merge changes to trunk.

Так-же делаются и бэкпорты изменений из девелоперской ветки в стредыдущие стабильные релизы.

Это, основы. Хотя, вскормленные на MS VSS, могут этого не знать, не подозревая о ущербности инструмента.

Как, там.... Вот девочка, молодец, пришла, песенку спела, хотя никто и не просил...

>>или наоборот, подгрузить изменения из форка в ствол, сохранив свои измененения в форке и обновления в стволе.

>А что за проблемы с этим могу возникнуть?

Мне бы последовательность действий увидеть, а потом сравним, где "на одно дейстыие больше" :D

> Я только так и работаю и других заствляю

>1.Fork a branch

>2.change

>3.merge changes to trunk.

Ну это стандартная практика... гораздо более естественная в DVCS, чем в централиованных VCS. Но у нас была задача "форнуть удаленный бранч" и довесок к ней "влить в форкнутый бранч изменения с транка". Как ее решить в случае SVN? 8)

Если все разработчики сидят в одной конторе, а сервер стоит в соседней комнате, тогда можно обойтись и без DVCS. А что делать, если ты опенсорсный разработчик и хочешь, например, сделать фичу для какой-нибудь мозиллы? Щас прям тебе все кинутся на сервере заводить новую ветку. Потом, лазить на сервер за каждым логом или диффом — это неудобно. Потом, как тебе сказали, центральный сервер может быть недоступен по разным причинам. Вот за этим всем и надо DVCS.

>Ну это стандартная практика... гораздо более естественная в DVCS, чем в централиованных VCS. Но у нас была задача "форнуть удаленный бранч" и довесок к ней "влить в форкнутый бранч изменения с транка". Как ее решить в случае SVN? 8)
И... в чём проблема? Барнч можно ветвить сколько хочешь, хоть миллион раз...
В Subversion все ветки равноправны и разделение на trunk/brunch/release условно.
Точно так же не понимаю, что за проблема с merge хоть в trunk хоть в branch. Есть десятки, если не сотни Merge tools. Используй любой.

Это вы со мной соглашаетесь и поддерживаете или спорите и негодуете?
Что-то не пойму...

> И... в чём проблема?

В трудоемкости, поэтому я и прошу список команд, хотя бы примерный. Потому что нет никаких проблем написать, скажем, компилятор на ассемблере, но так уже давно никто не делает.

> В Subversion все ветки равноправны и разделение на trunk/brunch/release условно.

Я пользователь SVN с версии 0.14 по (примерно) 1.2.x

> Это вы со мной соглашаетесь и поддерживаете или спорите и негодуете? Что-то не пойму...

Мне показалось, что вы не понимаете, зачем нужны DVCS, и я в меру своего разумения пытаюсь втолковать.

Это вы со мной соглашаетесь и поддерживаете или спорите и негодуете?
Что-то не пойму...

>Если все разработчики сидят в одной конторе, а сервер стоит в соседней комнате, тогда можно обойтись и без DVCS
Я как правило даже не знаю в одно ли со мной стране стоит сервер, при работе с Subversion.

>А что делать, если ты опенсорсный разработчик и хочешь, например, сделать фичу для какой-нибудь мозиллы?
Проектов соизмеримых с мозиллой 1 на 100000 мелких, гдже это не нужно.

>Потом, лазить на сервер за каждым логом или диффом — это неудобно.
??? Почему?

>Потом, как тебе сказали, центральный сервер может быть недоступен по разным причинам.
Хм... Спорное преимущество. Это, типа носить парашют всю жизнь за плечами, на случай если упадёшь с нескольких километров высоты... :)

А... а я думал, вы мне поддакиваете. Просто я про это писал неско посотов выше.

> Проектов соизмеримых с мозиллой 1 на 100000 мелких, гдже это не нужно.

Как ни странно, и для мелких поделок DVCS оказываются удобнее: рабочая копия сама себе репозиторий, не нужно заводить его в отдельном месте.

Другой забавный пример: если вы внезапно захотите использовать систему контроля версий для каталога /etc, вы сможете без фокусов сделать его рабочей копией репозитория SVN на живой машине?

>В трудоемкости, поэтому я и прошу список команд, хотя бы примерный. Потому что нет никаких проблем написать, скажем, компилятор на ассемблере, но так уже давно никто не делает.
1.Запустить свой любимый фронтэнд для Subversion.
2.Открыть нужную ветку
3.из контекстного меню выбрать "Brunch"
4.указать новый путь

Merge:
1.Запустить свой любимый фронтэнд для Subversion.
2.Выбрать revisions для синхронизации(из какой в какую)
3.Пройтись с merge там где обнаружены конфликты.

> Расскажите мне неразумному, а зачем нужна децентрализованная системы > управления версиями?

Часовое выступление линуса на тему DVCS vs CVCS: http://youtube.com/watch?v=4XpnKHJAok8

Если тако случится, что "внезапно захотите использовать систему контроля версий для каталога /etc" То я позвоню 911 и за мной приедут санитары.
Я пограммист а не админ, кроме того, я не вижу причин, почему я не могу поннять локальную копию SVN на своей машине, за время которое пондобится санитарам, чтобы доехать до моего дома(~5мин). Я ведь не собираюсь делать propagate моего /etc ?

Здесь какое-то непонимание:

>>Или попробуй поработать так, чтобы до определенного момента результатов твоей работы никто не видел.

> Делаешь форк отдельногой ветки и вперёд

Ответа на "форк отдельной ветви" ты не дал, его дал JackYF:

> Локальная копия есть? есть. Делаем svn import - и опа, подняли локальный мини-репозиторий. В нём поработали, сохранили несколько версий. Работы нашей никто не видит :)

После чего следует естественный вопрос о вливании изменений с транка в полученный svn import форк. Вся соль вопроса в том, что теперь у нас 2 SVN-репозитория, независимых, друг о друге ничего не знающих. Единственный способ обмена - через патчи (а SVN даже не поддерживает git-патчи, как Mercurial). Насколько я вижу, твое решение относится к единственному репозиторию, или сильно умным фронтендам, умеющим работать с несколькими репозиториями (если они настолько умные, они уже DVCS сами по себе).

> Если тако случится, что "внезапно захотите использовать систему контроля версий для каталога /etc" То я позвоню 911 и за мной приедут санитары.

Это такой тонкий слив? :P

> Я пограммист а не админ, кроме того, я не вижу причин, почему я не могу поннять локальную копию SVN на своей машине.

Кто там говорил про лишний этап? Зачем отдельный репозиторий, если она не нужен?

> Я ведь не собираюсь делать propagate моего /etc ?

Обождите propagate. Сначала давайте последовательность команд, которая /etc превратит в рабочую копию svn.

Я просто напросто не вижу смысла в тех лишних телодвижениях, которые предложил JackYF. При работе с Subversion всегда работаю с центральным репозитарием.

Я ведь не противник DVCS и пользовался как минимум Mercurial и Bikeeper. Просто для большинства(не всех) проектов с которыми Я ЛИЧНО имел дело, использование DVCS неоправдано. Как я уже писал, оно(для меня лично) оправдано при многоуровневом коммите, что есть редкость даже очень крупных проектов.