Как организовать процесс написания программы?

imho - именно subversion + trac. это не страшно, зато единожды "отмучавшись" дальше всё будет намного проще. вот пример как это может работать:
http://trac.enlightenment.org/e/log/trunk

git, конечно.

svn - куда уж проще-то..

> не с subversion же разбираться

Самое время разобраться. Если, конечно, тебе не достаточно системы контроля вида "полная копия предыдущей работоспособной версии проекта" ;)

естественно git, но если ты очень нежный и особенно вендузятник - то hg (mercurial)

Стопудов git

bzr

разумеется не git. и не svn.

darcs, разумеется.

обязательно git

Обязательно Mercurial.
Ни в коем случае не Git.

> Обязательно Mercurial. > Ни в коем случае не Git.

Поддержу. Насоветовали тут git, svn с траком(!). Стебётесь что-ли? Написано же _простую_ систему контроля версий.

> Стебётесь что-ли? Написано же _простую_ систему контроля версий.

Git cheat sheet умещается действительно на одну страничку. Для svn-like использования git ничем не сложнее. Зато когда с svn дело дойдёт до "эх, блин, вот щас бы...", то оно так и останется "эх, блин", а в случае с git можно дальше документацию почитать.

>Написано же _простую_

Критерий простоты? А вообще - Мигель прав :)

На освоение mercurial + hg_forest ушло два часа(прочтение туториала, man и best practictises в инете). Причём всё работает так как ты думаешь и лазить в доки вообще не приходится.

А вот гит писали нелюди(имхо). Скока я его юзал столько он мне мозг и трахал и работает всё counter-intuitive.

Это нормально что после git repack репозиторий вырос? :). Когда репозиторий был маленьким всё летало. А после тыщи коммитов и холодный старт стал лагать(fsck/gc/repack делал).

Да бросьте, в рамках clone, pull, log, diff и commit почти все rcs одинаковые.

> Да бросьте, в рамках clone, pull, log, diff и commit почти все rcs одинаковые.

Такие мелочи, как clone и pull, не везде есть. Не говоря о том, что Git умудрился сделать всё, что сложнее diff, через жопу^W^Wпо-своему.

Я тоже так думал пока не нарвался на это: http://www.linux.org.ru/view-message.jsp?msgid=3649545

Если мне кто-то объяснит как я такого эффекта добился буду благодарен. Я вообще охренел когда fsck набрал. Десяток деревьев указывал на одно и то же состояние репозитория(проверял по git log и git diff). Как такое могло произойти?

Или баг, или "Это я как-то разрулил.".

Линукс тоже не всем нравится, что с того? :)

> Линукс тоже не всем нравится, что с того? :)

Линукс как раз сделан по уму - как копия Unix внешне, с полностью другими внутренностями. Из DVCS так сделан Mercurial.

d том-то и дело что я действовал вслепую исключительно по "everyday git" и "git quickstart". Хотя и уделил исключительное внимание теории как вообще гит работает, всё равно в реальности я без гугла и многократного перепрочтения манов сделать что-либо сложнее тобой приведённых комманд не мог.

А в hg всё просто, он работает очень примитивно, но это и есть мой use case :).

Например: если я создам бранч в hg то при push он и на удалённой стороне создастся. А в git надо указать какой локальный бранч с каким удалённым работает итп и так с каждым клоном репозитория. Потом трахался их удаляя со всех моих многочисленных клонов.

> Поддержу. Насоветовали тут git, svn с траком(!). Стебётесь что-ли? Написано же _простую_ систему контроля версий.

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

"написании возможности просмотреть изменения на разных этапах разработки, зафиксировать какие-то промежуточные версии. чтобы на локальной машине организовать этот процесс?"

git в данном случае отлично подходит.

> Например: если я создам бранч в hg то при push он и на удалённой стороне создастся. А в git надо указать какой локальный бранч с каким удалённым работает итп и так с каждым клоном репозитория. Потом трахался их удаляя со всех моих многочисленных клонов.

это потому что Вы считаете что git похож на subversion, но это не так :) на subversion похож mercurial - они оба воспринимают репозиторий как нечто неделимое. а git его воспринимает как связанный набор патчей - это принципиальная разница. это хорошо видно по возможности объединить два _разных_ (не склонированных из одного) репозитория. git это умеет, ему всёравно откуда патчи получать а mercurial - нет:

abort: repository is unrelated

отсюда и вытекает «в git надо указать какой локальный бранч с каким удалённым работает» - естественное и логичное требование git'а :) ему же нужно знать откуда именно брать _патчи_ и как их смешивать.

>git это умеет, ему всёравно откуда патчи получать а mercurial - нет: abort: repository is unrelated

Яростное 4.2! Документацию читать надо. hg pull -f (или push -f) сделает то, что надо.

однозначно CVS

Вот видишь, и тут меркуриал оказался удобнее :).

> однозначно CVS

Ты из какого века к нам пожаловал? Сейчас 2009-ый...

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