Здравствуйте, Anton Batenev, Вы писали:
AB>Если коротко, то все аргументы можно свести к слову "удобно" — один из немногих примеров, когда фраза "ПО написанное разработчиком для разработчиков" не несет в себе негативного оттенка.
"Удобно" и "разработчиком для разработчиков" -- это про Mercurial. А про Git вот:
if ping was designed by the git people: net-ping host --no=dns,bind --proto=TCP,rfc:492 eth0@ipv4::http://1.0.0.127.IN -ADDR.ARPA --stats -v
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Passer, Вы писали:
P>Я лично увидел несколько отличий от SVN которые по моему мнению не в лучшую сторону. P>Может дело во мне и много лет проведенных с svn не дают мне понять преимущества Гита? Или просто другим разработчикам гит лучше рекламируют?
СВН хорош в основном для маленьких локальных команд, когда люди находятся в одном месте и работают в одно время. Либо работают в разное время, но все их изменения не пересекаются во времени с другими командами, т.е. частота (рейт) коллизий по мержам минимальна.
Когда команд становится больше и их работа раскидана во времени, начинают всё больше и больше появляться коллизии при мержах, всё сложнее становиться создавать подветки, т.к. в свн'е обычно выдаёт права конкретный человек из группы, которого просто может не быть на месте в момент необходимости выдачи прав, а сделать изменение надо прямо здесь и сейчас. К тому же создание подветки в свн'е это отдельная административная процедура, которой свойственны все проблемы администрирования (сделаем потом/не надо так делать потому-что вот вася бы сделал по-другому/в нашем транке разрешено делать ветки только нам/и т.д.). В гите, как я понимаю, создание подветок выведено из поля административного функционала, где решение принимают третьи лица не относящиеся к команде но владеющие репозиторием, и возложена на саму команду.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Passer, Вы писали:
P>Поделитесь своим мнением.
В Git-е можно переписывать историю коммитов. Обычно, когда пишешь код, коммитишь всё подряд: законченное и не очень, какая-то идея пришла в голову — тяп-ляп-коммит. Твой бранч, пока не сделал пуш никто ничего не видит, и делаешь как тебе удобно. В SVN я бы уже таким образом 100500 раз билд поломал, и меня бы пришли бить больно. Но когда работа закончена, у меня в Git-е получается много маленьких коммитов, которые я теперь могу привести в порядок с помощью `git rebase`. Это и есть переписывание истории. Это настолько удобно, что я даже SVN репы сначала конвертирую в Git, работаю с ними в Git-е, а потом коммичу в SVN с помощью `git svn dcommit`.
В общем, Git надо попробовать самому. Его удобство познаётся на практике.
Здравствуйте, Sergey J. A., Вы писали:
SJA>>>rebase в SVN-е, это да — геморой, но опять же возможно. Я занимался таким несколько раз... C>>В том числе что бы оформить коммиты к ушедшему вперёд по коммитам svn. SJA>Это думаю можно не учитывать. Каждый SVN пользователь постоянно пользуется таким rebase при каждом апдейте. Только его бранч состоит из одного незакомиченного "комита". Этот "комит" ребейзится на пришедшую ревизию.
Ага, и если что-то пошло не так, то можно вешаться. Наученные опытом SVN-щики обычно вручную бекапят ценные изменения перед апдейтом. Git же по дефолту не допускает необратимых операций, если что-то не так, можно вернуться к предыдущему состоянию (stash или reflog) и повторить позже.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Passer, Вы писали:
P>Я лично увидел несколько отличий от SVN которые по моему мнению не в лучшую сторону.
Например ?
P>Может дело во мне и много лет проведенных с svn не дают мне понять преимущества Гита? Или просто другим разработчикам гит лучше рекламируют? P>Поделитесь своим мнением.
Лично для меня Git, как Mercurial или другая DSVC, удобен в первую очередь тем,
что можно иметь свою приватную копию репозитория и работать в ней, никому не
мешая и ни от кого не завися. Можно коммитить изменения в отсутствие доступа к
основному репозиторию, можно обмениваться изменениями с коллегой, да и вообще в
Git полее продуманная, а потому более удачная модель ветвления.
Некоторые типовые приемы работы с системой контроля версий в Git выполняются
банально меньшим числом команд и требуют меньшего знания о том, что происходит.
При этом самих команд в Git явно больше, чем в Subversion, и среди них есть много
очень полезных. Первое, что пришло в голову: разбивка одного большого коммита на
несколько более мелких.
Из недостатков я бы отметил несколько более высокий порог вхождения в Git.
Ну еще под Windows у него не настолько богатая инструментальная поддержка, как у
Subversion, но это со временем выправляется.
Здравствуйте, Passer, Вы писали:
P>Вспомнил что среди знакомых программистов только я остался пользоваться SVN все давно уже перешли на Git.
Надеюсь, ООП-то вы уже освоили? А то вдруг вы один на "процедурах" остались....
P> Почему все переходят?
Потому что это новый, более удобный подход к задаче управления версиями. Настолько удобный, что УБЕЖДАТЬ никого даже не понадобилось — все как один, кто через Hg, кто через Git, приходят в мир DVCS.
P>Я лично увидел несколько отличий от SVN которые по моему мнению не в лучшую сторону.
Ну... и...? Раз уж сказал, напиши какие!
P>Может дело во мне и много лет проведенных с svn не дают мне понять преимущества Гита?
Просто вопрос привычки. Фактически, до момента push'а, работа с DVCS — тот же самый svn! А когда над проектом собирается больше одного человека, преимущества DVCS встают в полный рост. То есть DVCS — это уже не просто "версия 1.1, версия 1.2", а _командный_ инструмент для совместной работы. Не считаю даже нужным обмусоливать преимущества — их надо СРОЧНО начинать учить, если не хотите остаться на обочине.
Спасибо всем за ответы. И за очень интересные мнения!!
P>>Вспомнил что среди знакомых программистов только я остался пользоваться SVN все давно уже перешли на Git.
B>Надеюсь, ООП-то вы уже освоили? А то вдруг вы один на "процедурах" остались....
вот как раз после гит-а за него возьмусь. говорят интересная вещь))
P>>Я лично увидел несколько отличий от SVN которые по моему мнению не в лучшую сторону.
B>Ну... и...? Раз уж сказал, напиши какие!
Недостатки мелкие. Ничего серьезного.
Слишком слишком слишком водянистые документации. Каждую главу буквально можно сжать в абзац. никого не смущает что по системе контроля версии есть целая книга)))) теперь я хочу связать git с maven. Сколько же придется копать что бы найти как это сделать и какие это даст преимущества))
Явный недостаток это плохая поддержка гуи.
И вот этот "git add" который еще сопровождается словами "ничего лишнего вы не зальете на сервер". У меня в папке проекта не хранится ничего лишнего(если она попала в папку проекта значит это имеет отношение к нему). Все .class файлы и остальное что не надо добавлять в репозитоий я ввожу в игнор. а с другой стороны в таком решении(как у git) всегда есть шанс что в списке "git status" в числе остальных можно не заметить и не добавить важный файл.
В черепашках svn удобно и наглядно можно посмотреть состояние проекта. Открыл в проводнике и видишь на папках галочки, значит закоммичино. Если нет, открыл папку и увидел что не закоммичено.
А еще плюсы распределенной системы мне не до конца ясны. Судя по документации при словах "это дистрибутивная система" и "если на сервере полетит винт у вас ничего не потеряется" разработчики с визгом должны побежать качать этот продукт(ибо других плюсов не сочли нужным написать).
А мне не совсем ясны его плюсы. И очевидный минус это размер, особенно если учесть что при изменениях хранится весь файл(сколько же это будет весить).
Плюсы скорости очевидны но настолько ли они важны? Это не то же самое что и поставить горячую кнопку на установку плагина в идее? или тоже самое?))
Плюс ощущение что каждый раз придется делать этот дифф, статус и все такое что бы случайно что то не упустить. Я не хочу работать специалистом по гит-у)) Мое дело писать код. А версионизация должна быть настолько простой и удобной что бы если нет конфликтов я о ней вообще не задумывался.
Здравствуйте, uncommon, Вы писали:
U>В Git-е можно переписывать историю коммитов. Обычно, когда пишешь код, коммитишь всё подряд: законченное и не очень, какая-то идея пришла в голову — тяп-ляп-коммит. Твой бранч, пока не сделал пуш никто ничего не видит, и делаешь как тебе удобно. В SVN я бы уже таким образом 100500 раз билд поломал, и меня бы пришли бить больно. Но когда работа закончена, у меня в Git-е получается много маленьких коммитов, которые я теперь могу привести в порядок с помощью `git rebase`. Это и есть переписывание истории. Это настолько удобно, что я даже SVN репы сначала конвертирую в Git, работаю с ними в Git-е, а потом коммичу в SVN с помощью `git svn dcommit`.
Справедливости ради стоит отметить, что SVN позволяет иметь приватные (но не локальные) комиты. Когда мне нужно что-то сломать — я делаю это в отдельном (персональном) бранче и вливаю в транк только после стабилизации.
rebase в SVN-е, это да — геморой, но опять же возможно. Я занимался таким несколько раз...
.>>>Вооот. Это основное отличие — в svn навязывается некий алгоритм использования. Если ему не следуешь — будут проблемы. SJA>>SVN вообще как C++ — куча способов выстрелить себе в ногу. Да, нужно следовать более жёстким правилам. .>У С++ есть хотя бы какие-то технические преимущества, об SVN такого не скажешь.
Они есть.
Возможность отобрать права на чтение на куски репозитория. Используем для контрактеров.
Sparse checkout — многие пользуются что бы держать проект на SSD. Иначе не помещается.
Лучшая обработка часто, но незначительно изменяющихся бинарников. Не пользуемся.
.>Конечно можно. "git reflog" живёт месяц, афаир.
Проверил. Да, очевидно gc не собирает свежие объекты.
.>Чтобы удалить всё — нужно очень хорошо постараться, написав несколько команд с кучей ключей, о которых, я уверен, ты и не слышал, и вряд ли ты сможешь запомнить, я гуглю/читаю ман каждый раз. Случайно такое не сделаешь, проще написать "rm -rf .". .>Сравни с "svn up", который может покорёжить твои изменения, так что восстановить — проблема.
Ок. 'rm -rf' (он же сдохший веник) в SVN удалит только последний кусок работы. У меня это пол дня максимум.
У меня нет статистики, сколько кто копит в гите локальных коммитов. Но судя по всему побольше.
SJA>>Ну я неявно имел в виду, что если увидел при апдейте страшные конфликты — тогда можно и прихраниться. .>Снова то же. А если не прихранился (забыл, поленился) — svn опять умывает руки.
Да именно так. Просто надо быть аккуратнее.
SJA>>Но да — проблема есть, хотя я и ни разу в неё не вступал. Надеюсь разработчики svn-а прикрутят checkpoint-ы ещё при моей жизни... .>Мне кажется, что скорее разработчики svn перейдут на git.
Ну, пока не перешли.
Решил пересмотреть используемые тулы и дополнительные аспекты управления проектами.
Вспомнил что среди знакомых программистов только я остался пользоваться SVN все давно уже перешли на Git. Почитал кучу документаций(должен сказать очень водянистые доки) но так и не нашел ответа на вопрос зачем переходить на него. Почему все переходят?
Я лично увидел несколько отличий от SVN которые по моему мнению не в лучшую сторону.
Может дело во мне и много лет проведенных с svn не дают мне понять преимущества Гита? Или просто другим разработчикам гит лучше рекламируют?
Здравствуйте, Passer, Вы писали:
P> Почему все переходят?
Если коротко, то все аргументы можно свести к слову "удобно" — один из немногих примеров, когда фраза "ПО написанное разработчиком для разработчиков" не несет в себе негативного оттенка.
Здравствуйте, Passer, Вы писали:
P>Здравствуйте.
P>Решил пересмотреть используемые тулы и дополнительные аспекты управления проектами.
P>Вспомнил что среди знакомых программистов только я остался пользоваться SVN все давно уже перешли на Git. Почитал кучу документаций(должен сказать очень водянистые доки) но так и не нашел ответа на вопрос зачем переходить на него. Почему все переходят?
P>Я лично увидел несколько отличий от SVN которые по моему мнению не в лучшую сторону.
P>Может дело во мне и много лет проведенных с svn не дают мне понять преимущества Гита? Или просто другим разработчикам гит лучше рекламируют?
P>Поделитесь своим мнением.
1 — быстрые "оффлайн" коммиты. В случае с svn это в любом случае долгий процесс но помимо прочего он ещё и требует обязательного подключения к серверу. Это не всегда удобно. То же с чекаутами и прочими командами. Пожалуй это самое большое удобство. Набрал команду и она моментально отработала.
2 — в целом всё работает очень реактивно. От svn-а воспоминания как от довольно тормозной программы. Для жизни хватает скорости, конечно, но в целом хочется лучшего.
3 — потенциально распределенная модель предлагает больше вариантов работы. Я, правда, не сталкивался с вариантами, отличными от центрального сервера + копия репозитория у каждого разработчика, но в целом, если будет необходимость, можно делать разные интересные вариации.
В дополнение ко всему сказанному просто добавлю, что git банально намного гибче и "легче" что-ли, что позволяет его использовать во многих ситуациях, где использование svn было бы затруднено.
Например, у меня была такая цепочка, как-то, сколоченная на скорую руку, когда нужно было работать на нескольких машинах, а возможности использовать интернет не было — репозиторий на машине, репозиторий на флешке, репозиторий на другой машине (такая цепочка origin-ов). Причем я мог работать независимо на двух машинах, в одном и том же коде, потом по флешке синхронизировать их и мерджить без проблем. Все это настраивается в три щелчка. В случае с svn тут были бы проблемы.
И таких кейсов (которые, скорее всего, будут гораздо изящнее, чем мой), думаю, большое количество. В общем, попробуйте гит, того стоит.
Здравствуйте, Passer, Вы писали:
P>Поделитесь своим мнением.
+ Быстрый.
+ Можно делать любые изменения в своей копии и коммитить их локально, не мешая другим. Также можно локально откатиться на нужную версию например, просмотреть историю изменений, сделать блейм, ну и т.д. — все это будет быстро, поскольку копия весь репозиотрий хранится локально (со всеми версиями). Позволяет организовывать коммиты в общий репозиторий более осмысленно.
+ Существование развитых онлайн сервисов на git (типа github/bitbucket/etc) где можно совместно работать над кодом в больших распределенных (по времени и пространству) командах (через pull request-ы например).
+ Поддержка из коробки (пусть не полная, но все же) во многих средствах разработки (в том числе в VS)
— Отсутвие прав внутри репозитория как таковых.
— Отсутсвие GUI уровня допустим черепахи (TortoiseSVN). rebase/squash — фантастик хоум юзер экспириенс..
— Тысяча и одна команда на все случаи жизни.
P>Вспомнил что среди знакомых программистов только я остался пользоваться SVN все давно уже перешли на Git. Почитал кучу документаций(должен сказать очень водянистые доки) но так и не нашел ответа на вопрос зачем переходить на него. Почему все переходят?
С чего ты взял что все переходят-то?
глянем здесь
February 2012
Git: 124,000 repositories (26% of total)
SVN: 265,883 repositories (57% of total)
June 2012
Git: 134,459 repositories (27% of total)
SVN: 267,499 repositories (54% of total)
October 2013
Git: 238,648 repositories (38% of total)
SVN: 291,920 repositories (46% of total)
April 2014
Git: 247,103 repositories (37% of total)
SVN: 324,895 repositories (48% of total)
в процентном отношении SVN упал, а в штучном вырос
Здравствуйте, rm822, Вы писали:
R>С чего ты взял что все переходят-то? R>глянем здесь R> Git: 247,103 repositories (37% of total) R> SVN: 324,895 repositories (48% of total)
Ерунда какая-то. На одном только github'е уже 10 миллионов репозиториев.
Здравствуйте, Passer, Вы писали:
C>>>Ерунда какая-то. R>>Это статы с https://www.openhub.net/ R>>Список проектов у них впечатляет P>Божее... Над мозилой работают 13000 разработчиков а над убунту 5000)))
и все работают за идею
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Passer, Вы писали:
P>Плюс ощущение что каждый раз придется делать этот дифф, статус и все такое что бы случайно что то не упустить. Я не хочу работать специалистом по гит-у)) Мое дело писать код. А версионизация должна быть настолько простой и удобной что бы если нет конфликтов я о ней вообще не задумывался.
Тогда Mercurial и, например, TortoiseHG.
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Passer, Вы писали:
P> Недостатки мелкие. Ничего серьезного. P> Слишком слишком слишком водянистые документации. Каждую главу буквально можно сжать в абзац. никого не смущает что по системе контроля версии есть целая книга)))) теперь я хочу связать git с maven. Сколько же придется копать что бы найти как это сделать и какие это даст преимущества))
По svn тоже есть книга, и не одна... Вообще говоря, гит прост, очень прост. Главное понять структуру данных, а там всего пяток объектов (objects):
— blob: бинарный контент
— tree: список name -> blob-id (т.е. файл) | tree-id (подкаталог), т.е. по сути snapshot твоего каталога проекта (working copy).
— commit: структура состоящая из имени автора, даты, списка id родительских коммитов, сообщения. Если родитель один — это обычный коммит, если два (или несколько!) — merge commit. Т.е. множество коммитов образуют иммутабельный DAG.
— ref: символическое имя, указатель на другой ref или на commit-id, частными случаями являются branch, tag, stash и прочее.
Каждый объект имеет id, который вычисляется как sha от его содержимого. Всё, остальное — алгоритмы над этой структурой данных. Плюс команды, которые комбинируют другие команды, например "commit -a" это комбинация add + commit, "pull" это fetch + merge, и т.п.
В общем попробуй изучение начать с этой главы, она маленькая, улучшает понимание на порядок.
P> Явный недостаток это плохая поддержка гуи.
tortoisegit пробовал уже? Переезжающему с tortoisesvn будет просто освоиться.
А вообще, гуи слишком слаб чтобы все функции выразить, либо он будет по сложности как MS Word.
P> И вот этот "git add" который еще сопровождается словами "ничего лишнего вы не зальете на сервер". У меня в папке проекта не хранится ничего лишнего(если она попала в папку проекта значит это имеет отношение к нему). Все .class файлы и остальное что не надо добавлять в репозитоий я ввожу в игнор. а с другой стороны в таком решении(как у git) всегда есть шанс что в списке "git status" в числе остальных можно не заметить и не добавить важный файл.
"git commit -a" будет эквивалентен свн-овскому коммиту.
"git add --all && git commit" позволяет закомитить все изменения сразу, включая переименованные, перемещённые, удалённые, добавленные файлы. В svn вроде такое не сделать.
Команда add это по сути подготовка нового tree (его называют stage или index) который ты готовишься _атомарно_ закоммитить. Скажем, это позволяет сделать коммит только части изменений, притом любой, вплоть до отдельной строчки. svn тоже так не умеет.
P> В черепашках svn удобно и наглядно можно посмотреть состояние проекта. Открыл в проводнике и видишь на папках галочки, значит закоммичино. Если нет, открыл папку и увидел что не закоммичено.
И кто пользуется этим Проводником? Видимо, ты лучшего ничего не видел. В intellij idea подсвечиваются изменения вплоть до каждой строчки или символа, плюс тут же плоский список изменённых файлов.
Попробуй ещё Atlassian SourceTree.
P> А еще плюсы распределенной системы мне не до конца ясны. Судя по документации при словах "это дистрибутивная система" и "если на сервере полетит винт у вас ничего не потеряется" разработчики с визгом должны побежать качать этот продукт(ибо других плюсов не сочли нужным написать).
Если попробовать подобрать аналогию, чтобы выразить эмоции вызванные различием, это примерно как работа через монохромный терминал на каком-то мейнфрейме, где ещё работает куча таких же неудачников как ты, и твой личный лаптоп класса macbook pro, и у всех разработчиков такие же, вы только иногда, когда есть настроение, в чятике обмениваетесь чмокамикоммитами.
P> А мне не совсем ясны его плюсы. И очевидный минус это размер, особенно если учесть что при изменениях хранится весь файл(сколько же это будет весить).
Вся история Linux Kernel c 2005 года, 320k коммитов, 40k файлов, занимает около 600Mb. Умная структура данных, хорошая компрессия.
P> Плюсы скорости очевидны но настолько ли они важны? Это не то же самое что и поставить горячую кнопку на установку плагина в идее? или тоже самое?))
Когда создание бранча или коммита занимает 20 миллисекунд вместо 20 секунд — совершенно меняется стиль работы.
P> Плюс ощущение что каждый раз придется делать этот дифф, статус и все такое что бы случайно что то не упустить. Я не хочу работать специалистом по гит-у)) Мое дело писать код. А версионизация должна быть настолько простой и удобной что бы если нет конфликтов я о ней вообще не задумывался.
Если ты один, то запомни "git add -A && git commit && git push" или даже alias сделай. А если не один, или поддерживаешь несколько направлений разработки, или любишь эксперименты всякие, то придётся думать — а как запретить этим криворуким ломать билд, а как сделать изменение, чтобы сразу в нескольких ветках, да как потом выяснить что где сделано, а как отложить это на потом, а как потом это причесать красиво, т.п. — вот тут начинаются хитрости.
Здравствуйте, ., Вы писали:
.>По svn тоже есть книга, и не одна... Вообще говоря, гит прост, очень прост. Главное понять структуру данных, а там всего пяток объектов (objects):
я лично изучал эту структуру данных как возможную идею для реализации программы инкрементального бекапа. но для повседневного пользования программой знать её нафиг не нужно
Здравствуйте, BulatZiganshin, Вы писали:
BZ> я лично изучал эту структуру данных как возможную идею для реализации программы инкрементального бекапа. но для повседневного пользования программой знать её нафиг не нужно
Не нужно, согласен. Но жутко упрощает понимание всего остального, да и интересно, по-моему.
Здравствуйте, Sergey J. A., Вы писали:
SJA>rebase в SVN-е, это да — геморой, но опять же возможно. Я занимался таким несколько раз...
Rebase в git'e — это быстро, просто и легко. Постоянно юзаю. В том числе что бы оформить коммиты к ушедшему вперёд по коммитам svn.
Здравствуйте, Clerk, Вы писали:
SJA>>rebase в SVN-е, это да — геморой, но опять же возможно. Я занимался таким несколько раз... C>В том числе что бы оформить коммиты к ушедшему вперёд по коммитам svn.
Это думаю можно не учитывать. Каждый SVN пользователь постоянно пользуется таким rebase при каждом апдейте. Только его бранч состоит из одного незакомиченного "комита". Этот "комит" ребейзится на пришедшую ревизию.
Здравствуйте, ., Вы писали:
SJA>>>>rebase в SVN-е, это да — геморой, но опять же возможно. Я занимался таким несколько раз... C>>>В том числе что бы оформить коммиты к ушедшему вперёд по коммитам svn. SJA>>Это думаю можно не учитывать. Каждый SVN пользователь постоянно пользуется таким rebase при каждом апдейте. Только его бранч состоит из одного незакомиченного "комита". Этот "комит" ребейзится на пришедшую ревизию. .>Ага, и если что-то пошло не так, то можно вешаться. Наученные опытом SVN-щики обычно вручную бекапят ценные изменения перед апдейтом. Git же по дефолту не допускает необратимых операций, если что-то не так, можно вернуться к предыдущему состоянию (stash или reflog) и повторить позже.
Это конечно жирный минус.
Однако для опытного (а не наученного опытом) пользователя всё не столь печально:
Если обновляться почаще, конфликты будут возникать значительно реже(я уж и не помню когда они у меня были на update).
Если работать в персональном бранче и комитить всё перед sync merge — ничего теряться не будет, как и в git.
Ну и в конце концов ничего из ценно написанного ведь не теряется — всё висит в конфликтах.
Здравствуйте, Sergey J. A., Вы писали:
SJA> Это конечно жирный минус.
SJA> Однако для опытного (а не наученного опытом) пользователя всё не столь печально: SJA> Если обновляться почаще, конфликты будут возникать значительно реже(я уж и не помню когда они у меня были на update). SJA> Если работать в персональном бранче и комитить всё перед sync merge — ничего теряться не будет, как и в git.
Вооот. Это основное отличие — в svn навязывается некий алгоритм использования. Если ему не следуешь — будут проблемы. В git делай что душе угодно, в каком хочешь порядке. Могут навязывать лишь другие, когда обмениваешься изменениями (например, делаешь push в "центральный" репо).
SJA> Ну и в конце концов ничего из ценно написанного ведь не теряется — всё висит в конфликтах.
Начинаешь разрешать конфликты и вдруг что-то не сростается. И решаешь повторить мерж чуть иначе, отложить на потом, или поменять кое-что перед мержем, и т.п., а если бэкапов не оставил — сам виноват, вешайся.
Здравствуйте, ., Вы писали:
SJA>> Это конечно жирный минус.
SJA>> Однако для опытного (а не наученного опытом) пользователя всё не столь печально: SJA>> Если обновляться почаще, конфликты будут возникать значительно реже(я уж и не помню когда они у меня были на update). SJA>> Если работать в персональном бранче и комитить всё перед sync merge — ничего теряться не будет, как и в git. .>Вооот. Это основное отличие — в svn навязывается некий алгоритм использования. Если ему не следуешь — будут проблемы.
SVN вообще как C++ — куча способов выстрелить себе в ногу. Да, нужно следовать более жёстким правилам.
.>В git делай что душе угодно, в каком хочешь порядке. Могут навязывать лишь другие, когда обмениваешься изменениями (например, делаешь push в "центральный" репо).
Что хочешь? Хм...
git reset --hard origin/master
git gc
Так можно? (Не уверен насчёт синтаксиса, надеюсь идея понятна)
SJA>> Ну и в конце концов ничего из ценно написанного ведь не теряется — всё висит в конфликтах. .>Начинаешь разрешать конфликты и вдруг что-то не сростается. И решаешь повторить мерж чуть иначе, отложить на потом, или поменять кое-что перед мержем, и т.п., а если бэкапов не оставил — сам виноват, вешайся.
Ну я неявно имел в виду, что если увидел при апдейте страшные конфликты — тогда можно и прихраниться.
Но да — проблема есть, хотя я и ни разу в неё не вступал. Надеюсь разработчики svn-а прикрутят checkpoint-ы ещё при моей жизни...
Здравствуйте, Passer, Вы писали:
P>Может дело во мне и много лет проведенных с svn не дают мне понять преимущества Гита? Или просто другим разработчикам гит лучше рекламируют?
В связи с тем, что git — это dvcs, а svn — нет, то много плюшек git в svn банально не существуют — например, поиск по истории возможен и при отсутствии соединения с сервером,
лёгкий и безгеморойный rebase, лёгкие бранчи и т.д. Работать можно и с svn, но с git — гораздо удобнее.
Здравствуйте, Sergey J. A., Вы писали:
.>>Вооот. Это основное отличие — в svn навязывается некий алгоритм использования. Если ему не следуешь — будут проблемы. SJA>SVN вообще как C++ — куча способов выстрелить себе в ногу. Да, нужно следовать более жёстким правилам.
У С++ есть хотя бы какие-то технические преимущества, об SVN такого не скажешь.
.>>В git делай что душе угодно, в каком хочешь порядке. Могут навязывать лишь другие, когда обмениваешься изменениями (например, делаешь push в "центральный" репо). SJA>Что хочешь? Хм...
Угу.
SJA>git reset --hard origin/master SJA>git gc SJA>Так можно? (Не уверен насчёт синтаксиса, надеюсь идея понятна)
Конечно можно. "git reflog" живёт месяц, афаир.
Чтобы удалить всё — нужно очень хорошо постараться, написав несколько команд с кучей ключей, о которых, я уверен, ты и не слышал, и вряд ли ты сможешь запомнить, я гуглю/читаю ман каждый раз. Случайно такое не сделаешь, проще написать "rm -rf .".
Сравни с "svn up", который может покорёжить твои изменения, так что восстановить — проблема.
SJA>>> Ну и в конце концов ничего из ценно написанного ведь не теряется — всё висит в конфликтах. .>>Начинаешь разрешать конфликты и вдруг что-то не сростается. И решаешь повторить мерж чуть иначе, отложить на потом, или поменять кое-что перед мержем, и т.п., а если бэкапов не оставил — сам виноват, вешайся. SJA>Ну я неявно имел в виду, что если увидел при апдейте страшные конфликты — тогда можно и прихраниться.
Снова то же. А если не прихранился (забыл, поленился) — svn опять умывает руки.
SJA>Но да — проблема есть, хотя я и ни разу в неё не вступал. Надеюсь разработчики svn-а прикрутят checkpoint-ы ещё при моей жизни...
Мне кажется, что скорее разработчики svn перейдут на git.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, vsb, Вы писали:
vsb>3 — потенциально распределенная модель предлагает больше вариантов работы. Я, правда, не сталкивался с вариантами, отличными от центрального сервера + копия репозитория у каждого разработчика, но в целом, если будет необходимость , можно делать разные интересные вариации.
ключевые слова выделил, все изза этого пользуют, но эта мифическая "необходимость" так и не наступает
зато геморра от мержа выше крыши
Здравствуйте, Sergey J. A., Вы писали:
SJA>Они есть. SJA>Возможность отобрать права на чтение на куски репозитория. Используем для контрактеров.
Да, с этим согласен, в гит это хоть и делается, но довольно неочевидно (отпочковывается каталог как отдельный репо и потом мержится обратно как subtree). Но это тоже обычно означает непродуманное разбиение на модули, проект-свалка. Так что можно ещё поспорить — хорошая ли это фича, когда факт её применения обычно означает, что с проектом что-то не так.
SJA>Sparse checkout — многие пользуются что бы держать проект на SSD. Иначе не помещается. Да тоже можно, даже круче (например, исключения поддерживаются). Только обычно это означает, что проект какой-то сильно особенный, либо, скорее всего, непродуманное разбиение на модули, что вызывает кучу других проблем.
SJA>Лучшая обработка часто, но незначительно изменяющихся бинарников. Не пользуемся.
Бинарники в бинарых репо держать надо (ну или git annex). Иначе проблемы с мержами — разные бинарники — и что же делать при конфликтах?
SJA>А, ну нашёл.
SJA>git reset --hard origin/master SJA>git reflog expire --expire-unreachable=now --all SJA>git gc --prune=now
SJA>всё исключительно средствами гита.
Ну понятно, ногу можно и ложкой отпилить. Но случайно такое никак не сделаешь. Раз решил такое сделать, то значит знаешь что делаешь. svnadmin тоже может много что сделать, например, злоумышленник может незаметно подправить историю.
.>>Чтобы удалить всё — нужно очень хорошо постараться, написав несколько команд с кучей ключей, о которых, я уверен, ты и не слышал, и вряд ли ты сможешь запомнить, я гуглю/читаю ман каждый раз. Случайно такое не сделаешь, проще написать "rm -rf .". .>>Сравни с "svn up", который может покорёжить твои изменения, так что восстановить — проблема.
SJA>Ок. 'rm -rf' (он же сдохший веник) в SVN удалит только последний кусок работы. У меня это пол дня максимум. SJA>У меня нет статистики, сколько кто копит в гите локальных коммитов. Но судя по всему побольше.
Если ты в svn коммитишься каждые полдня, то и в гите будешь так же пушиться, а то и чаще, т.к. команды выполняются раз в пять быстрее. В чём разница-то?
SJA>>>Ну я неявно имел в виду, что если увидел при апдейте страшные конфликты — тогда можно и прихраниться. .>>Снова то же. А если не прихранился (забыл, поленился) — svn опять умывает руки. SJA>Да именно так. Просто надо быть аккуратнее.
В том-то и поинт — с гитом не надо.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
SJA>>Они есть. SJA>>Возможность отобрать права на чтение на куски репозитория. Используем для контрактеров. .>Да, с этим согласен, в гит это хоть и делается, но довольно неочевидно (отпочковывается каталог как отдельный репо и потом мержится обратно как subtree). Но это тоже обычно означает непродуманное разбиение на модули, проект-свалка. Так что можно ещё поспорить — хорошая ли это фича, когда факт её применения обычно означает, что с проектом что-то не так.
Именно наш случай — проект свалка. Это одна из причин почему был выбран SVN — что бы можно было быстро сконвертировать часть проектов с VSS-а и пользоваться нормальным VCS.
git потребовал бы больше усилий (причём моих личных, неоплачиваемых). Ещё осталось процентов 60 на VSS-е...
Если бы мне нужно было ещё и всё резать всё на модули...
SJA>>Sparse checkout — многие пользуются что бы держать проект на SSD. Иначе не помещается. .>Да тоже можно, даже круче (например, исключения поддерживаются). Только обычно это означает, что проект какой-то сильно особенный, либо, скорее всего, непродуманное разбиение на модули, что вызывает кучу других проблем.
Если я правильно понял — это не совсем настоящий sparse. Git всё равно скачивает всю историю, только чекаутит не все файлы.
SJA>>Лучшая обработка часто, но незначительно изменяющихся бинарников. Не пользуемся. .>Бинарники в бинарых репо держать надо (ну или git annex). Иначе проблемы с мержами — разные бинарники — и что же делать при конфликтах?
Не могу ничего сказать. Стараюсь всеми силами недопустить в SVN бинарники. Но как факт — svn справляется лучше.
Что за бинарные репы? Мне ща надо думать о прикручивании некого artifat managementa... Пока ничего хорошего не придумывается.
.>Ну понятно, ногу можно и ложкой отпилить. Но случайно такое никак не сделаешь. Раз решил такое сделать, то значит знаешь что делаешь. svnadmin тоже может много что сделать, например, злоумышленник может незаметно подправить историю.
Про случайно/неслучайно речь вроде не шло. "В git делай что душе угодно, в каком хочешь порядке". Я сделал — результат хуже чем аналогичный в svn. В svn можно уничтожить только незакомиченные данные.
Про svnadmin непонятно, мы вроде обсуждаем клиентскую сторону. Это можно в отдельный минус записать.
SJA>>У меня нет статистики, сколько кто копит в гите локальных коммитов. Но судя по всему побольше. .>Если ты в svn коммитишься каждые полдня, то и в гите будешь так же пушиться, а то и чаще, т.к. команды выполняются раз в пять быстрее. В чём разница-то?
Не буду. Я комичу раз в пол дня не потому что это медленно
Про скорость это аргумент уже достал, если честно.
viu43091@BYM1D048 /cygdrive/c/work/gfz-tools
$ time svn ci -m "test commit"
Sending README
Transmitting file data .
Committed revision 39512.
real 0m3.282s
user 0m0.015s
sys 0m0.093s
viu43091@BYM1D048 /cygdrive/c/work/pdf-hilite.dev
$ time git commit -a -m "test commit"
[test f3786e6] test commit
1 file changed, 3 deletions(-)
real 0m0.274s
user 0m0.015s
sys 0m0.140s
viu43091@BYM1D048 /cygdrive/c/work/pdf-hilite.dev
$ time git push
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 328 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To file:///\\srv-tfs\git\pdf-hilite
50b1420..f3786e6 test -> test
real 0m1.252s
user 0m0.015s
sys 0m0.109s
Итого: svn 3.2 секунды. Сюда входит так же выполнение достаточно тяжеловесных хуков.
git — 1.252 + 0.274 = 1.5
Разница всего в 2 раза.
Я над комментарием к комиту дольше думаю + быстрое ревью отсылаемых изменений.
Гит мне сэкономит хорошо если 5%. Уж тогда заживём...
SJA>>>>Ну я неявно имел в виду, что если увидел при апдейте страшные конфликты — тогда можно и прихраниться. .>>>Снова то же. А если не прихранился (забыл, поленился) — svn опять умывает руки. SJA>>Да именно так. Просто надо быть аккуратнее. .>В том-то и поинт — с гитом не надо.
Поинт есть, я не спорю. Но это не "ах, все срочно отказываемся от SVN-а, в ём невозможно работать"
Здравствуйте, ., Вы писали:
SJA>>Ок. 'rm -rf' (он же сдохший веник) в SVN удалит только последний кусок работы. У меня это пол дня максимум. SJA>>У меня нет статистики, сколько кто копит в гите локальных коммитов. Но судя по всему побольше. .>Если ты в svn коммитишься каждые полдня, то и в гите будешь так же пушиться, а то и чаще, т.к. команды выполняются раз в пять быстрее. В чём разница-то?
А как с бранчами или аналогичной функциональностью в svn?
Вот работаю над фичей — сделал новый бранч и начал в нём изменения. А тут нужно срочно баг фиксить. В бранче новой фичи комичу изменения
и завожу новый бранч под баг. Начал фиксить — присылают ещё более срочный баг. Коммичу что сделал в бранче бага1 и создаю бранч под баг2.
Заканчиваю с багом номер2 и отправляю изменения в основную ветку. Переключаюсь в баг1 и делаю rebase на основную ветку. Заканчиваю фикс бага1
и отправляю изменения в основную ветку. Возвращаюсь в бранч фичи, делаю rebase на основную ветку и т.д. История — чистая, код разных фич
друг другу не мешает.
Вопрос — как сохранять эти временные недоизменения в svn?
Здравствуйте, ., Вы писали:
.>Ага, и если что-то пошло не так, то можно вешаться. Наученные опытом SVN-щики обычно вручную бекапят ценные изменения перед апдейтом. Git же по дефолту не допускает необратимых операций, если что-то не так, можно вернуться к предыдущему состоянию (stash или reflog) и повторить позже.
Для обычного пользования reflog — это уже тяжёлая артиллерия. Обычно всё заканчивается устранением конфликтов или в особо тяжких случаях git rebase abort.
Здравствуйте, Clerk, Вы писали:
C>А как с бранчами или аналогичной функциональностью в svn? C>Вот работаю над фичей — сделал новый бранч и начал в нём изменения. А тут нужно срочно баг фиксить. В бранче новой фичи комичу изменения C>и завожу новый бранч под баг. Начал фиксить — присылают ещё более срочный баг. Коммичу что сделал в бранче бага1 и создаю бранч под баг2. C>Заканчиваю с багом номер2 и отправляю изменения в основную ветку. Переключаюсь в баг1 и делаю rebase на основную ветку. Заканчиваю фикс бага1 C>и отправляю изменения в основную ветку. Возвращаюсь в бранч фичи, делаю rebase на основную ветку и т.д. История — чистая, код разных фич C>друг другу не мешает. C>Вопрос — как сохранять эти временные недоизменения в svn?
Если баги достаточно маленькие я скорее сохраню патч. А потом его применю обратно.
Если исходить из того, что все работы достаточно большие, то мои действия будут слабо отличаться от перечисленных.
Вместо rebase будет sync merge. А так — те же бранчи. История возможно будет кривее — svn log -g не всегда адекватен.
В целом в svn работать с бранчами сложнее, но я не стесняюсь.
SJA>>В целом в svn работать с бранчами сложнее, но я не стесняюсь.
C>На работе центральный сервер — svn, локально у разработчиков — у кого-то svn, у кого-то git. C>С git'ом жизнь проще.
Ну так я и не отрицаю.
Я только против мнения, что svn ни на что не годится и им пользоваться вообще невозможно. Некоторые уверяют, что там даже трёхстороннего мержа нет.
Здравствуйте, The Passenger, Вы писали:
vsb>>3 — потенциально распределенная модель предлагает больше вариантов работы. Я, правда, не сталкивался с вариантами, отличными от центрального сервера + копия репозитория у каждого разработчика, но в целом, если будет необходимость , можно делать разные интересные вариации.
TP>ключевые слова выделил, все изза этого пользуют, но эта мифическая "необходимость" так и не наступает
У кого-то не настаёт, у кого-то настаёт.
TP>зато геморра от мержа выше крыши
В чём гемор? По-моему уж в мерже гит точно не хуже svn.
Здравствуйте, Passer, Вы писали:
P>Поделитесь своим мнением.
Пытался пользоваться mercurial. Выяснил, что он не совместим с моими мозгами, ибо те вывихнулись в попытке понять, что происходит, но так нифига и не поняли. Особенно выносил мозг мёрдж (2 ветки, в каждой есть независимые изменения, в какой-то момент надо смерждить изменения из одной ветки в другую). Пока сделал, наделал пару десятков локальных коммитов с разной степенью бредовости содержимого. Добил красноглазый гуй у tortoisehg с аццким количеством всяких галочек, кнопочек и полей ввода с непонятными мне функциями. В процессе чуть не сломал клаву — после двух часов попыток добиться того, чтобы закоммитилось именно то, что мне нужно, нервы сдавали.
Плюнул и ушёл обратно на tfs — он простой, как пробка, и напортачить там нереально (без использования админских утилит). Мораль — проще надо быть, и люди к тебе потянутся!
Здравствуйте, Sergey J. A., Вы писали:
SJA> Именно наш случай — проект свалка. Это одна из причин почему был выбран SVN — что бы можно было быстро сконвертировать часть проектов с VSS-а и пользоваться нормальным VCS.
Хе-хе. Вооот. А git ещё более нормальный vcs.
SJA> git потребовал бы больше усилий (причём моих личных, неоплачиваемых). Ещё осталось процентов 60 на VSS-е... SJA> Если бы мне нужно было ещё и всё резать всё на модули...
Резать всё равно придётся, рано или поздно. Но это немного другой вопрос — legacy systems. Кобол местами до сих пор используют, но рекомендовать его использовать — только вредить.
SJA> Если я правильно понял — это не совсем настоящий sparse. Git всё равно скачивает всю историю, только чекаутит не все файлы.
В этом смысле да. Если бинари в репо не толкать, то ничего страшного. Вроде байку рассказывали, что клон репозитория mozilla (?) со всей историей занимал меньше, чем working copy репозитория svn.
SJA> SJA>>Лучшая обработка часто, но незначительно изменяющихся бинарников. Не пользуемся.
SJA> .>Бинарники в бинарых репо держать надо (ну или git annex). Иначе проблемы с мержами — разные бинарники — и что же делать при конфликтах?
SJA> Не могу ничего сказать. Стараюсь всеми силами недопустить в SVN бинарники. Но как факт — svn справляется лучше. SJA> Что за бинарные репы? Мне ща надо думать о прикручивании некого artifat managementa... Пока ничего хорошего не придумывается.
Правильно. Надо, Федя, надо, прикручивание неизбежно для любого несдохшего проекта, это можно лишь болезненно оттягивать. А какой стек технологий то? В java мире — nexus/artifactory.
SJA> .>Ну понятно, ногу можно и ложкой отпилить. Но случайно такое никак не сделаешь. Раз решил такое сделать, то значит знаешь что делаешь. svnadmin тоже может много что сделать, например, злоумышленник может незаметно подправить историю. SJA> Про случайно/неслучайно речь вроде не шло. "В git делай что душе угодно, в каком хочешь порядке". Я сделал — результат хуже чем аналогичный в svn. В svn можно уничтожить только незакомиченные данные.
В гите будет аналогом незапушенные данные.
SJA> Про svnadmin непонятно, мы вроде обсуждаем клиентскую сторону. Это можно в отдельный минус записать.
Просто надо осторожно сравнивать. Например, чтобы у гита серверная сторона была, какой-нибудь repository manager.
SJA> .>Если ты в svn коммитишься каждые полдня, то и в гите будешь так же пушиться, а то и чаще, т.к. команды выполняются раз в пять быстрее. В чём разница-то? SJA> Не буду. Я комичу раз в пол дня не потому что это медленно
А почему же тогда? Почему-то после перехода на гит я коммичу раз в десять чаще. Пушу так же, раз в пол дня, или даже чаще — зависит — багфиксы делаю или новые фичи.
SJA> Про скорость это аргумент уже достал, если честно.
Это простая операция, не так заметно. А update проекта 1000 каталогов? А переключение бранча? Создание бранча? Поиск в истории? Разница порой будет уже не пять раз, а пять тысяч.
SJA>
SJA> viu43091@BYM1D048 /cygdrive/c/work/pdf-hilite.dev
SJA> $ time git push
SJA> To file:///\\srv-tfs\git\pdf-hilite
SJA>
UNC вещь тормозная, ssh быстрый, особенно если ControlMaster включить. У меня обычно >0.5 секунды пуш на github, занятой сервер где-то в интернене, а не локалка.
SJA> Итого: svn 3.2 секунды. Сюда входит так же выполнение достаточно тяжеловесных хуков. SJA> git — 1.252 + 0.274 = 1.5 SJA> Разница всего в 2 раза.
А десять старушек — уже рубль.
SJA> Я над комментарием к комиту дольше думаю
Думаешь долго, т.к. коммит в svn — ответственный шаг, ошибся — коллеги бить придут толпой. В git — обыденность, можно потом поправить.
SJA>+ быстрое ревью отсылаемых изменений. Гит мне сэкономит хорошо если 5%. Уж тогда заживём...
Ооо... ревью. Аналог gerrit есть для svn? С gerrit и push становится обыденностью, в худшем случае ревьювер пнёт, а чаще просто билд-сервер гавкнет.
SJA> .>В том-то и поинт — с гитом не надо. SJA> Поинт есть, я не спорю. Но это не "ах, все срочно отказываемся от SVN-а, в ём невозможно работать"
А зачем вы от VSS отказываетесь? Ведь возможно же работать.
Здравствуйте, ., Вы писали:
SJA>> Именно наш случай — проект свалка. Это одна из причин почему был выбран SVN — что бы можно было быстро сконвертировать часть проектов с VSS-а и пользоваться нормальным VCS. .>Хе-хе. Вооот. А git ещё более нормальный vcs.
Есть определённые требования которым гит не удовлетворяет. Какая бы ни была это классная vcs во всех остальных отношениях — она всё ещё не удовлетворяет этим требованиям.
Не понимаю, что тут сложного?
Я ещё раз обрисую свою позицию и больше отвечать на "но лучше же" не буду.
При выборе тула я руководствовался (и другим советую) исходить из сравнительного анализа в *своей* ситуации с *доступными* ресурсами.
svn *в моей* ситуации был более выгоден, чем гит. И я его выбрал. Я учёл и скорость работы и возможность sparse checkout-а и наличие у меня опыта и привычки команды и много чего ещё. Что-то разумеется я не учёл.
В итоге всё пучком до сих пор. Мержит приемлимо, скорость достаточная, сон спокойный.
Пару новых проектов я завёл в git, все open source проекты тоже git. Полёт нормальный, нравится, но страстного желания переводить всё на гит пока не возникает.
.>Резать всё равно придётся, рано или поздно. Но это немного другой вопрос — legacy systems. Кобол местами до сих пор используют, но рекомендовать его использовать — только вредить.
Начинать писать на коболе — да, не стоит. Если надо поправить пару параметров — лучше не бросаться всё переписывать.
У меня нет никакого желания улучшать структуру проектов и избавляться от бинарников в VSS-е что бы потом, через лет так 5 (полагаю столько займёт переход на svn, если на это не будет выделятся ресурсы) перейти на git.
.>Правильно. Надо, Федя, надо, прикручивание неизбежно для любого несдохшего проекта, это можно лишь болезненно оттягивать. А какой стек технологий то? В java мире — nexus/artifactory.
С++/.NET. nexus/artifactory/archiva/nuget пробовал — немного не то. Хотя углубленно не копал.
.>Почему-то после перехода на гит я коммичу раз в десять чаще. Пушу так же, раз в пол дня, или даже чаще — зависит — багфиксы делаю или новые фичи.
Почему не пушишь в 10 раз чаше? Неужели пуш медленный?
Я то предпочитаю хорошо оформленные комиты, но если кого-то останавливает только скорость коммита/пуша... Мда.
SJA>> Про скорость это аргумент уже достал, если честно. .>Это простая операция, не так заметно. А update проекта 1000 каталогов? А переключение бранча? Создание бранча? Поиск в истории? Разница порой будет уже не пять раз, а пять тысяч.
Я сделаю замеры. Но вот, как с технической точки рения ты полагаешь, что update, branch, switch будет медленнее?
SJA>> Я над комментарием к комиту дольше думаю .>Думаешь долго, т.к. коммит в svn — ответственный шаг, ошибся — коллеги бить придут толпой. В git — обыденность, можно потом поправить.
Именно. Так в чём же преимущества быстрого пуша, если я всё равно буду думать перед ним?
SJA>>+ быстрое ревью отсылаемых изменений. Гит мне сэкономит хорошо если 5%. Уж тогда заживём... .>Ооо... ревью. Аналог gerrit есть для svn? С gerrit и push становится обыденностью, в худшем случае ревьювер пнёт, а чаще просто билд-сервер гавкнет.
Нет, у нас другой процесс. Но я имел в виду просмотр *своих* изменений перед комитом.
Здравствуйте, Sergey J. A., Вы писали:
SJA> .>Почему-то после перехода на гит я коммичу раз в десять чаще. Пушу так же, раз в пол дня, или даже чаще — зависит — багфиксы делаю или новые фичи.
SJA> Почему не пушишь в 10 раз чаше? Неужели пуш медленный? SJA> Я то предпочитаю хорошо оформленные комиты, но если кого-то останавливает только скорость коммита/пуша... Мда.
Подозреваю что тут имеется в виду что можно безболезненно коммитить промежуточные шаги и при необходимости выкидывать потом ненужное чтобы не загаживать историю коммитами типа "Откат коммита 100500 потому что зашел в тупик и надо делать по-другому"
SJA>> .>Почему-то после перехода на гит я коммичу раз в десять чаще. Пушу так же, раз в пол дня, или даже чаще — зависит — багфиксы делаю или новые фичи.
SJA>> Почему не пушишь в 10 раз чаше? Неужели пуш медленный? SJA>> Я то предпочитаю хорошо оформленные комиты, но если кого-то останавливает только скорость коммита/пуша... Мда.
D>Подозреваю что тут имеется в виду что можно безболезненно коммитить промежуточные шаги и при необходимости выкидывать потом ненужное чтобы не загаживать историю коммитами типа "Откат коммита 100500 потому что зашел в тупик и надо делать по-другому"
Это локальные комиты. Хорошая штука, но мы обсуждаем именно скорость работы и её как-то непонятное влияние на частоту svn-комитов(git-пушей)
Здравствуйте, Sergey J. A., Вы писали:
SJA> Это локальные комиты. Хорошая штука, но мы обсуждаем именно скорость работы и её как-то непонятное влияние на частоту svn-комитов(git-пушей)
Связь скорость работы<->частота коммитов/пушей придумал ты Скорость это не только коммиты пуши, но и например blame
Здравствуйте, Dziman, Вы писали:
D> SJA> Это локальные комиты. Хорошая штука, но мы обсуждаем именно скорость работы и её как-то непонятное влияние на частоту svn-комитов(git-пушей)
D> Связь скорость работы<->частота коммитов/пушей придумал ты Скорость это не только коммиты пуши, но и например blame
И, например, то что можно коммитить промежуточные шаги без замусоривания истории(squash перед push) или извращениями с ручными патчами.
Здравствуйте, Dziman, Вы писали:
SJA>> Это локальные комиты. Хорошая штука, но мы обсуждаем именно скорость работы и её как-то непонятное влияние на частоту svn-комитов(git-пушей)
D>Связь скорость работы<->частота коммитов/пушей придумал ты
Разве?
SJA> .>Если ты в svn коммитишься каждые полдня, то и в гите будешь так же пушиться, а то и чаще, т.к. команды выполняются раз в пять быстрее. В чём разница-то?
SJA> Не буду. Я комичу раз в пол дня не потому что это медленно
А почему же тогда? Почему-то после перехода на гит я коммичу раз в десять чаще. Пушу так же, раз в пол дня, или даже чаще — зависит — багфиксы делаю или новые фичи.
Человек уверен, что в связи с быстрыми комитами я стану пушиться чаще.
D>Скорость это не только коммиты пуши, но и например blame
Скорость blame в svn приемлемая. Прежде чем бросаться в сравнения прошу прочесть первый абзац тут: http://rsdn.ru/forum/tools/5786505.1
Здравствуйте, Sergey J. A., Вы писали:
SJA> SJA>> Это локальные комиты. Хорошая штука, но мы обсуждаем именно скорость работы и её как-то непонятное влияние на частоту svn-комитов(git-пушей)
SJA> D>Связь скорость работы<->частота коммитов/пушей придумал ты
SJA> Разве?
SJA>
SJA> SJA> .>Если ты в svn коммитишься каждые полдня, то и в гите будешь так же пушиться, а то и чаще, т.к. команды выполняются раз в пять быстрее. В чём разница-то?
SJA> SJA> Не буду. Я комичу раз в пол дня не потому что это медленно
SJA> А почему же тогда? Почему-то после перехода на гит я коммичу раз в десять чаще. Пушу так же, раз в пол дня, или даже чаще — зависит — багфиксы делаю или новые фичи.
SJA> Человек уверен, что в связи с быстрыми комитами я стану пушиться чаще.
Он же пишет, что коммиты стали чаще, но пуш примерно как был так и остался.
SJA> D>Скорость это не только коммиты пуши, но и например blame
SJA> Скорость blame в svn приемлемая. Прежде чем бросаться в сравнения прошу прочесть первый абзац тут: http://rsdn.ru/forum/tools/5786505.1
.>Это простая операция, не так заметно. А update проекта 1000 каталогов? А переключение бранча? Создание бранча? Поиск в истории? Разница порой будет уже не пять раз, а пять тысяч.
Итак наш транк.
Far говорит: Поиск закончен. Найдено файлов: 32996, папок: 3497
(само собой без .svn)
Чистил кэш утилитой RAMMap. Не уверен, насколько это адекватно, но другого способа я не знаю.
(RAMMap -> Menu -> Empty -> Empty Standby List)
Для git-а у меня нет аналогичного соответствующего репозитория, но есть другой, с кучей мелких файлов.
Far говорит: Поиск закончен. Найдено файлов: 66586, папок: 16077
status, cold: 19 sec
status, warm: 17.5 sec
log(100), cold: 0.25 sec
log(100), warm: 0.2 sec
И есть такой-же по содержанию и количеству файлов, но с меньшей историей для SVN-а
Far говорит: Поиск закончен. Найдено файлов: 63371, папок: 15589
status, cold: 7 sec
status, warm: 4.5 sec
log не имеет смысла, ибо там всего 4 записи
Итого.
1. Скорость SVN-а на моём рабочем репозитории вполне приемлема.
2. На большом количестве малких файлов git медленнее.
Пожалуй я откажусь от гита на большом репозитории в сторону svn-а...
На случай, если будут вопросы по проведению тестов:
SVN
cold update:
<clear cache>
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn up -r PREV
Updating '.':
D ...
A ...
U ...
U ...
Updated to revision 39519.
real 0m5.809s
user 0m0.031s
sys 0m0.078s
<clear cache>
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn up
Updating '.':
D ...
A ...
A ...
A ...
A ...
U ...
U ...
Updated to revision 39520.
real 0m5.559s
user 0m0.000s
sys 0m0.078s
Warm update:
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn up -r PREV
Updating '.':
D ...
A ...
U ...
U ...
Updated to revision 39519.
real 0m3.493s
user 0m0.047s
sys 0m0.062s
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn up
Updating '.':
D ...
A ...
A ...
A ...
A ...
U ...
U ...
Updated to revision 39520.
real 0m3.387s
user 0m0.015s
sys 0m0.078s
Status cold + warm:
<clear cache>
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn st
real 0m3.323s
user 0m0.015s
sys 0m0.094s
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn st
real 0m1.192s
user 0m0.015s
sys 0m0.062s
Branch + switch (warm)
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn copy "^/trunk" "^/branches/private/username/test-1" -m "Create test branch"
Committed revision 39521.
real 0m12.477s
user 0m0.031s
sys 0m0.062s
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn switch "^/branches/private/username/test-1"
At revision 39523.
real 0m4.055s
user 0m0.000s
sys 0m0.108s
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn switch "^/trunk"
At revision 39523.
real 0m3.574s
user 0m0.000s
sys 0m0.109s
log 100 enries, cold + warm
<clear cache>
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn log --limit 100 > NUL
real 0m1.544s
user 0m0.000s
sys 0m0.094s
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/gf/trunk
$ time svn log --limit 100 > NUL
real 0m1.179s
user 0m0.015s
sys 0m0.046s
==== git big repo
<clear cache>
viu43091@BYM1D048 /cygdrive/c/work/git.speed.test/links
$ time git status
# On branch master
#
# It took 2.96 seconds to enumerate untracked files. 'status -uno'
# may speed it up, but you have to be careful not to forget to add
# new files yourself (see 'git help status').
nothing to commit, working directory clean
real 0m19.364s
user 0m0.000s
sys 0m0.125s
viu43091@BYM1D048 /cygdrive/c/work/git.speed.test/links
$ time git status
# On branch master
#
# It took 2.90 seconds to enumerate untracked files. 'status -uno'
# may speed it up, but you have to be careful not to forget to add
# new files yourself (see 'git help status').
nothing to commit, working directory clean
real 0m17.455s
user 0m0.000s
sys 0m0.093s
viu43091@BYM1D048 /cygdrive/c/work/git.speed.test/links
$ time git log -100 > NUL
real 0m0.260s
user 0m0.000s
sys 0m0.093s
viu43091@BYM1D048 /cygdrive/c/work/git.speed.test/links
$ time git log -100 > NUL
real 0m0.204s
user 0m0.046s
sys 0m0.062s
=== big repo svn
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/wc
$ time svn status
real 0m7.146s
user 0m0.015s
sys 0m0.124s
viu43091@BYM1D048 /cygdrive/c/work/sv.speed.test/wc
$ time svn status
real 0m4.220s
user 0m0.000s
sys 0m0.077s
SJA>> SJA> .>Если ты в svn коммитишься каждые полдня, то и в гите будешь так же пушиться, а то и чаще , т.к. команды выполняются раз в пять быстрее. В чём разница-то?
SJA>> SJA> Не буду. Я комичу раз в пол дня не потому что это медленно
SJA>> А почему же тогда? Почему-то после перехода на гит я коммичу раз в десять чаще. Пушу так же, раз в пол дня, или даже чаще — зависит — багфиксы делаю или новые фичи.
D>Он же пишет, что коммиты стали чаще, но пуш примерно как был так и остался.
Я выделил. Я комичу, когда считаю, что комит готов, а не потому что это быстро/медленно. Если мои слова где-то были истрактованы в другом ключе — прошу перетрактовать.
D>Я не утверждаю что git подходит всем.
А я не утверждаю, что svn подходит всем. Или даже хотя бы в среднем лучше git-a
Здравствуйте, vsb, Вы писали:
vsb>У кого-то не настаёт, у кого-то настаёт.
TP>>зато геморра от мержа выше крыши
vsb>В чём гемор? По-моему уж в мерже гит точно не хуже svn.
а можно замержить и залить только пару файлов не трогая остальные файлы?
Здравствуйте, The Passenger, Вы писали:
TP>а можно замержить и залить только пару файлов не трогая остальные файлы?
Можно. Добавляются только нужные файлы и с ними производится коммит.
Здравствуйте, Clerk, Вы писали:
TP>>а можно замержить и залить только пару файлов не трогая остальные файлы? C>Можно. Добавляются только нужные файлы и с ними производится коммит.
И git запомнит, что вот эти файлы из этого комита замержены а остальное нет? При последующем мерже этого-же комита что произойдёт?
Здравствуйте, Sergey J. A., Вы писали:
SJA>И git запомнит, что вот эти файлы из этого комита замержены а остальное нет? При последующем мерже этого-же комита что произойдёт?
Git при мердже всегда оперирует коммитами, а не отдельными файлами. Либо мердж между коммитами успешный, либо нет, но операция всегда атомарная.
Если я правильно понял — у нас есть, например, 5 файлов. Нам нужно закомитить сейчас 2 из них. Создаём коммит с 2мя файлами.
Теперь нам нужно отправить этот комит в основную ветку. Так как у нас есть изменённые ещё 3 файла — временно отправляем эти 3 файла
в стэш (временное хранилище). После этого мержим наш 2х файловый комит в основую ветку. Если позникают неоднозначности — фиксим и заканчиваем мердж.
Достаём из стэша оставшихся 3 файла и продолжаем над ними работу.
Если же мы про rebase и возникающие конфликты — то, по умолчанию, их придётся каждый раз фиксить. Или же можно включить запоминатель разрешения
конфликтов http://git-scm.com/blog/2010/03/08/rerere.html и при повторном возникновении того же конфликта git сам всё сделает.
Здравствуйте, Sergey J. A., Вы писали:
D>>И что это показывает? Что дурная голова рукам покоя не дает?
SJA>Именно это и показывает. Не svn или git, а дурная голова. SJA>Заявленное "делай что хочешь" несколько не соответствует действительности.
Причём тут голова? Я о принципе наименьшего удивления. Я имею в виду, что если ты делаешь какие-то операции, которые не предназначены что-то удалять (скажем svn up), то в хорошей VCS не должна возникать ситуация, когда нельзя операции откатить, и приходится "присохраняться" тупым копированием в хз какие бекапы. А если ты явно набираешь три довольно хиртые команды чтобы всё уничтожить, то собственно это и ожидаешь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sergey J. A., Вы писали:
SJA> .>Это простая операция, не так заметно. А update проекта 1000 каталогов? А переключение бранча? Создание бранча? Поиск в истории? Разница порой будет уже не пять раз, а пять тысяч.
SJA> Итак наш транк. SJA> Far говорит: Поиск закончен. Найдено файлов: 32996, папок: 3497 SJA> (само собой без .svn)
SJA> Чистил кэш утилитой RAMMap. Не уверен, насколько это адекватно, но другого способа я не знаю. SJA> (RAMMap -> Menu -> Empty -> Empty Standby List)
Для более-менее честного тестирования импортируй svn в git ( git svn clone <svnurl> ) и гоняй тесты.
На моем достаточно маленьком репо (7200 ревизий svn, 2486 файлов, папки не считал):
log:
time svn log --limit 100 > /dev/null
svn log --limit 100 > /dev/null 0.02s user 0.01s system 2% cpu 1.274 total
time git log -n 100 > /dev/null
git log -n 100 > /dev/null 0.00s user 0.01s system 46% cpu 0.021 total
blame для первого попавшевося файла:
time svn blame Class.java >/dev/null
svn blame > /dev/null 0.04s user 0.04s system 4% cpu 1.748 total
time git blame Class.java > /dev/null
git blame > /dev/null 0.05s user 0.01s system 78% cpu 0.069 total
status:
time svn status > /dev/null
svn status > /dev/null 0.02s user 0.06s system 80% cpu 0.100 total
time git status > /dev/null
git status > /dev/null 0.01s user 0.01s system 69% cpu 0.024 total
В git делай что душе угодно, в каком хочешь порядке.
SJA> Моей душе было угодно выполнить эти хитрые команды. Я уж и незнаю, что больше сказать.
Буквоедство. Я же тебе порекомендовал: "rm -rf *", и не стоило время тратить на гугл в поисках этих трёх команд.
Здравствуйте, Sergey J. A., Вы писали:
SJA> В итоге всё пучком до сих пор. Мержит приемлимо, скорость достаточная, сон спокойный. SJA> Пару новых проектов я завёл в git, все open source проекты тоже git. Полёт нормальный, нравится, но страстного желания переводить всё на гит пока не возникает.
Хорошо. Сойдёмся на том, что для некоторых корявых легаси систем в некоторых случаях svn или zip в качестве vcs могут быть лучше.
SJA> Начинать писать на коболе — да, не стоит. Если надо поправить пару параметров — лучше не бросаться всё переписывать. SJA> У меня нет никакого желания улучшать структуру проектов и избавляться от бинарников в VSS-е что бы потом, через лет так 5 (полагаю столько займёт переход на svn, если на это не будет выделятся ресурсы) перейти на git.
Есть такая вещь как technical dept, если проект не сдохнет, то платить его таки придётся.
SJA> С++/.NET. nexus/artifactory/archiva/nuget пробовал — немного не то. Хотя углубленно не копал.
А что не срослось?
SJA> Почему не пушишь в 10 раз чаше? Неужели пуш медленный?
После того, как мы завели gerrit, пушить тоже стал чаще на порядок — накой самому гонять тесты и т.п., пусть CI-сервер трудится, он железный.
SJA> Я то предпочитаю хорошо оформленные комиты, но если кого-то останавливает только скорость коммита/пуша... Мда.
Я могу сделать коммит, заняться чем-то другим, закоммитить, потом обнаружить, что какой-то тест валится, чуток исправить код, поправить сообщение, дописать ссылки на пофикшенные баги когда полезу в багтрекер. В общем оформление коммита это превращается из события, требующего серьёзного и ответственного отношения (как будто правишь софт для ядерного реактора), а простой процесс с кучей черновиков (как будто правишь домашнюю страничку для васи пупкина).
SJA> Я сделаю замеры. Но вот, как с технической точки рения ты полагаешь, что update, branch, switch будет медленнее?
Практически все svn операции требуют сетевое соединение. У гит их только две — push и fetch (pull). Скажем, создание бранча в гите это просто создание файла в каталоге ".git/refs/heads/" размером 40 байт, пара миллисекунд, на порядок меньше типичного пинга в сети.
update (pull) если без локальных изменений — просто fetch (который, например, Atlassian SourceTree делает в бэкграунде), и fast-forward merge — просто распаковка изменённых файлов в working copy.
SJA> Нет, у нас другой процесс. Но я имел в виду просмотр *своих* изменений перед комитом.
Удобнее изменения делать и просматривать по частям: первый коммит — поправить форматирование кода, второй коммит — рефакторинг, третий коммит — новые изменения. Пушим пачкой.
Здравствуйте, ., Вы писали:
.>Хорошо. Сойдёмся на том, что для некоторых корявых легаси систем в некоторых случаях svn или zip в качестве vcs могут быть лучше.
Если разницы между zip и svn не видно, то и смысла что-то обсуждать не вижу.
Здравствуйте, Clerk, Вы писали:
C>Если я правильно понял — у нас есть, например, 5 файлов. Нам нужно закомитить сейчас 2 из них. Создаём коммит с 2мя файлами. C>Теперь нам нужно отправить этот комит в основную ветку. Так как у нас есть изменённые ещё 3 файла — временно отправляем эти 3 файла C>в стэш (временное хранилище). После этого мержим наш 2х файловый комит в основую ветку. Если позникают неоднозначности — фиксим и заканчиваем мердж. C>Достаём из стэша оставшихся 3 файла и продолжаем над ними работу.
это уже звучит как минимум не "просто"
... а теперь еше усложним — представим что пока я правил эти 2 файла на остальные другие разрабы
уже повесили 100500 коммитов
я на самом деле не спец по гиту, просто бесит последняя программерская тенденция использовать то что модно а не что реально надо
Здравствуйте, The Passenger, Вы писали:
TP>это уже звучит как минимум не "просто"
TP>... а теперь еше усложним — представим что пока я правил эти 2 файла на остальные другие разрабы TP>уже повесили 100500 коммитов
Да хоть сто тысяч миллионов. Git сам всё замержит.
TP>я на самом деле не спец по гиту, просто бесит последняя программерская тенденция использовать то что модно а не что реально надо
Люди используют то, что им удобно. Лёгкие бранчи и ненавязчивый мерж/ребэйз в svn тупо отсутствуют.
Здравствуйте, Sergey J. A., Вы писали:
.>>Хорошо. Сойдёмся на том, что для некоторых корявых легаси систем в некоторых случаях svn или zip в качестве vcs могут быть лучше. SJA>Если разницы между zip и svn не видно, то и смысла что-то обсуждать не вижу.
Разницы столько же как и между svn и git. А там уже от зрения зависит — кто что видит.
Шаг между CVCS и DVCS примерно такой же как и между бэкапами и VCS.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
D>Для более-менее честного тестирования импортируй svn в git ( git svn clone <svnurl> ) и гоняй тесты.
Чё-то не могу найти какой сервер можно запользовать. Обязательно чтоб умел аутентификацию и хотя бы базовую авторизацию. Желательно также чтоб легко инсталировался.
Есть такое на примете?
P.S. под винду
==
не актуально. вроде завёлся некий bonobo сервер
Здравствуйте, Sergey J. A., Вы писали:
SJA> D>Для более-менее честного тестирования импортируй svn в git ( git svn clone <svnurl> ) и гоняй тесты.
SJA> Чё-то не могу найти какой сервер можно запользовать. Обязательно чтоб умел аутентификацию и хотя бы базовую авторизацию. Желательно также чтоб легко инсталировался.
SJA> Есть такое на примете?
SJA> P.S. под винду
SJA> == SJA> не актуально. вроде завёлся некий bonobo сервер
Для чего сервер чтобы протестировать скорость работы с репозиторием git?
Здравствуйте, Dziman, Вы писали:
D>Для чего сервер чтобы протестировать скорость работы с репозиторием git?
Я ж хочу протестировать скорость в реальных условиях. Девелоперы обычно пушат свои изменения и пулят чужие.
Здравствуйте, Sergey J. A., Вы писали:
SJA> D>Для чего сервер чтобы протестировать скорость работы с репозиторием git?
SJA> Я ж хочу протестировать скорость в реальных условиях. Девелоперы обычно пушат свои изменения и пулят чужие.
Видимо ты всё-таки не понимаешь про какую скорость речь.
Здравствуйте, Dziman, Вы писали:
SJA>> Я ж хочу протестировать скорость в реальных условиях. Девелоперы обычно пушат свои изменения и пулят чужие.
D>Видимо ты всё-таки не понимаешь про какую скорость речь.
Поскольку равноценного аналога git commit в svn нет, то их и сравнивать особо незачем.
Буду сравнивать локальные операции — status, revert, diff
Сетевые операции pull/push — update/commit
Вот чекаут ещё сравню — в гите он просто реактивный, судя по всему.
Скорость это не только коммиты пуши, но и например blame
