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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

abort: repository is unrelated

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

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

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