The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Выпуск распределённой системы управления версиями Mercurial 4.8, opennews (??), 05-Ноя-18, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


45. "Выпуск распределённой системы управления версиями Mercurial ..."  –1 +/–
Сообщение от пох (?), 05-Ноя-18, 17:00 
популярность git держится на бабках инвесторов, вбуханных в гитляп и гитхляп. (в рот Торвальдсу смотрят нолько нубы-опесорсники, из которых после окончания института получается нормальный менеджер среднего звена, в большинстве случаев)
Поскольку первый hg поддерживает на от...сь, а второй просто никак - он непопулярен и популярен не будет.

И это хорошо - меньше альтернативно-одаренных мастеров pull/push пройдет через фильтр.

Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск распределённой системы управления версиями Mercurial ..."  +1 +/–
Сообщение от myhand (ok), 05-Ноя-18, 17:39 
На самом деле - самый лучший код пишут программирующие в наручниках.  Левой ногой.  По крайней мере, однажды таки напишут.  Пока, наверное, обдумывают.
Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск распределённой системы управления версиями Mercurial ..."  –1 +/–
Сообщение от пох (?), 05-Ноя-18, 20:13 
для программирования никакие vcs не нужны, а умеющему только pull/push и бесполезны. Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.

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

Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от myhand (ok), 05-Ноя-18, 22:20 
> для программирования никакие vcs не нужны

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

> а умеющему только pull/push и бесполезны.

Странные вокруг вас люди, может у них диагноз какой.  Большинству вменяемых граждан абсолютно
несложно освоить современные vcs на приемлемом пользовательском уровне.

Хотя вот еще всех в школе писать учили, а пушкиными сделались почему-то не все.  Подозреваю,
умение писать (а возможно и читать) вы находите для всякого быдла (кто кроме вас) - излишними...

> Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.
> и тут хуже "шлите ваши патчи в рассылку, порезав мелкими ломтиками" придумать
> что-то сложно, однако же, вот - цельный линукс написали (правда, многие
> ключевые части таки делали команды, умевшие пользоваться vcs

Я вам открою страшную тайну: не только "умевшие пользоваться vcs" (т.е. обычные, вменяемые
люди), а еще и пользовавшиеся "внутре" нормальными багтрекерами, системами рецензирования
кода и т.п.  "Шлите патчи в рассылку" - это только верхушка айсберга.  Потому в линуксе данный
реликт времен очаковских до сих пор и работает.

Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от Orduemail (ok), 06-Ноя-18, 10:47 
> для программирования никакие vcs не нужны

Да, и текстовый редактор не нужен, можно ведь делать cat >src.c ENTER, вводить код, и тыкать в Ctrl-D по окончании ввода. И компилятор не нужен, можно ведь ассемблировать вручную. Да и вообще компьютер не нужен, программировать можно в уме.

> Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.

Не. Не знаю как mercurial, а git нужен даже для проекта который ты пилишь самостоятельно для себя в одно лицо. git даёт свободу внесения изменений. Ты можешь взять и поменять что-то для теста. Ты можешь начать вносить отладочный вывод, оверпроверки, и кучу другого отладочного кода, если что-то работает непонятным образом, только для того чтобы разобраться что происходит. Когда понимание придёт, всё что надо будет сделать git checkout --hard. То есть, всё это можно и без git'а: чисто теоретически можно делать это создавая копии директорий или как-нибудь ещё, но git делает эти вещи простыми.

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

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

72. "Выпуск распределённой системы управления версиями Mercurial ..."  +1 +/–
Сообщение от пох (?), 06-Ноя-18, 13:20 
>> Они становятся нужны, когда результат этого программирования выносится с твоего локалхоста.
> Не. Не знаю как mercurial, а git нужен даже для проекта который

[skip]
ты прекрасно описал use-pattern cvs (какое, милые, у вас, тысячелетье на дворе?)

этакий "умный undelete".

только вот синтаксис git checkout --hard (да и семантика - причем бы тут - checkout?) придуман кем-то явно незнакомым с cvs и вообще vcs, и изобретал велосипед - ну и изобрел, с квадратными колесами и без цепи, надо ногами толкаться, зато так веселее.

> Если же на более сложном уровне, то git позволяет создать внятную историю

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

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

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

говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она не умеет rebase.

зато и синтаксис, и семантика человеческие. А если что-то пошло не так - она останавливается и ждет, пока ты сам разберешься. И 3way merge у нее, по-моему, уже тоже был - причем без использования прекрасного kdiff, который не очень здорово работает через ssh (а скоро совсем не будет, с пришествием божественного вафлянда)

А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный git pull вместо fetch ? (в hg такая ошибка невозможна, потому что у нее нет "третьего состояния" git add)

банальнейшая ведь ситуация, если чуть в стороне от локалхоста :-(

Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от Orduemail (ok), 06-Ноя-18, 14:03 
>[оверквотинг удален]
> только вот синтаксис git checkout --hard (да и семантика - причем бы
> тут - checkout?) придуман кем-то явно незнакомым с cvs и вообще
> vcs, и изобретал велосипед - ну и изобрел, с квадратными колесами
> и без цепи, надо ногами толкаться, зато так веселее.
>> Если же на более сложном уровне, то git позволяет создать внятную историю
> к сожалению, гит _форсирует_ подделку этой самой истории - потому что никаким
> другим способом даже на локалхосте работать невозможно, не говоря уже о
> совместной работе (ну если не считать таковым push -f - что
> у нас вон принято делать, но тут, традиционно, ни разработчики, ни
> тем более архитекторы проекта гитом пользоваться и не умеют)

Это интересно. Если тебе не влом, расскажи мне, как в "нормальных" vcs я мог бы разрулить следующую ситуацию и получить внятную историю. Смотри, я запиливаю в проект новый функционал. В процессе я нахожу косяки в проекте не связанные с тем, что я сейчас делаю -- я могу создать issues об этих косяках, но часто проще исправить на месте. Иногда я нахожу косяки связанные с тем, что я делаю -- то есть я не могу запилить новый функционал, пока не внесу некоторые архитектурные изменения в существующий проект. Тут три типа изменений, в случае с git я могу вносить их хоть в полном беспорядке, с тем чтобы позже раскидать их по веткам с говорящими именами, а потом эти ветки красиво мергнуть в dev-ветку. Как то же самое проделать без "подделки истории"? Я ведь вношу все эти изменения не зная, что будет через полчаса. У меня есть определённый план внесения изменений, но он постоянно спотыкается о реальность и меняется.

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

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

>> более крупные. Впрочем, даже без этого -- беспорядочный поток коммитов вместо
>> истории тоже очень полезен для понимания происходящего.
> говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она
> не умеет rebase.

cvs я пробовал освоить ещё до git. Ниасилил. Совершенно ненужная вещь. Может быть для командной разработки и полезно, но для локальной разработки в одно лицо -- излишество.

> зато и синтаксис, и семантика человеческие.

Да что вы так озабочены этими человеками? vcs создаётся для программистов, а не для человеков, это тот редкий случай, когда разработку интерфейса не стоит доверять UX-специалисту, а следует оставить программисту, потому что программист для программиста сделает лучше, чем UX-спец для программиста.

> А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный
> git pull вместо fetch ?

В чем проблема? Как откатить назад несколько коммитов? Не заглядывая в шпаргалку, я бы предположил что надо сделать git checkout на последний правильный коммит, а затем туда перенести HEAD ветки. Последнее навскидку я не уверен как сделать. Но если без шпаргалок, то можно удалить старую ветку, и создать на этом коммите её заново. А на всякий случай, прежде чем удалять, надо... короче, чтобы было понятно, последовательность действий такая:

git branch temp
git branch -d screwed
git checkout <hash of last good commit>
git branch screwed
git branch -d temp

Я бы делал так, если бы не мог заглянуть в шпаргалку. Но я не понимаю этого искусственного ограничения: man git-branch всегда под рукой.

> (в hg такая ошибка невозможна, потому что у нее нет "третьего состояния" git add)

И как hg предлагает обходить нехватку этого третьего состояния? Оно ведь очень удобно, для создания истории в первом приближении: я собираю в коммит то, что нужно, смотрю всё ли правильно, затем делаю commit. Не совсем удобно то, что если я хочу закоммитить не все изменения в файле A, а только часть их -- приходится не на этапе git add это делать, а уже непосредственно в процессе commit'а, а в случае ошибок откатывать коммит. Но и всё же, add очень удобен. Как жить без него?

> банальнейшая ведь ситуация, если чуть в стороне от локалхоста :-(

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

Ответить | Правка | Наверх | Cообщить модератору

81. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от Аноним (81), 06-Ноя-18, 15:40 
> Не совсем удобно то, что если я хочу закоммитить не все изменения в файле A, а только часть их -- приходится не на этапе git add это делать, а уже непосредственно в процессе commit'а, а в случае ошибок откатывать коммит.

Вы имеете в виду "git commit -p"? Возрадуйтесь, ибо существует и "git add -p".

Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от myhand (ok), 06-Ноя-18, 14:47 
> только вот синтаксис git checkout --hard (да и семантика - причем бы
> тут - checkout?)

Притом, что обновление рабочего каталога.

> придуман кем-то явно незнакомым с cvs

Это с чего вдруг, гражданин телепат?

> изобретал велосипед - ну и изобрел, с квадратными колесами

Велосипед с квадратными колесами умеет делать атомарные изменения в данных репозитория, в отличие от cvs, способной превратить их в лапшу, если UPS не озаботиться.  Или интернет в нужный момент кончился...

>> Если же на более сложном уровне, то git позволяет создать внятную историю
> к сожалению, гит _форсирует_ подделку этой самой истории

Торвальдс сам к вам с наганом приходил, заставляя push -f?

Переписывание истории - вещь полезная локально, для чего ее и используют.  Если же вас угораздило
работать с проектом, в котором кто-то постоянно push -f в центральный master - git тут не виноватый.
Вы уж тогда в корень зрите - надо срочно молотки запретить.  Они ведь людей убивают.

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

И где у нас cvs bisect?

> зато и синтаксис, и семантика человеческие.

Притом человечество все упрямее им не пользуется.  Даже разработчики cvs давно забили на поделку.

Впрочем, человечество у нас не Дартаньяны.  Дартаньян - вы.

> И 3way merge у нее, по-моему, уже тоже был - причем без использования
> прекрасного kdiff

kdiff нету, 3way merge в git работает - ЧЯДНТ?

> А теперь, без подглядывания в шпаргалку, расскажи нам, как откатить обратно ошибочный
> git pull вместо fetch ? (в hg такая ошибка невозможна, потому
> что у нее нет "третьего состояния" git add)

(подразумеваю, что рабочий каталог чистый от изменений, тогда)
git log -1 && git reset --hard <sha1 последнего вашего коммита>

Хотя не исключаю, что можно и короче, если в шпаргалку посмотреть.

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

88. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от пох (?), 06-Ноя-18, 22:15 
> Притом, что обновление рабочего каталога.

в каком месте в слове checkout находится "обновление рабочего каталога" ?

>> придуман кем-то явно незнакомым с cvs
> Это с чего вдруг, гражданин телепат?

ну вот, например, "неожиданное прочтение" слова checkout как раз об этом и говорит.
У всех, кто пользовался cvs, почему-то в этом случае - revert.

> Велосипед с квадратными колесами умеет делать атомарные изменения в данных репозитория, в
> отличие от cvs, способной превратить их в лапшу, если UPS не озаботиться.

у вас помимо cvs данные способна уничтожить файловая система, особенно модные-современные, героически защищающие "непротиворечивость метаданных", в ущерб данным, носитель - особенно модный-современный, секторная метка записывается вместе с сектором, каждый раз, про ssd с их 32k pages и "на кого Бог пошлет" при отказе уж молчу, а вы все без ups ?

>> к сожалению, гит _форсирует_ подделку этой самой истории
> Торвальдс сам к вам с наганом приходил, заставляя push -f?

push -f это не подделка истории, это уничтожение вместе со свидетелями и создание снова (зачем устраивать армагеддец своим данным - отдельный вопрос). Подделка - rebase. Когда реальная история работы над ошибками заменяется вымышленной "для чистоты лога".

> Притом человечество все упрямее им не пользуется.

человечество прекрасненько пользуется svn, hg и даже, местами,перфорсой - хотя все они - последовательные улучшатели именно cvs. Пользоваться ей самой в наши дни - все равно что sendmail настраивать на большом релее. Можно, но непонятно, зачем.

> kdiff нету, 3way merge в git работает - ЧЯДНТ?

CONFLICT (content): Merge conflict in (какаятохрень)
в исходнике в результате какое-то
>>>>> some shit

...
<<<<< more shit
ну спасибо, конечно, но 3way merge я как-то иначе представлял.


> git log -1

э... он говорит - "тут какой-то automerge случился". И чего дальше? ;-) Я не хочу последствия ЭТОГО коммитить обратно в чужой репо.
ну и отдельный вопрос - что по этому поводу написано в документации. Не в гугле, а в документации ;-)

> Хотя не исключаю, что можно и короче, если в шпаргалку посмотреть.

фиг там :-(
особенно с учетом что такие проляпы случаются, когда давно эту копию не трогали, и не помнят, что там было add, что просто так валялось, а что локально закоммичено но незапушено.

Ответить | Правка | Наверх | Cообщить модератору

91. "Выпуск распределённой системы управления версиями Mercurial ..."  –1 +/–
Сообщение от myhand (ok), 06-Ноя-18, 23:33 
>> Притом, что обновление рабочего каталога.
> в каком месте в слове checkout находится "обновление рабочего каталога" ?

Ну, checkout как бы символизирует check out.  Дальше см. словарь англо-русский.

>>> придуман кем-то явно незнакомым с cvs
>> Это с чего вдруг, гражданин телепат?
> ну вот, например, "неожиданное прочтение" слова checkout как раз об этом и говорит.

man english

> у вас помимо cvs данные способна уничтожить файловая система

Или метеорит.  Но мы не про астрономию, а про конкретные баги конкретной vcs, которые
никто и никогда уже не починит.  Ибо cvs - дохлая.

>>> к сожалению, гит _форсирует_ подделку этой самой истории
>> Торвальдс сам к вам с наганом приходил, заставляя push -f?
> push -f это не подделка истории, это уничтожение вместе со свидетелями

Как же не подделка.  Была одна история - стала другая.  Прям как в РФии с ВНаУкраиной.
Более точно, конечно, push -f - это публикация поддельной истории.

Однако, вы таки ушли от вопроса: злые коммисары с маузерами вас
заставляют историю подделывать?  Может на свете и есть граждане,
которые каждый коммит в процессе работы обмусолят до невероятности,
прежде чем закоммитить - и список файлов, и изменения в них, и
комментарий к коммиту...  Но если глянуть на публичные cvs репы - то
возникает подозрение, что подобные граждане пользуются точно не cvs.

> Когда реальная история работы над ошибками заменяется вымышленной "для
> чистоты лога".

Не для "чистоты лога", а для удобства последующей работы с изменениями.

> ну спасибо, конечно, но 3way merge я как-то иначе представлял.

Кто-ж виноват, что вы даже не удосужились выяснить что это такое.

>> git log -1
> э... он говорит - "тут какой-то automerge случился". И чего дальше? ;-)

Смотрим sha в мерже, там будет помимо HEAD'а - sha вашего последнего коммита, который
и вставляем во вторую команду.

> Я не хочу последствия ЭТОГО коммитить обратно в чужой репо.

Не хотите, не коммитьте.  Вам же объяснили как быть.  История с ненужным мержем просто исчезнет.

> ну и отдельный вопрос - что по этому поводу написано в документации.

Без понятия.  А какая разница?  Скорее всего, данную задачу можно решить еще
как-то, как и большинство задач.  Может в одну команду, а не две.  Только нафига
мне это выяснять?

Ответить | Правка | Наверх | Cообщить модератору

123. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от пох (?), 07-Ноя-18, 19:32 
> Ну, checkout как бы символизирует check out.  Дальше см. словарь англо-русский.

"обновления(!) рабочего каталога" я в этом словаре не усматриваю. Наверное, у тебя гуглтранслейт вместо словаря.

> Однако, вы таки ушли от вопроса: злые коммисары с маузерами вас заставляют историю подделывать?

да, заставляют - git не оставляет другого workflow кроме бесконечных rebase.

>> ну и отдельный вопрос - что по этому поводу написано в документации.
> Без понятия.  А какая разница?  

такая что это частая ошибка и документация, в которой этого нет в самом начале - дерьмо, а не документация.

Ответить | Правка | Наверх | Cообщить модератору

128. "Выпуск распределённой системы управления версиями Mercurial ..."  –1 +/–
Сообщение от myhand (ok), 08-Ноя-18, 00:54 
>> Ну, checkout как бы символизирует check out.  Дальше см. словарь англо-русский.
> "обновления(!) рабочего каталога" я в этом словаре не усматриваю.

Смотри лучше.

>> Однако, вы таки ушли от вопроса: злые коммисары с маузерами вас заставляют историю подделывать?
> да, заставляют - git не оставляет другого workflow кроме бесконечных rebase.

Делай коммиты так, чтобы потом не понадобилось их переделывать по-человечески - и не нужно будет никаких rebase.  Удиви мир своим гением!

>>> ну и отдельный вопрос - что по этому поводу написано в документации.
>> Без понятия.  А какая разница?
> такая что это частая ошибка

За последние несколько лет - на данную "частую ошибку" не натыкался ни разу.  На что-то
подобное, кажется, однажды (кажется, случайно смержил очень сырую ветку в другую, уже
почти готовую в master).  Ни в документацию, ни в гугл лезть при этом не понадобилось.

> документация, в которой этого нет в самом начале - дерьмо, а не документация.

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

Ответить | Правка | Наверх | Cообщить модератору

108. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от Аноним (-), 07-Ноя-18, 09:54 
> Когда реальная история работы над ошибками заменяется вымышленной "для чистоты лога".

Тут как бы очень спорный вопрос - надо ли мне видеть вообще всю лажу Пупкина. Я и сам так порой балуюсь. Особенно если хочу чтобы изменения аудит другими рожами прошли. Если я наспамлю там своими потугами в которых наломал дров - все только запутаются, а аудит как таковой не получится вообще. Народ потеряется в техническом гуано и вместо изучения моего кода будет пыриться в всякий спам. Что им даст знание что я наломал дров, передумал, попробовал еще раз и еще и иначе - я даже и не знаю. Скорее всего получится как с лениным и жандармами - задолбаются и читать окончательный вариант вообще толком не будут. А вот это совсем не айс.

> человечество прекрасненько пользуется svn, hg и даже, местами,перфорсой - хотя все они
> - последовательные улучшатели именно cvs.

Так и на лошадях кто-то ездит. Просто их осталось мало.

Ответить | Правка | К родителю #88 | Наверх | Cообщить модератору

124. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от пох (?), 07-Ноя-18, 19:41 
> Тут как бы очень спорный вопрос - надо ли мне видеть вообще
> всю лажу Пупкина. Я и сам так порой балуюсь. Особенно если

в случае hg можно баловаться в named branches - которые можно вообще не экспортировать наружу, тогда ты видишь только результат мержа.
Но свою историю видишь в неизменном виде, пока она вообще тебе нужна (а дальше close ее и больше не видишь).

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

> Так и на лошадях кто-то ездит. Просто их осталось мало.

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

Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск распределённой системы управления версиями Mercurial ..."  +1 +/–
Сообщение от Аноним (-), 07-Ноя-18, 09:45 
> И где у нас cvs bisect?

До его окончания не дожил даже МакЛауд. Представляешь себе как оно - на любое действо полпроекта заново качать? С таким bisect проще будет вычислить баг по старинке. А по другому CVS не умеет, внезапно.

Ответить | Правка | К родителю #78 | Наверх | Cообщить модератору

110. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от Аноним (-), 07-Ноя-18, 09:58 
> говорю же - cvs, 1998й год. Нет, ветки она тоже умеет. Она
> не умеет rebase.

Она не умеет, блин, локальную работу с версиями толком. Да и ремотную - перекачивает полпроекта на каждый пшик. И если в hello world с этим можно жить, то в проекте размером с хотя-бы реактос это извините полный ахтунг. Как bisect сделать - да никак, такой хайтек CVSникам недоступен, да и смысла в нем мало - во многих случаях скачать проект дюжину раз займет дольше чем баг пришлепнуть иными методами.

Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

93. "Выпуск распределённой системы управления версиями Mercurial ..."  +/–
Сообщение от Аноним (-), 07-Ноя-18, 09:22 
> для программирования никакие vcs не нужны, а умеющему только pull/push и бесполезны.

Ну да. Древние как-то тумблерами на шину, с тетрадного листка. Правда вот время написания программы и исправления в ней ошибок было, скажу я вам.

Ответить | Правка | К родителю #54 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру