Посоветуйте систему контроля версий

Недавно переехал с свн на гит. Доволен.

Система работает не так

Как работает система, по твоему?

...сценарий, который не соответствует реальному использованию DVCS

Опять же, объясни, каким ты этот сценарий видишь?

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

Workflow уже привели: работа с бранчами. Если есть множество идей или багфиксов, которые, например, требуют ревьюва сторонними лицами, то сопровождать уже пять svn-бранчей - это подвиг. А в Git подвиг - это сопровождать 50 бранчей. 10-15 git-бранчей - это норма и не особо напряжно (по сравнению с SVN).

Это намекает, что Git говно бай дизайн, но к чему ты это?

Ну почему говно? Это позволяет не про*ть то, что было единожды закоммичено. Вот я как-то доигрался с rebase и потерял несколько коммитов. Нашел и вернул обратно за 5 минут. А вот если бы git gc в промежутке сделал, то нифига бы не нашел.

Все файловые системы фрагментируюся, а git замусоривается.

Лимит по времени. Это нужно по пол-года на каждый вариант потратить.

Да ты шутишь:) По три часа на каждый для быстрого обзора и по дню для полноценного погружения.

Git и Mercurial лично мне показались практически идентичными. И по тому и по другому есть курсы в интернетах.

Как работает система, по твоему?

каким ты этот сценарий видишь?

Собственно, я вижу (== использую) два сценария. Один - «очередь патчей», в Mercurial реализуется mq, в Git тоже что-то такое есть. Как сказал Эндрю Мортон, «your output is patches». Так вот, при разработке патча (или патчей) ты делаешь много коммитов - десятки, сотни. Рекомендуется делать коммит по достижению «comfort point», что бывает достаточно часто %) Это не говоря о том, что при разработке патча N иногда возникает необходимости вернуться к патчу N-m и поправить его.

Второй - «разработка для двжущейся цели». Представь, что ты пишешь драйвер, предназначенный для включения в ядро Linux. Предположим, разработка занимает ~4 месяца (несколько релиз-циклов). Понятно, что ты начинаешь работу на ветке от версии N. Потом выходит версия N+1, твои действия? Стандартная тактика - rebase на версию N+1. И это означает, что «старая» история, с корнем в N, просто выбрасывается. Цикл может быть повторен для N+2, N+3 и т.д. В конце концов, в истории ядра от тебя будет несколько коммитов, и корнем цепочки будет последняя на тот момент ревизия ядра.

Это намекает, что Git говно бай дизайн, но к чему ты это?

Ну почему говно?

Корни сборки мусора - в ублюдочной системе хранения раннего Git.

В техническом плане разницы нет

Гит написан на божественной сишке, mercurial — на богомерзком тормозном питоне. Разница очевидна.

Затраты на все «отдельно взятое» мизерны. Это не повод не пользоваться тем, что удобнее и быстрее.

Естетственно.
Я просто писал что давно не сталкивался со случаями когда нужен DVCS(OSS проекты отдельный разговор)

О случае когда он нужен я тоже писал, правда тогда ещё как NonHuman Новая система управления версиями от разработчиков Ubuntu (комментарий)

И всё равно не вижу случая когда какой угодно тул ускорит работу в 10 раз как писал один из предыдущих ораторов.

Нашёл Debugging around me и его блог. http://blog.gamedeff.com/
не нашёл в нём ничего интересного :(

Нашёл Debugging around me и его блог. http://blog.gamedeff.com/

17th May 2012, 09:25 am by CEMEH

Хтоето?

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

Вы наверное про бранчи не слыхали.
Рекомендую к изучению.

Это то, что выходит на запрос «презентация Люковского»

Кхм. Ты не знаешь, кто такой Марк Люковски? Впрочем, я выше дал ссылку на презентацию.

сопровождать уже пять svn-бранчей - это подвиг.

А в Git подвиг - это сопровождать 50 бранчей. 10-15 git-бранчей - это норма и не особо напряжно

У вас что-то не так с процессом разработки.
Не могу себе представить ситуация, когда я роаботаю более чем с 2 бранчами.

Кстати, а в чём проблема SVN? Почему требуется героизм?

спасибо, нашёл. почитаю.

А в Git подвиг - это сопровождать 50 бранчей. 10-15 git-бранчей - это норма и не особо напряжно (по сравнению с SVN)

10-15 git-бранчей - это норма

Либо у тебя голова шире плеч, либо под «сопровождением» ты понимаешь какую-то мелкую механическую работу.

TortoiseGit + msysgit

Но, пардон, о каких бранчах может идти речь, если: «Даже Merge мало кто пользуется.» ?!

Но, пардон, о каких бранчах может идти речь, если: «Даже Merge мало кто пользуется.» ?!

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

Ни разу не видел в крупной конторе ни Гит ни Меркуриал ни Базар. Только в мелких шарашках и в Open Source проектах.

И это очередное подтверждение того, что в больших конторах правят маркетологи, а не архитекторы.

Отсутствие гребаных .cvs /.svn в каждой папке, и возможности тривиальным перемещением папки сломать локальный репозиторий начисто.

В subvesion уже достаточно давно .svn только в корне.

И это очередное подтверждение того, что в больших конторах правят маркетологи, а не архитекторы.

Если бы правили маркетологи, то все бы программировали на RybyOnRails и Scala так как о ни большу шума а VCS бы каждый год меняли в соответствии с мнением ЛОРа.

Вы вообще где такую идею раскопали что в больших конторах маркетологи имеют хоть какое-то отношение IT?

Вы вообще где такую идею раскопали что в больших конторах маркетологи имеют хоть какое-то отношение IT?

А вы перечитайте еще раз мое сообщение и сообщение, на которое я ответил.

Либо у тебя голова шире плеч, либо под «сопровождением» ты понимаешь какую-то мелкую механическую работу.

Сопровождение - поддержка бранчей в актуальном состоянии относительно основной ветки разработки. Да, там как и мелкая механическая работа, так и работа для «головы шире плеч» на клинические случаи тотальных конфликтов при ребайзе или мерже. Но тотальные конфликты порождаются тотальными же изменениями в бранчах, а таких бранчей на счастье не так уж и много случается.

В любом случае, основной месседж: работа с бранчами в git на порядок легче работы с бранчами в svn.

В любом случае, основной месседж: работа с бранчами в git на порядок легче работы с бранчами в svn.

Какая версия SVN имеется в виду? Мерж в Git ничего особенного с точки зрения алгоритмов из себя не представляет, просто у этих алгоритмов входные данные более точные, чем у SVN времен 1.0-1.6 (в более поздних должен уже быть merge tracking).

Слив можно, как я понимаю, засчитывать.

А что это?

Какая версия SVN имеется в виду? Мерж в Git ничего особенного с точки зрения алгоритмов из себя не представляет, просто у этих алгоритмов входные данные более точные, чем у SVN времен 1.0-1.6 (в более поздних должен уже быть merge tracking).

В принципе, мой опыт общения с svn примерно на 1,6 версии и заканчивается. В версии 1.7, насколько доходила до меня информация, были учтены многие аспекты. Но всё равно, хоть и «ложечка нашлась, но осадок остался»: чисто субъективно осталась неприязнь к svn (может, даже не имеющая объективных корней с учётом реалий).

P.S. Корпоративный стандарт - svn, но с успехом его обхожу при помощи git-svn - костыля. Правда, сейчас волею судеб приходится работать с Perforce - значительно лучше, чем svn: лучше в плане скорости работы с удалённым сервером, но в целом хуже, чем всё тот же git. Впрочем, не исключаю опять субъективизм, ибо от Perforce в настоящее время нужны только простейшие операции без углубленных знаний, а с git приходится сталкиваться наиболее часто.

googlecode с mercurial, и тот же bitbucket

TortoiseGit же, если он сравним по функциональности с TortoiseHg, который прям-таки луч света в оффтопике.

Ни разу не видел в крупной конторе ни Гит ни Меркуриал ни Базар. Только в мелких шарашках и в Open Source проектах.

сейчас во всех крупных конторах (google, amazon, даже ms) стараются иметь возможность локально использовать git, и только для окончательного увековечивания файлов использовать бридж к perforce или svn, whatever.

Git

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

Это заблуждение, а не предубеждение.