LINUX.ORG.RU

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


0

0

В кой-то веки столкнулся с тем, что надо написать более-менее серьезную программу (один физический солвер, но не суть важно). И понимаю, что мне жутко не хватает при написании возможности просмотреть изменения на разных этапах разработки, зафиксировать какие-то промежуточные версии. Какую-то простую систему контроля версий.

Какие есть простые средства (что-нибудь совсем для начинающих, не с subversion же разбираться), чтобы на локальной машине организовать этот процесс?

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

sda00 ★★★
()

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

thevery ★★★★
()

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

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

alexsaa
()

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

stpg
()

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

mqspi
()

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

Miguel ★★★★★
()
Ответ на: комментарий от Sphinx

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

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

fenris ★★★★★
()
Ответ на: комментарий от fenris

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

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

mv ★★★★★
()
Ответ на: комментарий от fenris

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

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от mv

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от mv

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от mv

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

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

true_admin ★★★★★
()
Ответ на: комментарий от mv

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от mv

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

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

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

true_admin ★★★★★
()
Ответ на: комментарий от fenris

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

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

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

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

smh ★★★
()
Ответ на: комментарий от true_admin

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

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

abort: repository is unrelated

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

Eshkin_kot ★★
()
Ответ на: комментарий от Eshkin_kot

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

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

Zenom ★★★
()
Ответ на: комментарий от Eshkin_kot

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

true_admin ★★★★★
()
Ответ на: комментарий от smh

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

val-amart ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.