>когда есть надёжный и проверенный временем CVS?
CVS — эта та самая система управления версиями, пользователи которой панически боятся бренчей и мерджей? Не надо такой.
Ну в SVN сейчас получше с бренчами, чем пару версий назад, а вот в CVS... Да что там говорить, если CVS не умеет атомарно сделать коммит, а сделать патч изменений между двумя ревизиями неимоверный гемор, как тут можно говорить серьезно? Честно не понимаю людей которые еще ее используют и лично бы душил, которые переходят (да, такие нехорошие личности существуют еще) на нее с других систем. В любом случае все со свистом сосут у GIT, и тут ничего не поделаешь, а слезы неосиляторов никого не волнуют.
Ну в SVN сейчас получше с бренчами, чем пару версий назад
Ничего не получше, такое говно. svn copy, а потом svn merge с кучей страшных параметров, которые каждый раз надо вычитывать в мане.
Да что там говорить, если CVS не умеет атомарно сделать коммит, а сделать патч изменений между двумя ревизиями неимоверный гемор, как тут можно говорить серьезно?
Поэтому в CVS активно пользовались тегами.
В любом случае все со свистом сосут у GIT, и тут ничего не поделаешь
По количеству невменяемых команд и параметров конечно.
>Ничего не получше, такое говно. svn copy, а потом svn merge с кучей страшных параметров, которые каждый раз надо вычитывать в мане.
Ты отстал от жизни. Я ничего для мержа кроме как номеров ревизии (и то почти никогда) вообще ничего не указываю, SVN через костыль в виде svn:merginfo сам все разруливает. Самое страшное с чем я сталкивался — это tree conflict, но этим все системы управления версия грешат в разной степени.
Поэтому в CVS активно пользовались тегами.
А это тут при чем? Я как-то по привычке Ctrl+C нажал при коммите, а потом ох**л от того что произошло с репозиторием. Это ж цирк.
По количеству невменяемых команд и параметров конечно.
Это да. Кривая обучения у GIT крутая, но разобраться можно. А уж для простых действий там знать особо много и не нужно.
Это да. Кривая обучения у GIT крутая, но разобраться можно.
зачем это делать и забивать голову всяким говном, если есть mercurial, который может всё тоже самое, но при этом с ним можно работать сразу или почти сразу ?
А уж для простых действий там знать особо много и не нужно.
Ога, конечно, вот тебе пример конректного простого действия:
>зачем это делать и забивать голову всяким говном, если есть mercurial, который может всё тоже самое, но при этом с ним можно работать сразу или почти сразу ?
Я против меркуриала ничего не имею, но когда он отказался работать с однной рабочей копией в двух разных минорных версиях, просто с ним дела иметь перестал вообще из принципа.
То есть для такой тривиальщины в git'е вместо одной сущности используются две и вот так во всем.
Если почитать ман повнимательнее, то становится понятно, что это совсем не эквивалентные вещи их надо сравнивать скорее с svn update и svn switch. уж как там в Hg выкрутились — не знаю.
Я против меркуриала ничего не имею, но когда он отказался работать с однной рабочей копией в двух разных минорных версиях
Чего ты хотел сделать?
Если почитать ман повнимательнее, то становится понятно, что это совсем не эквивалентные вещи их надо сравнивать скорее с svn update и svn switch. уж как там в Hg выкрутились — не знаю.
Работать с одной рабочей копией из двух разных минорных версий hg.
это как это? в svn это делается так
Нет. revert и в первом и втором случае по аналогии можно сделать через reset. А вот switch — это уже совсем не revert, и совсем не reset, это по аналогии — checkout.
>А как так могло получится?
Надо было тупо взять проект у одного человека на флешке. Внезапно hg забыл про свои старые версии. Чтоб такое возникло у svn...
отсюда я делаю вывод, что он сбрасывает state всего HEAD'а, то есть всех файлов, а мне это нафиг не надо
>Видно, что с svn ты мало общался. Раньше с ним такое постоянно происходило.
Да много лет уже общаюсь и всегда была обратная совместимость на высоте в отличие от.
Какой такой stage ? Я не знаю что это и не хочу знать и забивать голову всякой %уетой. Я просто хочу вернуть правки в файлах или во всем проекте, все.
Вопрос закрыт. Нежелание изучения элементарных основ = тотальное непонимание всего остального. Это все равно что вышку изучать без знания основ математики.
кстати, у такого «частого» и «мегарулезного» git'а что предлагают использовать вместо mq ?
rebase и amend научился хоть hg, без левых экстеншнов? А то даже страшно использовать.
Да много лет уже общаюсь и всегда была обратная совместимость на высоте в отличие от.
я помню времена когда не было никакой обратной совместимости
Нежелание изучения элементарных основ
Это не элементарная основа, а ввод ненужных сущностей в элементарный процесс. Почему я открываю man hg и сразу все ясно что и для чего? А открываю man git и вдруг оказывается, что то что там написано это на самом деле не то, что там написано, а для его понимания и истолкования надо изучать «высшую математику» ?
rebase и amend научился хоть hg, без левых экстеншнов? А то даже страшно использовать.
Если amend это commit --amend, то этот данный функционал есть в mq.
Насчет rebase, я вообще считаю, что бранчи в одной директории это всё от лукавого. rebase есть в hq, но я не знаю что он делает, ибо никогда не пользовался.
rebase есть, в rebase и как и в гите «линеаризует» историю, только в отличии от гита делает это немного странно (или я не осилил) в итоге получалось дублирование всех патчей. Mq конечно клёвый да и ещё пара нововведений типа расшаривания bookmark, но в гите в том или ином виде всё это есть, разве что кроме анонимных веток, но там логика разная.
В целом 2 git и hg это хороших инструмента, и кому чт удобнее использовать..