Увидел свет (https://lkml.org/lkml/2012/12/31/73) релиз распределенной системы управления исходными текстами Git 1.8.1 (http://git-scm.com/). Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям задним числом используются криптографические методы, также возможна привязка цифровых подписей разработчиков к тегам и коммитам. Из проектов, разрабатываемых с использованием Git, можно отметить ядро Linux (http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6...), Android (https://android.googlesource.com/), Libreoffice (http://cgit.freedesktop.org/libreoffice), Systemd (http://cgit.freedesktop.org/systemd), X.Org (http://cgit.freedesktop.org/xorg), Wayland (http://cgit.freedesktop.org/wayland), Mesa (http://cgit.freedesktop.org/mesa/), Gstreamer (http://cgit.freedesktop.org/gstreamer), Wine (http://source.winehq.org/git/wine.git), Debian (http://anonscm.debian.org/gitweb) DragonFly BSD (http://gitweb.dragonflybsd.org/?p=dragonfly.git;a=summary), Perl (http://perl5.git.perl.org/perl.git), Eclipse (http://git.eclipse.org), GNOME (http://git.gnome.org/browse/), KDE (https://projects.kde.org/projects), Qt (http://qt.gitorious.org/), Ruby on Rails (https://github.com/rails/rails), PostgreSQL (http://git.postgresql.org/gitweb/), VideoLAN (http://git.videolan.org), PHP (http://git.php.net/).В анонсе новой версии отмечается, что в одном из будущих значительных выпусков Git будет изменено поведение команды "git push" по умолчанию. В ситуации когда при выполнении "git push" явно не указано что именно помещать в репозиторий ранее использовалась семантика "matching", при которой для обновления выбирались все внешние ветки и теги с именами, совпадающими с локальными. В будущем поведение будет изменено и по умолчанию будет применяться семантика "simple", при которой изменения отправляются только из текущей ветки в ветку с тем же именем, в случае если локальная ветка назначена для интеграции с удалённой веткой. Переопределить новое поведение можно через конфигурационную переменную "pus.default".
Кроме того, в одном из будущих выпуском может быть прекращена поддержка команды "git branch --set-upstream", которая объявлена устаревшей из-за того, что не редки случаи указания по ошибке "git branch --set-upstream origin/master", что приводило к созданию локальной ветки "origin/master" для интеграции с текущей загруженной веткой, что явно отличается от того, что ожидал получить пользователь. В качестве замены следует использовать команду "git branch [-u|--set-upstream-to]". Окончание "-to" поможет исключить ошибочную трактовку назначения опции;
Из изменений в Git 1.8.1 можно отметить:- Для tcsh и zsh добавлены скрипты для автодополнения опций командной строки git;
- В директорию contrib/completion добавлен скрипт "git-prompt" для раскраски подсказок в приглашении ввода;
- Убрано обходное решение для проблемы в утилите less, приводящей к молчаливому завершению работы при изменении размера терминала. Проблема устранена в релизе less 406, выпущенном ещё в 2007 году;
- При выполнении команды "git checkout" теперь выводится информация о том, насколько значительны расхождения с внешней веткой и приводятся советы как осуществить синхронизацию веток через операции push или poll;- При выполнении "git config --get" в случае наличия дублирующихся опций в файле конфигурации, вместо вывода ошибки теперь применяется последнее заданное значение;
- Добавлена конфигурационная директива "diff.context" для задания числа строк по умолчанию, выводимых в качестве контекста до или после изменённой строки (по умолчанию 3);
- В команду "git format-patch" добавлена опция "--notes=ref" для указания примечания к коммиту, после вывода строки "---";
- Команда "git log -p -Sстрока" отныне осуществляет поиск строки после использования фильтра textconv (ранее поиск выполнялся без преобразования блобов);
- В "git log --grep=pcre" теперь учитываются особенности регулярных выражений Perl, если в конфигурации задана директива "grep.patterntype = perl";
- В команде "git replace -d объект" объект теперь может интерпретироваться не только по полному имени, но и в форме хэша SHA-1;
- Команда "git rm $submodule" может быть использована для удаления рабочего дерева субмодуля без потери встроенных в него репозиториев;
- В команде "git send-email" теперь запрещено указание после "Cc:" лишних строк после email, например, строка "Cc: Stable Kernel stable@k.org # for v3.2 and up" будет обрезана до "Cc: Stable Kernel stable@k.org";- Добавлена команда "git submodule add" для добавления нового субмодуля в текущем файловом пути;
- В команду "git submodule sync" добавлена опция "--recursive";
- Добавлена переменная конфигурации "diff.submodule" для задания используемой по умолчанию опций для команды "git diff --submodule";
- В команду "git symbolic-ref" добавлена опция "-d $symref" для удаления именованных символических ссылок;
- В "git cvsimport" добавлена поддержка указания часового пояса для каждого автора;
- В состав включён вспомогательный внешний интерфейс (remote-helper) для взаимодействия с репозиториями Subversion;
- Добавлен новый remote-helper для Mercurial;
- Добавлена поддержка сборки в окружении Cygwin с новым набором заголовочных файлов;
- Обновлён код поддержки сборки с использованием инструментария MinGW;
- Произведена оптимизация логики генерации начального списка доступных ссылок из "upload-pack", выполняемая на другой стороне соединения при запуске "git fetch";
- Проведена оптимизация логики поиска набора атрибутов, соответствующих указанному пути;
- Для ускорения команд "git diff-index" и "git update-index" задействован предварительно загружаемый индекс, что позволило повысить скорость работы на системах с медленным вызовом функции stat (в том числе в Linux).
URL: https://lkml.org/lkml/2012/12/31/73
Новость: http://www.opennet.me/opennews/art.shtml?num=35739
Докачку уже запилили? Если нет, то не нужно.
А чем оно лучше svn?
а что такое svn?
> а что такое svn?Древняя система контроля версий, централизованной эпохи еще.
> А чем оно лучше svn?Практически всем. Наиболее - тем что оно распределенное и потому может хранить всю историю изменений локально. Так что не надо дрюкать какой-то там ремотный сервер чтобы посмотреть что было пять ревизий назад и откатить вон тот патч, вызвавший проблемы. По поводу чего можно покодить хоть там где интернетом и не пахло, чувствуя себя белым человеком при этом. Да и зависимость от центрального сервака - зло.
Зависимость от центрального сервака во многих случаях - добро. Особенно когда это корпоративное использование персонал не особо квалифицирован в управлении версиями. Гит в таких ситуациях нужно обкладывать горой костылей, чтобы юзверь не начудил.Но это, пожалуй, единственный вариант, когда SVN предпочтительнее.
> Но это, пожалуй, единственный вариант, когда SVN предпочтительнее.ошибаетесь, поработайте с репозитарием 100Gb+ и тогда мы с вами поговорим, что удобнее, а что нет ;)
Да, с такими работать как-то не приходилось. А в чём там SVN выигрыш даёт? Только в том,что локально меньше держать?
причём тут выигрыш? SVN даёт только проигрыш
Вы можете толком ответить, что там на таких размерах репа происходит? Ну и заодно - что лежит в версионнике - большие или малые файлы. Что в основном бинари на таких обьъемах - понятно.
> Вы можете толком ответить, что там на таких размерах репа происходит? Ну
> и заодно - что лежит в версионнике - большие или малые
> файлы. Что в основном бинари на таких обьъемах - понятно.Там происходит полная ж. См. репозиторий boost'а, например. Там ограничения VCS привели к тому, что вменяемая история оказывается практически полностью утрачена.
не обязатаельно так хардкорно. Достаточно на сотни мегов, но вне офиса, а где-нибдуь из дома или во время командировки
> ошибаетесь, поработайте с репозитарием 100Gb+А зачем версионировать прон? Не понимаю.
В рекламном агентстве, допустим - вполне реальный размер. Кладётся всё в исходниках, с кучей слоёв, в максимальном разрешении, весит соответственно. ОДин PSD на 100 метров - вполне нормально. Другое дело, что в один репозиторий всё это можно и не пихать, а назначить по репе дизайнеру или заказчику или кампании. Но это уже вопрос местной специфики.
и вообще можно в реп не пихать, а настроить посуточное архивирование всего контента некоторых директорий с рабочих машин. Там же на самом деле не нужен версионник, в 9 из 10 паттернов работы с данными в вашем случае обычная бэкапилка делает всё на порядки проще, удобнее и быстрее (BackupPC, например).остаётся 1 случай из 10, где бэкап раз в сутки не подходит и конечный сотрудник знает, понимает и умеет делать контрольные точки в своей работе внутри дня.
если админ для первого случая ставит SVN, или любую другую VCS, то он конченный идиот.
Ну да, я где-то в обсуждении такой пример приводил. Просто бэкап на FTP. Правда там всё же далеко не раз в сутки надо, и по папкамм как-то отдельно раскладвать, и тому подобное. В общем скриптик был... интересный.Но SVN в первом случае даёт две вещи:
1) откат. svn revert который. Больше одной версии в прямой доступности - это спосб запутать сотрудника,лучше пусть эникея зовёт. А вот одна - в самый раз, и количество вызовов снижается и диск не захламляется дурными копиями "на всякий случай".
2) окошечко, в котором всё же пишется,что именно было сделано. И этот текст гарантированно прибит к тем файлам, к которым относится. Еслои вы не в курсе, дизайнеров/художников научить работать с тикет-системами удаётся далеко не всегда, а вот аннотацию ввести - это понятно, здесь проблем нет.И третье, отдельно - SVN банально проще настроить, чем инкрементальный бэкап с быстрым восстановлением.
1
> Зависимость от центрального сервака во многих случаях - добро.Особенно когда:
1) Упала сеть.
2) Упал сервак и нет бэкапа.
3) Упал интернет у ремотного разработчика.
4) Разработчик хочет покодить на природе.> Особенно когда это корпоративное использование персонал не особо квалифицирован
> в управлении версиями.А зачем обезьянам гранаты? Из этой игры кто-то надеется извлечь хороший результат?
> Гит в таких ситуациях нужно обкладывать горой костылей, чтобы юзверь не начудил.
Потому что не надо путать систему контроля версий (заточенную на индивидов с мозгами, пользующихся по назначению) и обезьян с гранатой. Никто не ориентирует гранаты на использование их обезьянами.
> Но это, пожалуй, единственный вариант, когда SVN предпочтительнее.
Это в целом дефективный сценарий, пардон. И что, утверждается что эти полудурки еще и что-то конкурентоспособное из себя вымучают? oO
Так есть случаи, когда ремотных разработчиков просто нет. Что даёт много большую надёжность, кстати, в плане администрирования софта. Ну и в случае рекламной конторы - рабочая машина у дизайнера всяко лучше, чем дома.А у админа,у которого упал сервак и нет бэкапа - остальное и подавно десять раз поляжет, винда-то под шаловливыми ручками пользователей.
Эти "полудурки" рисуют так, как я мечтать не смею. Или с заказчиками умудряются договариться там, где я убил бы давно с особой жестокостью. И умудряются что-то понять из фраз вроде "ну вот это... оно как-то грустно, надо бы с хаханькой, чтоб пробирало". И приносят фирме деньги. Чать из которых и платят админу, чтобы он сделал этим людям удобно.
Но да, без SVN там можно неплохо обойтись, используя FTP. А можно и не обходиться, и даже научить щелкать на ярлычок, когда какой-то этап работы закончен, и писать в появившемя окошке, что именно сделано.
> а что такое svn?google вроде не забанили еще.
> Древняя система контроля версий, централизованной эпохи еще.
т.е. вы предлагаете каждому человеку, скачивать 1 Тб репозитарий, чтобы удобно поработать дома? А чо, закинул на флеху и пошел работать домой, удобно ж :D
> Гит в таких ситуациях нужно обкладывать горой костылей, чтобы юзверь не начудил.
собственно на это и намекал, что для каждой задачи свои методы. А то пихают git во все щели и с пеной у рта кричат, он лучше всех!
> Да и зависимость от центрального сервака - зло.
да как сказать, только не надо говорить, что сервер может поломаться, а интернет перестать работать :D
> т.е. вы предлагаете каждому человеку, скачивать 1 Тб репозитарий, чтобы удобно поработать дома? А чо, закинул на флеху и пошел работать домой, удобно ж :DПредлагаю заюзать sshfs
> т.е. вы предлагаете каждому человеку, скачивать 1 Тб репозитарий, чтобы удобно поработать дома? А чо, закинул на флеху и пошел работать домой, удобно ж :Dдля особо одаренных git clone --depth 1
Если использовать --depth то репозиторий становится инвалидом, там даже git push не сделаешь.
> да как сказать, только не надо говорить, что сервер может поломаться,
> а интернет перестать работать :DМожет и поломаться, и упасть вместе с бэкапами (некоторые держат их там же), и ещё много чего. Также смею доложить, что некоторым работать в офлайне получается куда продуктивнее по причине отсутствия лишних прерываний.
Можно ещё много чего прибавить (в т.ч. и про shallow clones), но что-то сомнения берут, что Вы вообще на охоту сюда пришли. Тем более за терабайтными репо с чем-то полезным.
Вот как раз по удобству администрирования SVN именно в сили централизованности много лучше. Тот же бекап централизованный и не завяисящий от состояния рабочей станции.
> Тот же бекап централизованный и не завяисящий от состояния рабочей станции.А в git по дефолту каждая копия - полноценный бэкап.
Это не бэкап, а пародия- кто, когда и как его покалечит - неизвестно. Централизованный нормально администрируемый бэкап всяко надёжнее.
> Это не бэкап, а пародияЭто бэкап.
> - кто, когда и как его покалечит - неизвестно.
И обычно неважно, поскольку их таких много (как и положено бэкапам).
> Централизованный нормально администрируемый бэкап всяко надёжнее.
Нет, конечно (даже у меня конторские погремушки bacula растаскивает в несколько мест, а самое интересное бэкапится и другими методами). Просто и он не отменяется. :)
Тут несколько моментов:1) бэкапить придётся каким-то образом локальные репозитории (в них всякие приватные ветки могут активно расти). Учитывая, что пользователь этих репозиториев может наклепать вагон и в непредсказуемых местах диска - решать получится разве что административно.
2) неквалифицированный пользователь влёгкую убивает локальный репозиторий до полуживого состояния (место почистит, или ещё какую глупость сделает), после чего начинаются чудеса - тут файл есть, тут ругнулось, там push не проходит с загадочной ошибкой... При этом юзера пугаются и начинают вовсе ерунду творить, а починить, не прибив пользовательские локальные ветки - дело нетривиальное. Раз попробовал - больше не хочу. А с бэкапом локала - см. пункт 1.
3) не то чтоб я был крутым гит-спецом, но некоторый опыт есть. Но вот я не знаю способов дать возможность push и при этом не дать угробить репозиторий, в который этот push делается. Наверное где-то есть оно, но мне не попадалось. Так что шансов найти проблемы больше даже на сервере. А вот с SVN, который так просто на затрёшь, или с FTP, который вообще позволяет только заливать и после этого ставит всё в ридонли - оно попроще.
Да, всё это, конечно, подразумевает работу в офисе, наличие вменяемого централизованного администрирования и неквалифицированных (в работе с версионниками) пользователей. Но я, собственно, и утверждаю, что в таком сценарии SVN предпочтительнее чем Git.
> Но вот я не знаю способов дать возможность push и при этом не дать угробить репозиторий, в который этот push делается. Наверное где-то есть оно, но мне не попадалось.Уже не первый раз за последние дни встречаю подобный вопрос, и всегда он остается без нормального ответа. Делается это очень просто с помощью опций receive.denyNonFastForwards и receive.denyDeletes на центральном сервере. Если же нужно что-то более продвинутое в плане контроля за действиями пользователей - тогда либо через самописные хуки, либо установку gitorious и др.
а push/rebase/push оно прикроет?
акститесь svn only
> а push/rebase/push оно прикроет?Да, это и есть основное предназначение параметра receive.denyNonFastForwards (он запретит любые не FF мержи, а rebase куска истории, уже опубликованной в центральной репе, никак не может привести к FF мержу).
git дерьмецо
svn можно запускать без апатча и sshservice svnserve start и все!!!
Простота, Элегантность и нету быдлонабора git add / git commit / git push
> git дерьмецо
> svn можно запускать без апатча и sshАля-улю, дядя. git можно запускать без апача и ssh. Неожиданно, правда?
Авторизация, шифрование трафика ?
> Авторизация, шифрование трафика ?И давно svn:// научился шифровать трафик? (svn+ssh:// исключаем по условию задачи)
И, кстати, для доступа к git репозитарию через http(s), в отличие от svn, не обязательно требуется поддержка WebDAV со стороны веб сервера.
[sasl]
use-sasl = true
min-encryption = 128
max-encryption = 256
>> Авторизация, шифрование трафика ?
> И давно svn:// научился шифровать трафик? (svn+ssh:// исключаем по условию задачи)
> И, кстати, для доступа к git репозитарию через http(s), в отличие от
> svn, не обязательно требуется поддержка WebDAV со стороны веб сервера.http(s) с коробки не умеет, Апатч не используем по религиозным соображениям.
Набор-то как раз хороший, особенно если помнить о git add -i (а когда не надо - есть git commit -a).
> т.е. вы предлагаете каждому человеку, скачивать 1 Тб репозитарий, чтобы удобно поработать дома? А чо, закинул на флеху и пошел работать домой, удобно ж :DТак, для примера - ВСЯ история FreeBSD со всеми ветками в git весит меньше, чем SVN чекаут.
> Git является одной из самых эффективных, надёжных и высокопроизводительных систем управления версиями
> одной из самыхНе самой? Да. Не. Может. Быть.
> Да. Не. Может. Быть.[Yes] [No] [Ok] [Cancel] [Abort] [Retry] [Ignore] [Quit]
> может быть прекращена поддержка команды "git branch --set-upstream", которая объявлена устаревшей из-за того, что не редки случаи указания по ошибке "git branch --set-upstream origin/master", что приводило к созданию локальной ветки "origin/master" для интеграции с текущей загруженной веткой, что явно отличается от того, что ожидал получить пользовательПоследние дни настали. Разработчики git принимают во внимание _ожидания_ пользователя.
> Последние дни настали. Разработчики git принимают во внимание _ожидания_ пользователя.Внезапно, когда некто делает нечто - он ожидает некий результат. А вот если вы, пристроив зад на толчок вдруг ВНЕЗАПНО отправляетесь на орбиту - это довольно неожиданный результат.
> для особо одаренных git clone --depth 1Костыль на костыле. Нет уж, спасибо :D
> Предлагаю заюзать sshfs
ага, и юзать платные клиенты под винду.
> Костыль на костыле. Нет уж, спасибо :DЭто батенька не костыл, это национальная возможность не лить всю историю.
> ага, и юзать платные клиенты под винду.Ну не хочешь sshfs, webdav или smb устроит? бесплатно.
Поделитесь сколько человеко часов потратили на > 100GB кода.
Оно правда костыльно - при таких объемах (там и одна ревизия соответствующих размеров обычно) локально держать версии очень накладно. Особенно учитывая, что это бинари и, соотвественно, с дельтами там всё плохо. А нужны старые версии довольно редко. Получается, что нужно чутьли не после каждого push прибивать локальные старые версии, что именно костылём и выглядит. А без центрального сервера ни при какой серьезнойразработке обычно не обходится, тем более когда ресь идет о репе с бинарями, которые создают всяко не программисты и доверять им в плане сохранности репозитория нельзя.Собственно, для больших бинарей версионник с вероятностью вообще на фиг не нужен - а нужен FTP плюс политика "новую версию кладём в новую папку", заэнфорсенная правилами самого FTP-сервера.
> - а нужен FTP плюс политика "новую версию кладём в новую
> папку", заэнфорсенная правилами самого FTP-сервера.Да, внезапно, VCS это не FTP...
Внезапно главное - какую цель хотим достичь. А потом уже выбираем средства. Если у нас сидит (как я когда-то видел) девочка-художник, которую кое-как научили отличать файлы от каталогов и не класть всё на рабочий стол - какая там VCS. Зато рисует эта девочка великолепно, фантазия отличная и очень быстро въезжает в то, что надо заказчику. Вот это - реальный случай, где FTP + задачка в nnCron отлично подошли. Правда, открывал папку с копиями помогал выбрать нужную эникейщик, но раз в неделю - не сложно.
> Поделитесь сколько человеко часов потратили на > 100GB кода.без понятия, я их не считаю :)
Как то так получается
# cd ~
# svn co file:/// .... 2012/03/ ./03/
# du -h ./03/
222G 03/# find . -type f -name '*.psd' -exec ls -l {} \; | awk '{ print $5}' | awk '{s+=$0} END {print s/1073741824" Gb"}'
95,2019 Gb
> # find . -type f -name '*.psd'Думаю, за Ваши массивы текстовых файлов *.psd здесь рад не только я, но хотя бы тему своих ответов поправили...
>> # find . -type f -name '*.psd'
> Думаю, за Ваши массивы текстовых файлов *.psd здесь рад не только я,
> но хотя бы тему своих ответов поправили...А вы думали 1 Тб кодинга? :D Я не в M$/google работаю ;) И то сомневаюсь, что даже все исходники всех форточек и всяких эксченджей потянут на такой объем
сарказм
> Это батенька не костыл, это национальная возможность не лить всю историю.мне вот нужно сделать checkout одной папки(файла) из репозитария в 250 Gb, git позволит такое сделать?
> Ну не хочешь sshfs, webdav или smb устроит? бесплатно.
а что, smb уже научилось over internet работать? Или вы мне сейчас начнете предлагать vpn и т.п. вещи? А вы пробовали балансировать sshfs/webdav/smb? В отличие от http занятие не из приятных ;)
> мне вот нужно сделать checkout одной папки(файла) из репозитария в 250 Gb,не нужно вам этого делать, у вас же нет репозитария. Что у вас есть называется файлопомойкой.
>> мне вот нужно сделать checkout одной папки(файла) из репозитария в 250 Gb,
> не нужно вам этого делать, у вас же нет репозитария. Что у
> вас есть называется файлопомойкой.о великий и могучий гуру, а мужики то и не знали :D
> А вы пробовали балансировать sshfs/webdav/smb? В отличие от http занятие не из приятных ;)внезапно, webdav и есть http. И ваш SVN вероятно именно через него работает. Подключать удалённый диск в любом случае не айс, для удалённой работы допустимы тольок синки туда-сюда. SVN в основном только это и умеет нормально делать.
>> А вы пробовали балансировать sshfs/webdav/smb? В отличие от http занятие не из приятных ;)
> внезапно, webdav и есть http. И ваш SVN вероятно именно через него работает.скажем так, svn это расширенный webdav
> Подключать удалённый диск в любом случае не айс, для удалённой
> работы допустимы тольок синки туда-сюда. SVN в основном только это и
> умеет нормально делать.ага, а как потом программисту смотреть отличия в коде? :) Сейчас человек может посмотреть историю ревизий и сравнить файл в двух ревизиях, с наглядным отображением изменений. В вашем случае, хз чо он там будет делать
> ага, а как потом программисту смотреть отличия в коде? :) Сейчас человек
> может посмотреть историю ревизий и сравнить файл в двух ревизиях, с
> наглядным отображением изменений. В вашем случае, хз чо он там будет
> делатьКакие отличия в коде, у него psd файлы, у вас psddiff есть?
>> ага, а как потом программисту смотреть отличия в коде? :) Сейчас человек
>> может посмотреть историю ревизий и сравнить файл в двух ревизиях, с
>> наглядным отображением изменений. В вашем случае, хз чо он там будет
>> делать
> Какие отличия в коде, у него psd файлы, у вас psddiff
> есть?раскройте свой кругозор и тогда вы узнаете, что в природе существуют не только psd файлы :D
>> ага, а как потом программисту смотреть отличия в коде? :) Сейчас человек
>> может посмотреть историю ревизий и сравнить файл в двух ревизиях, с
>> наглядным отображением изменений. В вашем случае, хз чо он там будет
>> делать
> Какие отличия в коде, у него psd файлы, у вас psddiff
> есть?есть bsdiff = http://www.daemonology.net/bsdiff/
Это другая история
> скажем так, svn это расширенный webdavтоже неправильно. SVN это "суженный" webdav, т.е. его кастомизированное подмножество.
> ага, а как потом программисту смотреть отличия в коде? :)
какому программисту, вы очём вообще? У вас же вроде как толпа дизайнеров и прочих нетехнарей, не?
> Сейчас человек может посмотреть историю ревизий и сравнить файл в двух ревизиях, с наглядным отображением изменений. В вашем случае, хз чо он там будет делать
мой случай был для простого хранения бинарных данных, это единственная ниша, где SVN может составить конкуренцию остальным инструментам
Для работы с текстовыми сорцами SVN вообще непригоден, особенно если нужно работать с большим репозитарием или просто удалённо. Ибо
1. каждая ветка SVN это отдельная копия всего контента (для SVN удвоенное место всего контента). Да, можно извращаться чекаутами только части репы, но для разработки это нетипичный паттерн.
2. каждый чих это несколько запросов на сервер. Нельзя даже хистори посмотреть без нескольких http/webdav'ных запросов.
3. естественно, работа остальными ревизиями тоже дёрганье сервера.
как следствие, SVN ужасно тормозной для обычной разработки.
>> скажем так, svn это расширенный webdav
> тоже неправильно. SVN это "суженный" webdav, т.е. его кастомизированное подмножество.началась тавтология :)
> какому программисту, вы очём вообще? У вас же вроде как толпа дизайнеров
> и прочих нетехнарей, не?нет, это лишь ваши домыслы ;)
> 1. каждая ветка SVN это отдельная копия всего контента (для SVN удвоенное
> место всего контента). Да, можно извращаться чекаутами только части репы, но
> для разработки это нетипичный паттерн.как раз в моем случае это идеальный вариант, ибо в день по 100-150 проектов и для каждого создавать отдельный репозитарий просто не удобно.
> 2. каждый чих это несколько запросов на сервер. Нельзя даже хистори посмотреть
> без нескольких http/webdav'ных запросов.а вы каждую секунду смотрите хистори? или вы сидите на gprs
> 3. естественно, работа остальными ревизиями тоже дёрганье сервера.
и что. Ну разве что у вас vps за 5$ в месяц
> как следствие, SVN ужасно тормозной для обычной разработки.
специфику чистых программистов (с/с++/java, etc) не знаю. Возможно там действительно git намного удобнее.
Я лишь хотел сказать, что у svn есть своя ниша задач, где он будет удобнее git/mercurial/bazar/etc ... . А где то git будет удобнее.
> Костыль на костыле.Возможность настройки теперь называется костылем? Ох, а у вашего монитора яркость не настраивается? А то нафиг вам эти костыли?
>> Костыль на костыле.
> Возможность настройки теперь называется костылем? Ох, а у вашего монитора яркость не
> настраивается? А то нафиг вам эти костыли?слышал звон, да не знаю где он :D
Рады за вас, меньше знаешь крепче спишь.
Нет, ну серьёзно. Сегодня они правят UI в угоду «ожиданиям», с позволения сказать, пользователя, а что будет завтра? Маны на человеческом языке вместо птичьего? Последовательный и предсказуемый UI? Нормальная архитектура в виде libgit(2) + frontendы? Полноценный интерфейс для встраиваемых плагинов? Сообщения об ошибках, ориентированные на, опять простите, конечного пользователя, а не на разработчика git?
Думаю, это заговор, имеющий целью сделать Элитный Инструмент Хакеров Ядра очередной унылой просто-DVCS, которая тихо и незаметно работает.
Очень элитарный интструмент, угу - по распространенности примерно как все остальные VCS вместе взятые. Може это вы чего-то не понимаете? Программистам, в общем-то, всунуть неудубную им тулзу довольно сложно.
> по распространенности примерно как все остальные VCS вместе взятыеразве что DVCS
> Може это вы чего-то не понимаете?
Ага, скоро как 5 лет разными DVCS активно пользуюсь и до сих пор не понимаю.
внезапно, обычные люди чистым гитом и не пользуются, а юзают надстройки
> внезапно, обычные люди чистым гитом и не пользуются, а юзают надстройки
> % find /usr/lib/git-core/ -lname git | wc -l
> 107пользуются-пользуются. потому что git уже пару лет как сам себе «надстройка».
Ребят, ну чо вы спорите.git хуже svn одним -- он тормознее. Но он и должен быть тормознее. Вы ж поймите, ваш локальный винчестер не дотягивает даже до Fast Ethernet, про GigE я уж молчу. А дисковая полка на сервере переплюнет и GigE.
Соответственно, когда вы работаете с большими репозитариями -- на git'е вы повеситесь на витой паре.
Во всех остальных возможностях git и svn совпадают.
> Ребят, ну чо вы спорите.
> git хуже svn одним -- он тормознее. Но он и должен быть
> тормознее. Вы ж поймите, ваш локальный винчестер не дотягивает даже до
> Fast Ethernet, про GigE я уж молчу. А дисковая полка на
> сервере переплюнет и GigE.
> Соответственно, когда вы работаете с большими репозитариями -- на git'е вы повеситесь
> на витой паре.
> Во всех остальных возможностях git и svn совпадают.фрактальные алгоритмы, дедупликация, векторное чтение из потока
> Ребят, ну чо вы спорите.
> git хуже svn одним -- он тормознее. Но он и должен быть
> тормознее. Вы ж поймите, ваш локальный винчестер не дотягивает даже до
> Fast Ethernet, про GigE я уж молчу. А дисковая полка на
> сервере переплюнет и GigE.
> Соответственно, когда вы работаете с большими репозитариями -- на git'е вы повеситесь
> на витой паре.Мы с boost'ом работали?
> Во всех остальных возможностях git и svn совпадают.
> Вы ж поймите, ваш локальный винчестер не дотягивает даже до
> Fast Ethernet, про GigE я уж молчу. А дисковая полка на
> сервере переплюнет и GigE.Андрей, вообще-то средний локальный винчестер переплёвывал FE (~11Mb/s) ещё в прошлом веке, где-то в районе десяти гигабайт ёмкости. Конкретно DTLA 15Gb/7200RPM у меня на VIA686 отдавал порядка 27 Mb/s в начале диска.
Даже если бы GE был в десять раз быстрее, то это максимум нынешние бюджетные двухблинные терабайтники (Hitachi HDS721010CLA332: ~130 Mb/s на старте).
Дисковые полки (и даже просто стопку локальных SAS в RAID5/6/10) нынче из эзернетов лучше высовывать десяткой.
А ещё есть такая штука как SSD, рекомендую пощупать. В новом ноуте отдаёт несколько более 440Mb/s sustained.
> Соответственно, когда вы работаете с большими репозитариями --
> на git'е вы повеситесь на витой паре.Позвольте усомниться ввиду вышесказанного (особенно при активном пересечении по местам, над которыми работают).
> Во всех остальных возможностях git и svn совпадают.
Наверное, смешнее всех было бы разработчикам SVK...
>git хуже svn одним -- он тормознее.расскажите что там еще интересного в вашей альтернативной реальности?)))))))
Вот, характерный пример. Я сейчас случайно изменил файл в git-репозитории, который мне нужен только на чтение. Что в svn, что в hg, я уже заранее знаю, как его вернуть назад, это логично и очевидно, и идёт на третьей странице руководства.В git же, если не знаешь, если не знаешь всех нюансов, то его использование - это постоянное натыкание вот на такие неочевидности, и пока не разберёшься со всеми, пользоваться git практически невозможно. git - это показатель крутости, а не показатель эффективности :) он позволяет смотреть на других свысока. но большинству людей неинтересны технические тонкости, им нужно простое средство решать простые задачи, и чтобы оно было логично и понятно. Я прочитал штук 20 учебников по git, несколько лет пытался им пользоваться хотя бы по мелочам, но у меня не техническое мышление и я вообще не понимаю логики его работы, у меня нет никакой основы, на которую можно опереться. При этом с hg у меня никаких проблем не возникает, я его освоил сразу и многие вещи там делаются легко и просто.
>[оверквотинг удален]
> пока не разберёшься со всеми, пользоваться git практически невозможно. git -
> это показатель крутости, а не показатель эффективности :) он позволяет смотреть
> на других свысока. но большинству людей неинтересны технические тонкости, им нужно
> простое средство решать простые задачи, и чтобы оно было логично и
> понятно. Я прочитал штук 20 учебников по git, несколько лет пытался
> им пользоваться хотя бы по мелочам, но у меня не техническое
> мышление и я вообще не понимаю логики его работы, у меня
> нет никакой основы, на которую можно опереться. При этом с hg
> у меня никаких проблем не возникает, я его освоил сразу и
> многие вещи там делаются легко и просто.git похож на большую неуправляемую фуру
>[оверквотинг удален]
>> это показатель крутости, а не показатель эффективности :) он позволяет смотреть
>> на других свысока. но большинству людей неинтересны технические тонкости, им нужно
>> простое средство решать простые задачи, и чтобы оно было логично и
>> понятно. Я прочитал штук 20 учебников по git, несколько лет пытался
>> им пользоваться хотя бы по мелочам, но у меня не техническое
>> мышление и я вообще не понимаю логики его работы, у меня
>> нет никакой основы, на которую можно опереться. При этом с hg
>> у меня никаких проблем не возникает, я его освоил сразу и
>> многие вещи там делаются легко и просто.
> git похож на большую неуправляемую фуругыг, сказали люди про framework, во внутренности загляните
>[оверквотинг удален]
> пока не разберёшься со всеми, пользоваться git практически невозможно. git -
> это показатель крутости, а не показатель эффективности :) он позволяет смотреть
> на других свысока. но большинству людей неинтересны технические тонкости, им нужно
> простое средство решать простые задачи, и чтобы оно было логично и
> понятно. Я прочитал штук 20 учебников по git, несколько лет пытался
> им пользоваться хотя бы по мелочам, но у меня не техническое
> мышление и я вообще не понимаю логики его работы, у меня
> нет никакой основы, на которую можно опереться. При этом с hg
> у меня никаких проблем не возникает, я его освоил сразу и
> многие вещи там делаются легко и просто.
> Я прочитал штук 20 учебников по git, несколько лет пытался
> им пользоваться хотя бы по мелочам, но у меня не техническое
> мышление и я вообще не понимаю логики его работы, у меня
> нет никакой основы, на которую можно опереться.Бедный буратино.
> Вот, характерный пример. Я сейчас случайно изменил файл в git-репозитории, который мне нужен только на чтение. Что в svn, что в hg, я уже заранее знаю, как его вернуть назад, это логично и очевидно, и идёт на третьей странице руководства.Зачем руководство? «вернуть» == «revert» => hg/svn/darcs/mtn/bzr/fossil revert. problem solved.
> но большинству людей неинтересны технические тонкости, им нужно простое средство решать простые задачи, и чтобы оно было логично и понятно.
Скорее средство, которое не мешает решать свои задачи.
> у меня не техническое мышление и я вообще не понимаю логики его работы
Думаю, это не имеет значения. У меня техническое мышление и я понимаю логику работы git — и всё равно он вызывает в лучшем случае недоумение, иногда раздражение.
> нет никакой основы, на которую можно опереться
низкоуровневое поделие (до сих пор) потому что. Выход один — заучивать man gitglossary чтобы хотя бы читать man git-* без подглядывания в первый.
Откатить измененный файл до зафиксированной версии:
git checkout path/to/file/name
а ещё откатить рабочую копию до нужного состояния — тоже git checkout. И даже переключиться в ветку, предварительно создав её — тоже git checkout.http://stevelosh.com/media/images/blog/2010/01/mercurial-vs-...
ветку вы можете откатывать не только так, что плохого в ключике -b, очень удобно.
Если вы постоянно стреляете себе в ногу, это не значит что ружье плохое, просто на предохранитель нужно ставить.
> ветку вы можете откатывать не только такЧто как бы намекает, что дизайн git CLI продумывался не менее 15 минут. А то и целых 20.
> вы постоянно стреляете себе в ногу
Как будто бы работа программиста недостаточно сложна и без закидонов git.
Уже пол года как я использую git по работе, но ощущение как от работы с бензопилой. Нужен постоянный контроль своих действий + мета-версионный инстумент tar :)
> Уже пол года как я использую git по работе, но ощущение как
> от работы с бензопилой. Нужен постоянный контроль своих действий + мета-версионный
> инстумент tar :)Именно про это я и хочу сказать, все есть
Но для работы с git нужны склилы и прокачка магии
контроль своих действий нужен даже во сне чтобы постель не замочить
