Выбор системы контроля версий

Да любая современная DVCS подойдет. Я бы посоветовал Mercurial, если у тебя нет особо длинных имен файлов :)

А что скажет сообщество по поводу darcs? Единственное, что смущает это то, что символические линки не поддерживаются.

> Я бы посоветовал Mercurial, если у тебя нет особо длинных имен файлов

Особо длинные это сколько? Как там с поддержкой emacs?

> А что скажет сообщество по поводу darcs?

Я использовал только DARCS1, и он жрал память в три горла и временами просто уходил в себя. Говорят, в DARCS2 это починили. Вообще система интересная, но слишком гибкая - для одного человека overkill, для группы просто боязно использовать :) И еще в DARCS1 было плохо с бинарями.

>> Я бы посоветовал Mercurial, если у тебя нет особо длинных имен файлов

> Особо длинные это сколько?

В случае uppercase-имен латиницей - примерно 1/2 от максимальной длины, которую допускает используемая ФС; в случае русских имен - 1/3.

> Как там с поддержкой emacs?

Я emacs не пользуюсь, но в в дистрибутиве Mercurial зачем-то есть mercurial.el :) Кроме того, насколько я знаю, модерновые DVCS поддерживаются каким-то специальным модулем (DVC.el, кажется).

И еще... я бы категорически рекомендовал прогерам использовать Mercurial с mq, насчет физиков - ХЗ.

Где можно почитать тюьториал для затравки по mercurial?

> в) хотелось бы обойтись без специально поднятых сервисов, как cvs или svn (я знаю, что там можно обойтись и без этого). Хотелось бы чтобы все настройки связанные с репозитарем хранились и распространялись вместе с рабочей копии.

в Mercurial есть веб-интерфейс hg serve. Выглядит, например, так: http://demo.openlibrary.org:9021/

> б) возможность "клонирования" рабочей директории (и всего сразу и только части). Первое чтобы сделать третью копию, например, на удалнном компьютере через ssh, а второе, чтобы дать доступ кому-то для совместной работы на каким-то проектом.

git

Всё тут: http://www.selenic.com/mercurial/wiki/ (см. Getting Started)

В HG Book вроде тоже есть tutorial. http://hgbook.red-bean.com/

> а) поддержка этой системы в emacs - лучше через стандартный Version Control (в документации в emacs 22.1.1 сказано, что он поддерживает CVS и Arch).

Я использую Mercurial для домашнего кода через VC. `C-x v v` и в путь. Вероятно, это только в CVS-версии Емакса.

> Как там с поддержкой emacs?

http://xtalk.msk.su/~ott/ru/writings/emacs-vcs/EmacsMercurial.html http://xtalk.msk.su/~ott/ru/writings/emacs-vcs/EmacsDVC.html

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

В случае с dscm обычно требуется переталкивать изменения из одного репозитория в другой. Для Mercurial можно написать хук на пост-коммит, чтобы это само делалось. Да, понятия «рабочая копия» и «репо» в общем-то совпадают.

а) svnsync чем не устроил?

б) Э? svn+ssh:// svn cp просто scp?

в) svn file:/// (svnserve -t на другой машине с зеркалом провда запустить придётся)

Поддержка в emacs давно есть и пашет.

Итого - чем не устраивает svn?

> а) svnsync чем не устроил?

Тем, что это односторонняя репликация.

> Итого - чем не устраивает svn?

Кроме написанного в топике? :)

SVN - старый корявый зверь по сравнению с Mercurial (говорю как пользователь SVN с версии 0.14 по 1.2.x).

GNU Bazaar

про mq: http://piranha.org.ua/blog/2008/05/21/poor-mans-rebase-in-mercurial/

> б) возможность "клонирования" рабочей директории (и всего сразу и только части). Первое чтобы сделать третью копию, например, на удалнном компьютере через ssh,

в Mercurial вообще-то через http, но можно настроить и ssh: http://piranha.org.ua/blog/2008/05/21/sharing-hg-repo-through-ssh/

можно и через https настроить http://sphinx.net.ru/blog/entry/howto-mercurial-repo-with-web-fastcgi-and-ssl/

>Для своей домашней машины сейчас использую Subversion. Думаю посмотреть на другую систему контроля версий

см. для Mercurial

есть расширение Convert http://www.selenic.com/mercurial/wiki/index.cgi/ConvertExtension?highlight=(c...)

http://www.selenic.com/mercurial/wiki/index.cgi/RepositoryConversion#head-804...

http://www.selenic.com/mercurial/wiki/index.cgi/SubversionToMercurialSync?hig...)

или Tailor http://www.selenic.com/mercurial/wiki/index.cgi/Tailor?highlight=(tailor)

для Git см. gitsvn

http://git.or.cz/course/svn.html

err, правильная ссылка про gitsvn:

http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-0218336dec1ca035191...

веб-интерфейс в git наподобие hg serve: gitweb http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-1dbe0dba1fdab64e839...

(хотя cgit симпатичнее)

git под венду, на всякий случай: http://code.google.com/p/msysgit/downloads/list

Всем спасибо. Буду пробовать Mercurial.

Блин. Я похоже тоже заценю нецентральную ртуть.

про настройку gitweb и миграцию с SVN http://rails.wincent.com/wiki/Setting_up_gitweb

git в картинках: http://eagain.net/articles/git-for-computer-scientists/
git rebase: http://rails.wincent.com/wiki/Using_git_rebase
про копирование коммитов в два репозитория: http://rails.wincent.com/wiki/Using_multiple_repositories_with_Git

(может, ещё кому пригодится)

> Всем спасибо. Буду пробовать Mercurial.
нененене, Evgueni, нет. git лучше;)

http://www.simplicidade.org/notes/archives/2007/12/git_vs_mercuria_1.html
http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html
etc

сквозной пример: взяли репозиторий SVN, конвертировали в git, опубликовали на своём private сервере, задеплоили на public http://rails.wincent.com/wiki/Doing_a_one-off_migration_from_Subversion_to_Git и по ссылкам

"An introduction to git-svn for Subversion/SVK users and deserters" http://utsl.gen.nz/talks/git-svn/intro.html via http://rails.wincent.com/wiki/Git_advantages

git на самом деле не совсем VCS. Это такая объектная БД, которая притворяется файловой системой : http://www.advogato.org/person/apenwarr/diary/371.html http://www.advogato.org/person/apenwarr/diary/369.html http://random-state.net/log/3410155710.html и по ссылкам

> нененене, Evgueni, нет. git лучше;)

Главное преимущество Git - это пеар :D

> http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html

"The only feature missing I miss in Mercurial is the possibility of having local branches in my repository" - бгг. Во-первых, named branches такие есть, во-вторых, обычная идеология работы - branch-per-repository.

> http://blog.experimentalworks.net/archives/38-Git-vs.-Mercurial.html >hg contra: > No per-repository branching

не совсем так, можно делать подпроекты с расширением Forest : http://www.selenic.com/mercurial/wiki/index.cgi/ForestExtension

>> нененене, Evgueni, нет. git лучше;)
>Главное преимущество Git - это пеар :D
Дык, а ещё милионы лемингов не могут ошибаться:P (или сколько там ядерных разработчиков?))

Я год как приобщился к гиту и доволен, а до этого сравнивал гит, всякие перворсы, меркуриалы и тд - выбрал гит.

Единственный недостаток гита - отсутствие казуального интерфейса под офтопик (хачу Tortoise Git). Без него тяжело пересадить вендузятников и приходится юзать костыли типа git-cvsserver и git-svn 8((

>> Главное преимущество Git - это пеар :D

> Дык, а ещё милионы лемингов не могут ошибаться:P (или сколько там ядерных разработчиков?))

Гораздо меньше, просто они хорошо известны.

> до этого сравнивал гит, всякие перворсы, меркуриалы и тд - выбрал гит.

Критерии - в студию. Пока что немногие известные мне выборы выиграл Mercirial (кроме FreeBSD, но там не очень понятная ситуация была)

> Единственный недостаток гита

Вопрос ведь не в недостатках, а в достоинствах. Я верю, что Git - самая подходящая система для разработки ядра Линукса, но я этим не занимаюсь, топикстартер - тоже. Что такого _нужного_ есть в Git, но нет в Mercurial?

> отсутствие казуального интерфейса под офтопик (хачу Tortoise Git)

А TortoiseHg уже есть.

> Единственный недостаток гита - отсутствие казуального интерфейса под офтопик (хачу Tortoise Git).

Tortoise Hg вроде есть в исходниках, взять и прикрутить туда git. Или юзать утилиты вроде http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-21d85cab115f96d35f8... , тот же http://www.cl.cam.ac.uk/~maw48/pmpu/ или совсем http://code.google.com/p/gitsafe/ (этот ну прям сильно на Tortoise Hg похож)

> то такого _нужного_ есть в Git, но нет в Mercurial?

http://www.advogato.org/person/apenwarr/diary/371.html

"Come on, revolutionary? It's just a version control system!

Actually it's not. Git was originally not a version control system; it was designed to be the infrastructure so that someone else could build one on top. And they did; nowadays there are more than 100 git-* commands installed along with git. It's scary and confusing and weird, but what that means is git is a platform. It's a new set of nouns and verbs that we never had before. Having new nouns and verbs means we can invent entirely new things that we previously couldn't do.

Git is a new kind of filesystem, and it's faster than any filesystem I've ever seen: git checkout is faster than cp -a. It even has fsck."

есть там много чего, другое дело, а зачем весь этот зоопарк для простых задач VCS :))

> Git was originally not a version control system; it was designed to be the infrastructure so that someone else could build one on top.

Ога, ога. В 2005-м году, да? То-то Xen как раз в то время выбрал Mercurial (если интересно - поищи их доводы), а сам Git эволюционировал в сторону того, что раньше Линус называл porcelain.

> есть там много чего, другое дело, а зачем весь этот зоопарк для простых задач VCS :))

Примерно то же самое есть "под капотом" всех современных свободных DVCS (кроме Bzr, опжалуй) - они все выросли из Monotone и OpenCM.

просто Mercurial изначально делался как понятный VCS, правда, расширяемый, а git -- как платформа для БД с content-addressable memory, поверх которой можно сделать, например, VCS.

>> до этого сравнивал гит, всякие перворсы, меркуриалы и тд - выбрал гит.

>Критерии - в студию. Пока что немногие известные мне выборы выиграл Mercirial (кроме FreeBSD, но там не очень понятная ситуация была)

Ну основными критериями были дейентрализованость, легкость бранчинга и мёржа бранчей, скорость работы ... Тоесть критерии были примитивными и под них подходил как Mercirial, так и Git.

>Я верю, что Git - самая подходящая система для разработки ядра Линукса, но я этим не занимаюсь, топикстартер - тоже.

Ну и я ядром не занимаюсь, но мне Git вполне подходит для работы. Даже в небольших домашних проектахиках использую гит;)

> Что такого _нужного_ есть в Git, но нет в Mercurial?

Нужного, как сказать. Для простого использования системы контроля версий у них обоих всё в порядке. Но если что-то понадобится экзотическое - то вероятнее всего оно будет в Git, а будет ли Mercurial - это вопрос. Например восстановление удаленного бранча, который не был смержен с другими ветками. В Git такое сделать можно. А в Mercurial?

> А TortoiseHg уже есть.

Это большой плюс.

> А что скажет сообщество по поводу darcs?

хорошая система, если врубаться в "теорию патчей" и постоянно пользоваться darcs amend.

http://changelog.complete.org/posts/588-Re-Examining-Darcs-Mercurial.html http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is-The-Most-Dis... http://changelog.complete.org/posts/596-Some-more-git,-mercurial,-and-darcs.html http://changelog.complete.org/posts/586-Rebase-Considered-Harmful.html http://thread.gmane.org/gmane.comp.version-control.darcs.user/11201 http://hans.fugal.net/blog/articles/2007/11/16/mercurial-and-darcs http://hans.fugal.net/blog/articles/2007/11/20/darcs-and-mercurial-redux

> Tortoise Hg вроде есть в исходниках, взять и прикрутить туда git. Или юзать утилиты вроде http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-21d85cab115f96d35f8.. . , тот же http://www.cl.cam.ac.uk/~maw48/pmpu/ или совсем http://code.google.com/p/gitsafe/ (этот ну прям сильно на Tortoise Hg похож)

Спасибо за ссылки. GitSafe - попробовал, он неюзабелен. Единственное что более менее нормально работает - QGit.

> Например восстановление удаленного бранча, который не был смержен с другими ветками. В Git такое сделать можно. А в Mercurial?

git rebase (просто или --interactive) примерно соответствует по возможностям hg MQ или darcs amend.

Восстановление удалённого бранча -- то есть, был commit, в следующем комите бранч был удален? возможно и там и там, насколько я понимаю

ссылок зато много, перебирай-не хочу! :))) все эти GUI на любителя, проще настроить однотипные шорткаты в emacs к git/hg/svn и не париться :)

> Но если что-то понадобится экзотическое - то вероятнее всего оно будет в Git, а будет ли Mercurial - это вопрос.

Ну вот и хочется примеров такой экзотики - правда ли решения нет, и нужно ли решение вообще.

> Например восстановление удаленного бранча, который не был смержен с другими ветками.

Если бранч не был специально удален (hg strip или hg pull -r), то он просто болтается в репозитории в виде еще одной головы. В первом случае восстановление невозвможно, во втором - ничего и восстанавливать не нужно.

> по поводу darcs?

сравнение потрохов darcs, git, mercurial: "A tale of five merges: cvs, svn, git, darcs, etc" http://www.advogato.org/person/apenwarr/diary.html?start=390

про "теорию патчей": http://en.wikibooks.org/wiki/Understanding_darcs/Patch_theory

мда, оказывается мою любимую gitdbfs в некотором роде уже реализовали: на git -- gitshelve http://www.newartisans.com/blog_files/git.versioned.data.store.php (осторожно, шревты "вырви глаз") и на Mercurial http://piranha.org.ua/blog/2008/05/19/hgshelve/

правда, это только db уровень, связку с fs вроде fuse можно ещё додумать

про миграцию SVN/CVS репозиториев в git: http://www.newartisans.com/blog_files/diving.into.git.php

Виндузятник обнаружил git и импортировал свой SVN репозиторий: http://tilarids.blogspot.com/2008/03/git-svn.html

Попробовал mercurial - для системы контроля версий вроде подходит. Надо теперь ещё прикрутить второй диск и организовать постоянный бэкап для полного счастья и лечения паранойи :)

У кого-нибудь есть идеи какую программу бэкапа лучше использовать?

Вопрос про бэкап разместил тут же: http://www.linux.org.ru/view-message.jsp?msgid=2932359&lastmod=1215967518851

> http://www.linux.org.ru/view-message.jsp?msgid=2932359&lastmod=1215967518851

rsync в cron

Это первое что приходит в голову, но тогда всего одна копия остаётся без истории.

> но тогда всего одна копия остаётся без истории.

? Насколько я понял, нужен бэкап на случай краха диска? Репозиторий, скопированный rsync, сохраняет полную историю, а у обычных данных ее просто нет. Или имеется ввиду generational backup?