система контроля версий !

предложения в ЛС, ЛС в профиле.

пишу так вот в каталоге репозитория !

hg clone /var/.../subdomains/symfony/Symfony/ first_clone
abort: repository /var/.../subdomains/symfony/Symfony/ not found!

Тебе уже тыщщу раз написали:

• создаешь пустую директорию
• делаешь в ней hg init
• регистрируешь свой проект где-нибудь на сосфорже
• в .hg/hgrc в defaults вписываешь адрес этого проекта
• если надо — регистрируешь еще где-нибудь
• пишешь код
• делаешь hg add * (если все надо добавить)
• делаешь hg commit и пишешь комментарий к первому коммиту (initial run обычно)
• делаешь hg push

Я для себя даже заметочку в жожошке делал

Да, в ~/.hgrc есть смысл сделать базовую настройку:

[ui]
username = Твое Имя <твое@мыло>
verbose = True

[auth]
sf.prefix = hg.code.sf.net
sf.username = твой_логин_на_сосфорже
sf.password = ТвОйПаРоЛь
sf.schemes = https

gc.prefix = code.google.com
gc.username = твой_логин_на_гуглокоде
gc.password = тВоЙпАрОлЬ
gc.schemes = https

В этом случае не придется писать username в каждый .hg/hgrc и не придется пароль вводить каждый раз, как push делаешь.

Ну, а для того, чтобы работать на другом компьютере, просто в первый раз делаешь hg clone URL, а затем для обновления коммитов, сделанных с других компьютеров, — hg pull.

Еще там куча всякой всячины есть, но я — баран. Разве что hg diff использую помимо всего вышеперечисленного.

ты забыл самое главное: можно делать банки hg bun. Банка это тоже репка, но одним файлом. Можно на флешку, можно почтой. Ну как угодно. С банками твой сосфорж и не нужен.

Нафига тогда VCS?

Копируем имеющиеся файлы в рабочую директорию

cp -r /var/.../subdomains/symfony/Symfony/ first_clone
cd first_clone
hg init .
hg add
#Работаем с файлами
hg commit
# сносим все что было
#rm -r /var/.../subdomains/symfony/Symfony/ 
# клонируем из рабочей директории
hg clone first_clone /var/.../subdomains/symfony/Symfony

ты не поверишь: для контроля версий кода. Дистрибуция это уже дополнительная фича.

Даже если ты один единственный разраб, всё равно приходится минимум две ветки держать. И сразу две поддерживать. Т.е. мержить тоже приходится. А не только push/pull.

Я так далеко не заходил. Только одна ветка. А то еще не хватало проблем себе на задницу...

hg clone first_clone /var/.../subdomains/symfony/Symfony

а зачем плодить сущности? Или это пример только?

Я так далеко не заходил. Только одна ветка. А то еще не хватало проблем себе на задницу...

дык ты сам подумай, вот ты сделал няшную программу калькулятор. Оно умеет складывать. Всё ништяк. Ты решил делать умножение, но оно у тебя черезжопное и кривое пока. Что, будешь в мануале писать «дорогие юзеры, не юзайте пожалуйста умножение!», да?

А так делаешь две ветки, и пилишь спокойно. Ну а если баг найдут в релизе — не беда, пофиксишь там же, и смержишь в дебаговой ветке.

Очень удобно, попробуй. Тебе понравится.

Что, будешь в мануале писать «дорогие юзеры, не юзайте пожалуйста умножение!», да?

Нет, просто не буду делать pull, пока не заработает. А в качестве промежуточного хранилища у меня Dropbox.

Очень удобно, попробуй. Тебе понравится.

У меня и с одной-то веткой косяки бывают (если долго не разрабатывал, потом начинаю вспоминать, где более свежий релиз: на сосфорже или в дропбоксе).

Нет, просто не буду делать pull, пока не заработает. А в качестве промежуточного хранилища у меня Dropbox.

блжад... Шёл 21й век... У меня hg ci делается после каждой удачной сборки.

У меня и с одной-то веткой косяки бывают (если долго не разрабатывал, потом начинаю вспоминать, где более свежий релиз: на сосфорже или в дропбоксе).

вот именно. А так ты будешь видеть всю историю с датами. Чем больше ты делаешь коммитов, тем лучше.

У меня

hg ci

делается после каждой удачной сборки.

А что это такое? Нифига не понятно, для чего сокращение такое.

Чем больше ты делаешь коммитов, тем лучше.

Тем больше шансов запутаться. Тем более, что я не умею делать откаты и т.п.

Смотрите, живой Луговский :)

А что это такое? Нифига не понятно, для чего сокращение такое.

facepalm

$ hg help ci
hg commit [ПАРАМЕТР]... [ФАЙЛ]...
псевдонимы: ci
зафиксировать указанные файлы или все изменения в хранилище

Тем больше шансов запутаться.

в трёх ветках? КАК??? Обычно там одна даже идёт, в которой всё и пишешь.

Тем более, что я не умею делать откаты

$ hg help up
hg update [-c] [-C] [-d ДАТА] [[-r] РЕВИЗИЯ]

псевдонимы: up, checkout, co

обновить рабочий каталог (или переключить ревизию)

    Обновляет рабочую копию хранилища на указанную ревизию. Если ревизия не
    задана, обновляет до оконечной ревизии (tip) текущей именованной ветки и
    перемещает текущую закладку (см. "hg help bookmarks").

что сложного-то?

Я обычно целиком пишу.

что сложного-то?

Сложно — ковыряться в дереве ревизий.

Сложно — ковыряться в дереве ревизий.

таки попробуй, потом расскажешь. Что «сложно», и как ты так раньше жил. И какое я говно, что тебе об этом рассказал только сегодня ☺

живой Луговский :)

Вот и Луговского настиг маразм...

Еще бы hg diff -r reva:revb цветом показывал разницу... Ну или как-нибудь более понятно.

гиториус

Не учи плохому. Есть же гитлаб, внутрях у которого гитолайт. Мега удобная штуковина.

Еще бы hg diff -r reva:revb цветом показывал разницу... Ну или как-нибудь более понятно

у меня и так цветом

[defaults]
# suppress noisy extdiff header message
cdiff = -q

[extensions]
hgext.hgk=
hgext.graphlog=
hgext.patchbomb=
hgext.extdiff=
color =
pager =

[pager]
pager = LESS='FRSXQ' less
quiet = True
attend = outgoing,incoming,diff,status,log,qdiff,blame,annotate,pdiff,glog

Ой, спасибо!

Ну и вещь! Класс!!!

Не учи плохому. Есть же гитлаб, внутрях у которого гитолайт. Мега удобная штуковина.

Ну, я только гиториус знаю =)

бедненький...

ну ещё ветки осиль, это ещё круче. ☺

Git или Mercurial?

Старый добрый Subversion.

с маленькими директориями норм работает,а вот большой проект пытаюсь отслеживать и такое вот пишет после

hg add

как исключать файлы из слежки ??? 'mnjn файл больше 10 мегабайт весит (

bash-4.1$ hg ci trouble committing tmp/sess_gf8reki7h0t5vpdp9mmtts8na5! transaction abort! rollback completed abort: Permission denied: /var/www/vhosts/ooo-metko.host4g.ru/httpdocs/tmp/sess_gf8reki7h0t5vpdp9mmtts8na5

как то можно посмотреть, что конкретно было изменено в фале относительно другой ревизии ?

hg log -v -p -r7

для особо молчаливых )

VCS никакой «контроль» обеспечивать не должна.

Ты некомпетентен. Как ты к dvcs прикрутишь hook-и, которые не дадут закоммитить без ссылки на Jira/Bugzilla/whatever, например?

Тебе говорили, что ты больной?

меркуриал ставь, он проще.

Я лично предпочитаю mercurial, он для меня намного интуитивнее и допиливать меньше приходится
допиливать меньше приходится

небось юзаешь tortoise hg, поэтому все расширения за тебя включены? ибо типично, допиливать таки приходится hg. в нем такие _базовые_ фичи как rebase, stash, mq, purge, color, pager все через расширения. особенно весело, когда расширения нужно ставить вручную, а потом они отваливаются после апдейтов hg. а как прикольно в нем mergetool реализован, например запускаешь hg merge из скрипта на сервере по крону, а он дергает vimdiff. это дефолтное поведение, он не проверяет даже что терминал не приаттачен. еще прикольно, что fetch и pull в hg перепутаны относительно git по названию, и fetch к тому же расширением зачем-то сделан. иногда создается впечатление, что авторы hg тупо делали все «только бы не как в git».

небось юзаешь tortoise hg

мимо.

поэтому все расширения за тебя включены?

Вопрос не в расширениях. А в уровне диагностики (mercurial выдаёт при работе много подсказок) и юзабилити (понимание сокращённых команд и т.п.)

еще прикольно, что fetch и pull в hg перепутаны относительно git по названию

Или в git они перепутаны относительно mercurial? :)

Как бы там ни было, первым (после svn лет 8 назад) я щупал git, работаю сейчас чаще с git, тем не менее, с git я постоянно утыкаюсь в то, что не знаю, как сделать ту или иную простую операцию, а с mercurial такого не было вообще никогда. Просто берёшь и работаешь :)

иногда создается впечатление, что авторы hg тупо делали все «только бы не как в git».

git был представлен 7 апреля 2005г.
mercurial — 19 апреля 2005г.

Прямо так и вижу, как они за две недели сидят и лепят «только бы не как в git!» :D

Но даже если и был бы такой подход, я бы его только приветствовал. Так как с _моей_ точки зрения, как я писал, mercurial вышел несравним интуитивнее и комфортнее, чем git.

А в уровне диагностики (mercurial выдаёт при работе много подсказок)

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

юзабилити (понимание сокращённых команд и т.п.)

сокращенные команды это мелочь, а вот «и т.п.» хотелось бы подробнее :)

с git я постоянно утыкаюсь в то, что не знаю, как сделать ту или иную простую операцию, а с mercurial такого не было вообще никогда. Просто берёшь и работаешь

это говорит только о том, что ты слабовато знаешь git.

много, только написан в них типично всякий бред

Я же писал выше — в результате с git'ом постоянно приходится лезть в google, а с mercurial — просто работаешь :)

это говорит только о том, что ты слабовато знаешь git.

Так я с самого начала о том и пишу. Что с mercurial можно просто взять и начать работать, а git надо долго изучать. Именно потому что mercurial намного интуитивнее. Чтобы работать с ним, его не нужно знать хорошо, достаточно иметь очень поверхностное представление. А вот с git так не получится. Его надо _знать_.

Согласен: bash-completion для git и hg выдают списки опций. Только у hg подавляющее большинство опций интуитивно понятно, а у git хрен разберешься!

Правда, основные команды таки у них одинаковы.

Так я с самого начала о том и пишу. Что с mercurial можно просто взять и начать работать, а git надо долго изучать.

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

А вот с git так не получится. Его надо _знать_.

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

это значит, что ты меркуриал более-менее изучил, и наработал навыки

Естественно. И сделал я это именно потому что он проще и интуитивнее. Который раз я уже про это пишу? :)

и используешь намного меньше/реже, поэтому постоянно спотыкаешься.

Тут важно причину со следствием не путать :) Я же писал выше, что начал первым использовать git. Но как только стал пробовать hg, так сразу он стал нагляднее и понятнее. И очевидно, что именно поэтому я hg использую гораздо чаще. А менее интуитивный git — реже.

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

Не знаю. Я именно что начал использовать сразу, лишь изредка заглядывая в гугл для не самых ходовых операций, типа переноса файла со всей историей из одного репозитория в другой и т.п. А на уровне простой работы с коммитами, дифами и ветками мне по hg хватало даже не man'а, а help'а из самих команд.

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

и я на git перехожу ) жесть !

еще прикольно, что fetch и pull в hg перепутаны относительно git по названию

Скорее наоборот. Потому что если push это только push без всяких коммитов, то и pull должен быть просто pull без других операций. А я в гите долго искал, как после pull сделать update до последней ревизии, а потом оказалось что он сам его запускает :)

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

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

это субъективщина

С чего подветка и началась: система контроля версий ! (комментарий)

Я обычно hg предпочитаю, если есть выбор. Но после недолгого пользования git мне понравилась там идея stage area - т.е. сначала отдельно выбираешь всё что нужно, и потом коммит. И да, git абсолютно неинтуитивен - без манов там мало что можно сделать поначалу, в отличие от hg, где я поначалу часто просто угадывал что нужно сделать, чтобы было хорошо.

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