distributed vcs
Коллеги используют git для разработки продукта, потом экспортируют в CVS, лелеют надежду перевести центральный репозиторий на git.
Коллеги используют git для разработки продукта, потом экспортируют в CVS, лелеют надежду перевести центральный репозиторий на git.Такие примеры и я знаю. Вопрос "зачем?"
Очевидно, удобнее.
Я кроме git практически ничем другим не пользовался, поэтому не могу сравнить.
Я кроме git практически ничем другим не пользовался, поэтому не могу сравнить.
git умеет rebase, cherry-pick, 2-ух фазный коммит крайне удобен...
git умеет rebase, cherry-pick, 2-ух фазный коммит крайне удобен...Чего такого особенного например в rebase?
http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Merc...
Ну вот отсюда видно что кроме Git еще всякие есть системы. И из этого списка Mercurial (который я в итоге использую) выглядит симпатичнее.
А у Git'a есть неободимость регулятной перепаковки репозитория. И слишком много команд. В общем и из distributed систем вряд ли лучший вариант.
Но дело в другом: "чем git лучше svn"?
Для чего тебе так удобен двухфазный коммит?
Distributed VCS - пока баловство, тулзами не поддерживается, преимущества не очевидны, ручной работы по интеграции не отменяют.
У нас SVN покрывает 99% всех потребностей. Все-таки понятная и простая модель с тупо инкрементируемым Revision Number делает свое дело.
У нас SVN покрывает 99% всех потребностей. Все-таки понятная и простая модель с тупо инкрементируемым Revision Number делает свое дело.
>Distributed VCS - пока баловство
Попробуй организовать работу сотен разработчиков в SVN
Попробуй организовать работу сотен разработчиков в SVN
Попробуй организовать работу сотен разработчиков в SVNПопробуй организовать работу сотен разработчиков в git
Родной,
~/src/linux-2.6 $ git shortlog -n -s|wc -l
5457
Это количество разработчиков за 4 года.
~/src/linux-2.6 $ git shortlog -n -s|wc -l
5457
Это количество разработчиков за 4 года.
Мама твоя тебе родная.
http://hgbook.red-bean.com/read/collaborating-with-other-peo... :
Это касательно разработки ядра. "Организована" она очень слабо. И потрудись плз перечитать первый пост — вопрос о коммерческом ПО.
http://hgbook.red-bean.com/read/collaborating-with-other-peo... :
The development of the Linux kernel has a shallow hierarchical structure, surrounded by a cloud of apparent chaos. Because most Linux developers use git, a distributed revision control tool with capabilities similar to Mercurial, it's useful to describe the way work flows in that environment; if you like the ideas, the approach translates well across tools.
At the center of the community sits Linus Torvalds, the creator of Linux. He publishes a single source repository that is considered the “authoritative” current tree by the entire developer community. Anyone can clone Linus's tree, but he is very choosy about whose trees he pulls from.
Linus has a number of “trusted lieutenants”. As a general rule, he pulls whatever changes they publish, in most cases without even reviewing those changes. Some of those lieutenants are generally agreed to be “maintainers”, responsible for specific subsystems within the kernel. If a random kernel hacker wants to make a change to a subsystem that they want to end up in Linus's tree, they must find out who the subsystem's maintainer is, and ask that maintainer to take their change. If the maintainer reviews their changes and agrees to take them, they'll pass them along to Linus in due course.
Individual lieutenants have their own approaches to reviewing, accepting, and publishing changes; and for deciding when to feed them to Linus. In addition, there are several well known branches that people use for different purposes. For example, a few people maintain “stable” repositories of older versions of the kernel, to which they apply critical fixes as needed. Some maintainers publish multiple trees: one for experimental changes; one for changes that they are about to feed upstream; and so on. Others just publish a single tree.
This model has two notable features. The first is that it's “pull only”. You have to ask, convince, or beg another developer to take a change from you, because there are almost no trees to which more than one person can push, and there's no way to push changes into a tree that someone else controls.
The second is that it's based on reputation and acclaim. If you're an unknown, Linus will probably ignore changes from you without even responding. But a subsystem maintainer will probably review them, and will likely take them if they pass their criteria for suitability. The more “good” changes you contribute to a maintainer, the more likely they are to trust your judgment and accept your changes. If you're well-known and maintain a long-lived branch for something Linus hasn't yet accepted, people with similar interests may pull your changes regularly to keep up with your work.
Reputation and acclaim don't necessarily cross subsystem or “people” boundaries. If you're a respected but specialised storage hacker, and you try to fix a networking bug, that change will receive a level of scrutiny from a network maintainer comparable to a change from a complete stranger.
To people who come from more orderly project backgrounds, the comparatively chaotic Linux kernel development process often seems completely insane. It's subject to the whims of individuals; people make sweeping changes whenever they deem it appropriate; and the pace of development is astounding. And yet Linux is a highly successful, well-regarded piece of software.
Это касательно разработки ядра. "Организована" она очень слабо. И потрудись плз перечитать первый пост — вопрос о коммерческом ПО.
тулзами не поддерживаетсякакими именно? чего не хватает?
>"Организована" она очень слабо.
Это твоё личное мнение? На чём оно основано?
Разве есть другой проект с таким количеством разработчиков, чтобы можно было сравнить?
It just works.
Кстати, не могу согласиться с предпоследними двумя абзацами.
>вопрос о коммерческом ПО.
Ты спросил про git и сотни разработчиков, получил ответ.
Разница между открытым и коммерческим продуктом в том, что руководитель не может приказать, он может просить, рекомендовать и отказывать, и есть люди, которые приходят и уходят. Есть ли разница в сложности собирания работы всех участников вместе в коммерческом и открытом проектах?
Кстати, Linux вполне себе коммерческое ПО, в том смысле, что более 80% (а именно самые активные) разработчиков получают за это зарплату.
Это твоё личное мнение? На чём оно основано?
Разве есть другой проект с таким количеством разработчиков, чтобы можно было сравнить?
It just works.
Кстати, не могу согласиться с предпоследними двумя абзацами.
>вопрос о коммерческом ПО.
Ты спросил про git и сотни разработчиков, получил ответ.
Разница между открытым и коммерческим продуктом в том, что руководитель не может приказать, он может просить, рекомендовать и отказывать, и есть люди, которые приходят и уходят. Есть ли разница в сложности собирания работы всех участников вместе в коммерческом и открытом проектах?
Кстати, Linux вполне себе коммерческое ПО, в том смысле, что более 80% (а именно самые активные) разработчиков получают за это зарплату.
Для чего тебе так удобен двухфазный коммит?Мои изменения сохранить нужно и быстро. git это делает даже если удалённый репозитарий (с кем я синхронизирован) изменился. А CVS - нет.
какими именно? чего не хватает?MS visual studio не поддерживает
А сценария применения для работы не вижу.чтоб только писать код в едином бранче то git действительно не нужен
чтоб только писать код в едином бранче то git действительно не нуженВ svn есть какая-то проблема с бранчами?
А для каких ситуаций нужен? (Если мы рассматриваем не "организацию" типа "сижу жду патча и знать не знаю что там вокруг происходит" как я ядре Linux.) Пример организации какой-нибудь?
Теоретически с dvcs можно проще организовать "многосутпенчатый приезд коммита в репозиторий", может быть можно по-другому организовать code review, тестирование и т.п.
В итоге получается что git используют "потому что модно".
MS visual studio не поддерживает
There is also a Visual Studio plugin to use git from Visual Studio.
Если да, то чем она лучше svn?Использую git поверх svn, потому что более удобно, хотя вся разработка и ведется в одной ветке. Пока
Удобства следующие:
1. Можно изменить всю историю, пока не залил ее на сервер. Исправить ошибки в логе. Долить забытые файлы. И т.д.
2. Какая бы скоростная не была связь с сервером, обработка истории, когда она лежит на локальном ЖД, идет быстрее. git log, git blame - все делается быстрее, чем просто через svn.
3. Возможность быстро сделать git stash и заняться другими вещами.
Конечно, все эти вещи можно было бы и на основе svn сделать, просто улучшив клиент, но пока этого никто не сделал. Что касается веток в svn, то git через svn тут гораздо более удобен по следующей причине: если в рабочей копии лежит весь репозиторий, а не trunk или какая-то из веток, то добавление любой ветки ведет к увеличению хранимого репозитория на диске на очень много. Грубо говоря, если у тебя 10 примерно одинаковых веток, то в git это будет занимать одну ветку плюс чуть-чуть (на диске а с свн каждая ветка свой полный размер.
В svn есть какая-то проблема с бранчами?В svn нет бранчей и мёрджей в смысле git. есть только (пусть и быстрая) операция копирования файлового поддерева. про svn-мердж я лучше промолчу.
если в рабочей копии лежит весь репозиторий, а не trunk или какая-то из ветокзачем так делать?
а с свн каждая ветка свой полный размер.афаир, при копировании в svn всё-таки ничего не копируется, только ссылки делаются. так что новый branch после создания занимает ~0.
Он про файлы в рабочей копии: когда уже сделаешь checkout, на сервере ясен пень лежат только diff'ы
Очевидно, чтобы быстро переключаться между бранчами.
С svn'ом это тоже довольно быстро.
открой секрет
открой секретsvn switch, надо думать, быстрее я не знаю способа.
Да, его, естественно, и имел в виду.
Понимаю, что всем запросам не угодишь, не призываю никого юзать один svn, просто не стоит так сгущать краски =)
Понимаю, что всем запросам не угодишь, не призываю никого юзать один svn, просто не стоит так сгущать краски =)
Использую git так же как описал (центральный репозиторий svn, локально на рабочей машине - git)
Кроме того, git - это самый удобный способ для миграции CVS-репозиториев, т.к. в git нормальная поддержка branches. Людей, активно пользовавшихся бренчами для отдельных файлов в CVS, перевести на SVN с его недобренчами - малореально, а вот на git - легко.
И ещё держу в git локальные зеркала CVS-репозиториев некоторых open source проектов - так с ними гораздо удобнее работать.
Единственное что - под windows работаю с git исключительно в консоли bash под cygwin, т.к. клиентов аналогичных TortoiseSVN под Windows пока нет. Собственно это вижу единственным минусом git по сравнению с svn (если большинство программистов работают под Windows). Всё остальное - сплошные плюсы.
Кроме того, git - это самый удобный способ для миграции CVS-репозиториев, т.к. в git нормальная поддержка branches. Людей, активно пользовавшихся бренчами для отдельных файлов в CVS, перевести на SVN с его недобренчами - малореально, а вот на git - легко.
И ещё держу в git локальные зеркала CVS-репозиториев некоторых open source проектов - так с ними гораздо удобнее работать.
Единственное что - под windows работаю с git исключительно в консоли bash под cygwin, т.к. клиентов аналогичных TortoiseSVN под Windows пока нет. Собственно это вижу единственным минусом git по сравнению с svn (если большинство программистов работают под Windows). Всё остальное - сплошные плюсы.
клиентов аналогичных TortoiseSVN под Windows пока нетhttp://code.google.com/p/tortoisegit/
А в линуксе с git чем работаешь? Я в командной строке, только git difftool иногда с kdiff3 использую. Посоветуй, если есть что удобное, кроме стнадартного git'овского gitk.
или, как я уже заметил, http://code.google.com/p/gitextensions/
А в линуксе с git чем работаешь? Я в командной строкеработаю с git только в командной строке,
gitk почему-то сразу не особо понравился, не помню уже чем
про svn-мердж я лучше промолчу.Очень ловко
Ты имеешь в виду svn версии ниже 1.5 и проблему с переименованием файлов? Чем еще не устраивают бранчи и мерж в svn?
что ты хочешь доказать? что в svn всё можно сделать? не спорю. всё можно сделать и вообще без vcs.
но мне быстрее и проще использовать для этого нормальную vcs где не нужно совать руки по локоть в жопу только чтоб найти бранч-поинт.
но мне быстрее и проще использовать для этого нормальную vcs где не нужно совать руки по локоть в жопу только чтоб найти бранч-поинт.
В общем по результатам треда меня удивила популярность git (на мой взгляд не лучшая dvcs).
Ну и видно что главной разницей — распределенностью — никто особенно и не пользуется. А казалось бы тут можно наворотить разных workflow.
Касательно двухфазного коммита: непонятен механизм "как заметить что не все закоммитил". Вижу одно применение: человек выучил команду commit, а не выучил status.
Про мерджи: иногда (!) напрягает что переименование файлов не мержится (svn 1.4). В остальном не вижу разницы.
Скорость svn log как-то никогда не напрягала.
"git поверх cvs" — понятно cvs та еще прелесть, не думал что кто-то осознанно пользуется.
Лично мне dvcs удобно чтобы работать когда нет инета. На практике такого практически не бывает.
Такое вот имхо.
Ну и видно что главной разницей — распределенностью — никто особенно и не пользуется. А казалось бы тут можно наворотить разных workflow.
Касательно двухфазного коммита: непонятен механизм "как заметить что не все закоммитил". Вижу одно применение: человек выучил команду commit, а не выучил status.
Про мерджи: иногда (!) напрягает что переименование файлов не мержится (svn 1.4). В остальном не вижу разницы.
Скорость svn log как-то никогда не напрягала.
"git поверх cvs" — понятно cvs та еще прелесть, не думал что кто-то осознанно пользуется.
Лично мне dvcs удобно чтобы работать когда нет инета. На практике такого практически не бывает.
Такое вот имхо.
что ты хочешь доказать?"доказать" я ничего не хочу. Я для себя понял что dvcs ничего в процессе коммерческой разработки не меняет. Это все что мне было нужно узнать :-)
Пожалуй отсутствие двухфазного комита меня напрягает больше всего, когда приходится пользоваться svn. Например, есть какие-то хорошие изменения, которые пока не готовы для общего репозитария. Чтобы их довести, нужно сделать неочевидную вещь, которая может не получиться. Что делать? Неужели бранч?
Еще пример, перед комитом в общий репозитарий хочется почистить код, убрать из него какую-то отладку, упростить diff для читабельности. И тут - раз - и код перестает работать. Я откачу до локального комита, а что делают любители svn? Бэкапы ручками? Опять бранчи в рабочей копии?
Еще пример, перед комитом в общий репозитарий хочется почистить код, убрать из него какую-то отладку, упростить diff для читабельности. И тут - раз - и код перестает работать. Я откачу до локального комита, а что делают любители svn? Бэкапы ручками? Опять бранчи в рабочей копии?
для жонглирования патчами я активно пользуюсь stgit как более функциональный аналог git shash.
всё никак не соберуть попробовать mercurial, там вроде-бы patchset является встроенной сущностью
и можно одной командой маскировать набор патчей в сэте не меняя их порядок, например временно выкидывая дебажные патчи из сета.
всё никак не соберуть попробовать mercurial, там вроде-бы patchset является встроенной сущностью
и можно одной командой маскировать набор патчей в сэте не меняя их порядок, например временно выкидывая дебажные патчи из сета.
patchset является встроенной сущностьюНу почти. Это расширение которое есть в дистрибутиве и которое надо "включить".
http://www.selenic.com/mercurial/wiki/MqExtension
Неужели бранч?в чем проблема? Так и делают.
Для этого есть svk. Вот только плагина к eclipse у него нет, поэтому им не пользуюсь.
Ты перепутал, svk - distributed, их в этом треде принято ругать 
А его можно сделать локально? Насколько я помню, в стародавние времена svn не умел несколько операций над одним файлом держать в рабочей копии. Скажем, создать файл, отредактировать, смержить, удалить.Неужели бранч?в чем проблема? Так и делают.
Ну и синтаксис команды merge несколько ээээ..., постоянно нужно какие-то пути указывать, ревизии. Если над коммитом работать, скажем, 2 часа, меня бы напрягло с этим возиться.
> Ну и синтаксис команды merge несколько ээээ..., постоянно
> нужно какие-то пути указывать, ревизии. Если над коммитом
> работать, скажем, 2 часа, меня бы напрягло с этим возиться.
А что, что-то умеет читать мысли и сливать тексты самостоятельно?
Если тебе не нравится делать это за одно действие, никто не
мешает проделать diff и patch руками.
---
...Я работаю антинаучным аферистом...
> нужно какие-то пути указывать, ревизии. Если над коммитом
> работать, скажем, 2 часа, меня бы напрягло с этим возиться.
А что, что-то умеет читать мысли и сливать тексты самостоятельно?
Если тебе не нравится делать это за одно действие, никто не
мешает проделать diff и patch руками.
---
...Я работаю антинаучным аферистом...
Причем тут телепаты? Какие diff и patch? О чем ты вообще?
В моем сообщении речь идет подготовке комита в несколько шагов. Мерж здесь если и нужен, то тривиальный, и только если vcs вынуждает использовать для этой задачи бранчи.
И я вовсе не против мержа. Я за! Двумя руками. Мне просто не нравится все время указывать длинные пути до бранчей и номера ревизий там, где, в некоторых vcs, достаточно обойтись коротким именем.
В моем сообщении речь идет подготовке комита в несколько шагов. Мерж здесь если и нужен, то тривиальный, и только если vcs вынуждает использовать для этой задачи бранчи.
И я вовсе не против мержа. Я за! Двумя руками. Мне просто не нравится все время указывать длинные пути до бранчей и номера ревизий там, где, в некоторых vcs, достаточно обойтись коротким именем.
Какие diff и patch? О чем ты вообще?А как же основное тождество svn: merge=diff+patch. Хотя ты этого похоже не знаешь, поэтому тебе и трудно работать с merge.
> Причем тут телепаты? Какие diff и patch? О чем ты вообще?
(cd there && cvs diff -r 6.66) | patch; cvs ci -m 'Do it!'
Номера ревизий тебе так и так придётся указывать, или как ты
предполагаешь VCS узнавать, что именно ты хочешь сливать?
> Мне просто не нравится все время указывать длинные пути до
> бранчей и номера ревизий там, где, в некоторых vcs, достаточно
> обойтись коротким именем.
Каким? Именем разницы между двумя соседними версиями?
Это какой-то очень простой случай.
---
...Я работаю антинаучным аферистом...
(cd there && cvs diff -r 6.66) | patch; cvs ci -m 'Do it!'
Номера ревизий тебе так и так придётся указывать, или как ты
предполагаешь VCS узнавать, что именно ты хочешь сливать?
> Мне просто не нравится все время указывать длинные пути до
> бранчей и номера ревизий там, где, в некоторых vcs, достаточно
> обойтись коротким именем.
Каким? Именем разницы между двумя соседними версиями?
Это какой-то очень простой случай.
---
...Я работаю антинаучным аферистом...
Большая ошибка.
Merge = F(diff, patch).
Хотя ты этого похоже не знаешь, поэтому и не понимаешь преимуществ git.
Точный вид функции F оставляю в качестве домашнего задания.
Merge = F(diff, patch).
Хотя ты этого похоже не знаешь, поэтому и не понимаешь преимуществ git.
Точный вид функции F оставляю в качестве домашнего задания.
Это только если конфликты есть, так тогда и руками возиться надо будет.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
Номера ревизий тебе так и так придётся указывать, или как тыНу она типа знает общего предка двух состояний, текущего и второго, которое я указываю. Как правило, у этого второго есть короткое human readable имя - это HEAD одного из бранчей.
предполагаешь VCS узнавать, что именно ты хочешь сливать?
Merge = F(diff, patch).Я говорил про svn, но ты похоже не умеешь читать и именно поэтому начал писать про git.
Хотя ты этого похоже не знаешь, поэтому и не понимаешь преимуществ git.
Первое домашнее задание, которое ты выдал?
> Ну она типа знает общего предка двух состояний, текущего и
> второго, которое я указываю. Как правило, у этого второго есть
> короткое human readable имя - это HEAD одного из бранчей.
Subversion же предоставляет тебе возможность указывать такое, разве нет?
Это даже CVS умеет: cvs up -j branch-name
---
...Я работаю антинаучным аферистом...
> второго, которое я указываю. Как правило, у этого второго есть
> короткое human readable имя - это HEAD одного из бранчей.
Subversion же предоставляет тебе возможность указывать такое, разве нет?
Это даже CVS умеет: cvs up -j branch-name
---
...Я работаю антинаучным аферистом...
Хз, я в хелпе вижу только синтаксис с URL.
Номера ревизий тебе так и так придётся указывать, или как тыпредполагаешь VCS узнавать, что именно ты хочешь сливать?предлагаю сделать команду mergeall, которая делает merge -r M:N, где M — это (N из предыдущей выполненной команды mergeall)+1, а N — максимальное возможное.
попробуй хотя бы так для начала:
Это будет хорошим началом знакомства с SVN.
svn merge -c 450 ../my-local-branch
Это будет хорошим началом знакомства с SVN.
svn merge -c 450 ../branches/my-local-branchИ только если ты находишься в транке, иначе пути еще удлиняются, а главное - меняются от команды к команде. Спору нет, всего лишь мелкое неудобство, но они накапливаются.
Ага. То есть про working copy ты не слышал. Это команда накладывает изменения из указанного working copy в текущий, причем совершенно неважно, бранч или транк.
Как бы ты все верно написал (кроме того, что про working copy я конечно же слышал и я вроде все верно пишу. А причем тут это?
Оставить комментарий
pilot
Используете ли вы на работе какую-нибудь distributed vcs? (darcs, git, bazaar, mercurial).Если да, то чем она лучше svn?
Лично я вижу применение этим системам только в бесплатных разработках: скачал себе весь репозиторий и играйся сколько влезет. А сценария применения для работы не вижу.