Организация Apache Software Foundation представила (https://blogs.apache.org/foundation/entry/hats_off_to_the_ap...) релиз системы управления версиями Subversion 1.7.0 (http://subversion.apache.org), первого значительного выпуска с момента принятия в апреле 2010 года Subversion в число первичных проектов Apache. Несмотря на развитие децентрализованных систем, Subversion пользуется большой популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем.
Из использующих Subversion открытых проектов можно отметить: Django, FreeBSD, Free Pascal, GCC, MediaWiki, Mono, PHP, Ruby. Поддержка Subversion реализована в таких хостингах открытых проектов, как Google Code, CodePlex и SourceForge. Результаты исследования, проведенного компанией Forrester Research, показали, что Apache Subversion лидирует в категории продуктов автономной конфигурации программного обеспечения и управления изменениями.
Среди кл...URL: http://svn.haxx.se/dev/archive-2011-10/0152.shtml
Новость: http://www.opennet.ru/opennews/art.shtml?num=32019
Супер! Есть интересные изменения
>Рабочие копии мета-данных, ранее разбросанные по всем директориям (каталоги .svn), теперь сохраняются в одном месте - в корне рабочей копии проекта создаётся одна директория ".svn", мета-данные в которой сохраняются с использованием SQLite.Это теперь выборочно не обновить? Печально.
Меня это тоже расстроило(
Не вижу связи. Просто перенесли на верхний уровень все данные svn - к возможности выборочного обновления напрямую это отношения не имеет.
> Не вижу связи.Ну так и не смотри.
Идиот на проводе? Кто мешает полезть вверх по дереву и найти .svn в корне локальной копии? Никак это не свзяано с возможностью работать с куском репозитория, разве что недописали что-то. Принципиальных проблем там близко нет.
Отправляйся в палату!
> Не вижу связи. Просто перенесли на верхний уровень все данные svn -
> к возможности выборочного обновления напрямую это отношения не имеет.Теперь нельзя просто скопировать под-директорию в другое место и продолжать работать с ней как с SVN-кой. Теперь на каждый чих нужно checkout, даже есть рядом лежит checkout директории более высокого уровня.
Печаль...
а чем svn up <dirname> в руте не катит?
>а чем svn up <dirname> в руте не катит?Необходимостью прыгать туда-сюда и вводить длинные команды вместо простого "svn up"
А что, так сложно решить задачу рекурсивого обхода родительских директорий в поисках подходящей .svn-директории?
Это плохо тем, например, тем, что раньше можно было в огромном дереве, которое конвертить в git целиком слишком накладно, отдельные ветки заменить на git, и из-за отсутствия .svn subversion их бы не трогал (хотя update при этом и валится), а теперь он полезет внутрь и неизвестно что там натворит. Кроме того, теперь отдельную ветку дерева не вынесешь за его пределы (например, поняв что остальное не нужно).В общем, единственное что оставалась ценного в svn - его непроходимая дубовость, а теперь он закосами под современные vcs ещё сильнее мешает своему использованию.
во-во svn живет за счет своей простоты и тут они начали "улучшать" ...
верните нелюди тупой .svn !
>во-во svn живет за счет своей простоты и тут они начали "улучшать" ...Я погорячился. Обновлять можно и отдельно. Но всё равно решение неудобное. По крайней мере, как сказано выше, скопировать часть проекта уже нереально. Ну и рекурсивный поиск "вверх" хоть и решает часть проблем, вызванных таким подходом, всё равно выглядит крайне убого в программном отношении.
Ещё как удобно. Даже отличное решение!!! Если вырезать папку из одного места репозитория и и вставить в другую папку ничего плохого не произойдет. А вы попробуйте секретарше, работавшей с документом объяснить, что так делать нельзя и почему.P.S. Отличный репозиторий для корпоративных хранилищ бинарных документов. Для программного кода есть более продвинутые решения типа git, bazar, mercurial.
>Если вырезать папку из одного места репозитория и и вставить в другую папку ничего плохого не произойдет.Но и ничего хорошего тоже.
>А вы попробуйте секретарше, работавшей с документом объяснить, что так делать нельзя и почему.А не надо ничего объяснять. Особенно секретарше.
>Но и ничего хорошего тоже.Ну это основная проблема у пользователей слабо знакомых с компьютером. Они перемещают папки с .svn, больше проблем у обычных пользователей не замечал. Как я понимаю, теперь это уже не будет приводить к проблемам, что есть очень хорошо.
>А не надо ничего объяснять. Особенно секретарше.
Мда. Видите ли какое у вас бы там ни было мнение о SVN, но статистика показывает, что его ниша уже не хранение кода, а именно юристы/экономисты держащие сотни документов в SVN. Subversion на это нишу и ориентируется. Программный код же будут хранить во всяких аля-git системах. И это хорошо, не зачем плодить велосипеды делающие то же самое, а так у Subversion есть будущие.
>Они перемещают папки с .svn, больше проблем у обычных пользователей не замечал.Так это не проблема, а удобство. Кто же виноват, что вы гранаты обезьянам раздаёте.
>Мда. Видите ли какое у вас бы там ни было мнение о SVN, но статистика показывает, что его ниша уже не хранение кода, а именно юристы/экономисты держащие сотни документов в SVN.Может ссылку на статистику в студию. А то смешно как-то всё это звучит. Особенно про юристов/экономистов.
В папках с исходным кодом конечно необходимость перемещения целой папки в другое место действительно выглядит маловероятной.>Так это не проблема, а удобство. Кто же виноват, что вы гранаты обезьянам раздаёте.
Проблема в том, что сис-админы да и IT-шники в целом часто забывают, что IT-процесс это только поддерживающий процесс (или сфера развлечений). То есть принципиально уборщица от сисадмина в этом смысле ничем не отличается, её задача сделать сделать так чтобы основные сотрудники непосредственно задействованные в непосредственно главном процессе предприятия чувствовали себя максимально комфортно. Но сис-админы почему-то решают, что они более важны для предприятия, называя основных сотрудников обезьянами, клавадавами и т.п. Subversion призван решать задачи централизованным хранением файлов. Из-за простоты, интеграции в Explorer с его помощью можно поднять эффективность работы не только IT-шников, но и других сотрудников, более близким к основной деятельности компании. Для работы с программным кодом есть более современные (по архитектуре) системы чем SVN.
Как система работы именно с исходным кодом она вытесняется другими системами. Просто можно следить сколько крупных проектов с открытым кодом покинуло SVN (OpenJDK, проекты того же apache и т.п.). Вероятна та же ситуация и в закрытых проектах. Сравните популярность того-же GitHub с аналогичными хостингами.
>Может ссылку на статистику в студию. А то смешно как-то всё это звучит. Особенно про юристов/экономистов.
Например тут можно посмотреть косвенную статистику использования SVN.
http://en.wikipedia.org/wiki/Comparison_of_open_source_softw...Я не имел ввиду, что владею статистикой использования SVN экономистами и юристами. Просто косвенно очевидно, что доля использования SVN для хранения исходников вытесняется более современными системами. А вот поддержка бинарных файлов в SVN и принципы его работы с версиями более удобны для не разработчиков софта (в том числе, например, для дизайнеров работающих в программах типа Photoshop). Последние изменения в функционале стали полезными как раз для этой ниши, не думаю что это совпадение.
>В папках с исходным кодом конечно необходимость перемещения целой папки в другое место действительно выглядит маловероятной.Почему маловероятной? Очень удобная и востребованная возможность. Но кто-то опять решил за всех.
>Проблема в том, что сис-админы да и IT-шники в целом часто забывают, что IT-процесс это только поддерживающий процесс (или сфера развлечений). То есть принципиально уборщица от сисадмина в этом смысле ничем не отличается, её задача сделать сделать так чтобы основные сотрудники непосредственно задействованные в непосредственно главном процессе предприятия чувствовали себя максимально комфортно.Ну вот опять всех под одну гребёнку. Так обычно рассуждают люди далёкие от IT. Но им простительно.
>Просто косвенно очевидно, что доля использования SVN для хранения исходников вытесняется более современными системами.Куда вытесняются? Я хочу полноценно разрабатывать сидя в лесу с ноутом. А куда там фанатики побегут в следующий раз, меня мало интересует. Как, впрочем, и cherry-pick не заменит докачку. Увы.
> В папках с исходным кодом конечно необходимость перемещения целой папки в другое
> место действительно выглядит маловероятной.Довольно удобное и частое применение. Особенно когда используется один репозиторий для кода, а не лапша из десятков маленьких git-иков.
> Для работы с программным кодом есть
> более современные (по архитектуре) системы чем SVN.По архитектуре - может быть. А по удобству распределенные системы сливают тому же SVN. SVN проще для понимания, позволяет работать с одним репо, а не плодить на каждый проект.
> Как система работы именно с исходным кодом она вытесняется другими системами. Просто
> можно следить сколько крупных проектов с открытым кодом покинуло SVN (OpenJDK,
> проекты того же apache и т.п.).Крупные проекты жуют кактус потому что слишком большие и без децентрализации возникают постоянные коллизии при записи в trunk, требуются отложенные коммиты, промежуточные репки и т.п.
Пока проект не достиг 100 разработчиков, то можно смело посылать DVCS в перед истории и пользоваться более удобными средствами для управления кодом.
Вы не поняли о чёт идет речь. Имелся ввиду рефакторинг кода. Перемещаются классы/модули, но врыт ли система настолько будет с самого начала спроектировать что целую папку с подпапками программного кода нужно будет перемещать без изменений. Имеется ввиду редко такое случается у более менее опытных программистов когда вместо
#include "foo/module1/*/*.h"
Тупо нужно сделать
#include "notfoo/module1/*/*.h"(* заменить на названия)
На практике часть файлов может перенестись в другие папки, часть переименоватся и т.п.. То есть имелась ввиду исключительно реструктуризация программного кода, а не реструктуризация репозитория.
Приходит секретарша, видит подпапку с документами для отправки лучше держать в другой парке. Она в Explorer по этой папке Ctrl+X (вырезала) и вставила в другое место. Потом на корневой папке репозитария тоже равой кнопкой и Commit. И тут начинаются проблемы, так как в SVN каждая папка фактически моет быть отдельным репозитарием. И так кстати действительно логично менять структуру.С перемещением папки .svn наверх таких проблем больше не будет.
И да не надо меня учить, что такой SVN, я с ним лет 7 работал. Когда достаточно большой не хватало ряда функций, которые как раз есть в git. Из того что сначала доставляло неудобство разве отсутствие линейной нумерации ревизий, но быстро переходишь на tag-и, что это более удобно нежели помнить число 11434.
>Довольно удобное и частое применение. Особенно когда используется один репозиторий для кода, а не лапша из десятков маленьких git-иков.
Не поверите, в git это тоже можно :)
> Вы не поняли о чёт идет речь. Имелся ввиду рефакторинг кода. Перемещаются
> классы/модули, но врыт ли система настолько будет с самого начала спроектировать
> что целую папку с подпапками программного кода нужно будет перемещать без
> изменений. Имеется ввиду редко такое случается у более менее опытных программистов
> когда вместо
> #include "foo/module1/*/*.h"
> Тупо нужно сделать
> #include "notfoo/module1/*/*.h"
> (* заменить на названия)Еще проще:
<dependency>
<groupId>myCode1</groupId>
<artefactId>myCode2</artefactId>
</dependency>и куда модуль не переноси - работать код будет без изменения программного кода.
>>Довольно удобное и частое применение. Особенно когда используется один репозиторий для кода, а не лапша из десятков маленьких git-иков.
> Не поверите, в git это тоже можно :)а как в git сделать checkout поддиректории?
Ух... Вы опять не поняли, я говорил, что для разработки программного кода, каталог .svn в каждом подкаталоге как раз не проблема. См. Выше. Для особо непонятливых: я хвалил (точнее говорил, что это как раз не минус) в этом контексте SVN и негде не писал, что чего там нельзя из того что Вы мне в ответе написали.Ещё раз тут напишу, я SVN работал более 7-ми лет, мне не надо рассказывать что там можно, а чего не можно. checkout поддиректории решается через sparse (см. документацию git 1.7 и выше).
Дискуссия себя изжила, если этот разговор глухого и слепого можно так назвать. Изучаете новое, это не помешает и делайте для себя выводы.
Ещё в пользу SVN (я тот самый аноним который использует git для кода) большому счёту из-за архитектурных особенностей распределенных репозиториев типа git, действительно на практике работа с подкаталогами в SVN действительно более удобно реализована. Но опять же, хоть это и другой вопрос: но следует ли пихать всё на свете в одно дерево.
>SVN проще для понимания, позволяет работать с одним репо, а не плодить на каждый проект.Я вижу Вы созрели для bazaar.
> ...
> Довольно удобное и частое применение. Особенно когда используется один репозиторий для
> кода, а не лапша из десятков маленьких git-иков.
> ...
> По архитектуре - может быть. А по удобству распределенные системы сливают тому
> же SVN. SVN проще для понимания, позволяет работать с одним репо,
> а не плодить на каждый проект.Досточтимый сэр пробовал _работать_ с svn-репозиторием boost'а?
> Досточтимый сэр пробовал _работать_ с svn-репозиторием boost'а?нет. я вообще не работаю с С/С++ ;)
> Программный код же будут хранить во всяких аля-git
> системах. И это хорошо, не зачем плодить велосипеды делающие то же
> самое, а так у Subversion есть будущие.аля-git убоги - они простейшую даже фичу как checkout под-директории не осилили. Для своих проектов у меня один! SVN и это удобно.
Нет, не путайте, это Вы не осилили как это делается. И не только папки можно отдельно, а и любой набора файлов, например отобранных по некоему критерию. Подсказка: "git sparse".Да и вообще, что Вы так нервничайте. Отличная новость, буду пользоваться и дальше обеими системами. Вам подходит для исходников, нет нескольких часов чтобы осилить альтернативу, ну и отлично, если основная работа делается хорошо.
> Нет, не путайте, это Вы не осилили как это делается. И не
> только папки можно отдельно, а и любой набора файлов, например отобранных
> по некоему критерию. Подсказка: "git sparse".спасибо, почитаю.
> Да и вообще, что Вы так нервничайте. Отличная новость, буду пользоваться и
> дальше обеими системами. Вам подходит для исходников, нет нескольких часов чтобы
> осилить альтернативу, ну и отлично, если основная работа делается хорошо.Хоть один адекватные аноним попался :)
> аля-git убоги - они простейшую даже фичу как checkout под-директории не осилили.Это вы убоги - не осилили ман почитать. Да понятное дело - высер на форуме это проще.
> Для своих проектов у меня один!
Велосипед? :)
> SVN и это удобно.
Ну если вы в проекте единственный участник, используете только 1 компьютер и на нем же установлен сервер... но в GIT можно и не извращаться так. А иначе - если сервер ремотный, то клевать при отвале сети как-то не очень, знаете ли.
с нетерпением ждем реализацию offline коммитов
> с нетерпением ждем реализацию offline коммитоввсего лишь локальные оффлайн коммиты применительно к SVN это скорее костыль будет, в то время как в нормальных системах управления версиями, такими как git и Mercurial, это на уровне ДНК, наряду с кучей других плюсов
костыль - не костыль, но пользоваться будет удобнее.
что за "нормальные системы", то не стоит путать теплое с мягким -- у svn есть своя ниша, в которой он неплохо живет. говорю это как пользователь git-svn со стажем
> костыль - не костыль, но пользоваться будет удобнее.А какой смысл в удалении гланд через задний проход, когда в DVCS такая фича получается сама и на халяву, в силу принципов работы? По-моему, если вам нужна независимость от сервера и возможность полноценной работы оффлайн, проще всего просто перейти на dvcs типа git'а. После этого можете хоть емэйлом синхронизироваться, отсылая патчи друг другу и вообще не имея центрального сервера, например. А можно и с ним.
>> костыль - не костыль, но пользоваться будет удобнее.
> А какой смысл в удалении гланд через задний проход, когда в DVCS
> такая фича получается сама и на халяву, в силу принципов работы?
> По-моему, если вам нужна независимость от сервера и возможность полноценной работы
> оффлайн, проще всего просто перейти на dvcs типа git'а. После этого
> можете хоть емэйлом синхронизироваться, отсылая патчи друг другу и вообще не
> имея центрального сервера, например. А можно и с ним.DVCS не всегда удобны. SVN для некоторых задач удобнее применять, чем DVCS.
> DVCS не всегда удобны. SVN для некоторых задач удобнее применять, чем DVCS.Лично мне вот нихрена не удобно зависеть от какого-то сервера где-то в дубенях. А еще я могу пользоваться десктопом и ноутом, например. И мне как-то ну совсем не удобно зависеть от наличия интернета или конективити между ними на 100%. А в свн если напортачить то даже на энную ревизию без сервака не откатишься нифига. Извините, но это - каменный век.
для начала, почитайте про бритву Оккама и принцип kiss
> для начала, почитайте про бритву Оккама и принцип kissА можно я вас шарахну вашим же оружием? Да, мистер, гребаный сервер svn - абсолютно лишняя сущность, полностью согласен. В git можно и совсем без сервера обойтись :)
а в svn без сервера обойтись нельзя?
> а в svn без сервера обойтись нельзя?Для начала попробуйте посмотреть историю (aka svn log) без сервера...
для локального репозитария (не checkout'а) - без проблем. локально все коммиты не хранятся и в некоторых случаях это плюс по сравнению с, скажемем, git'ом: если репозиатарий содержит чуть больше, чем 100^W50% часто изменяющихся бинарных файлов (верстка, к примеру), тянуть всю историю их изменений не особо приятно. если даже забыть о плохо жмущихся бинарных файлах, то тянуть историю за 10 лет, тоже не особенно приятно, а без нее, к примеру, локальный annotate корректно работать не будет.
Изменения замечательные, только опоздали лет на 5 - для всех немногих проектов, что ещё используют svn для репозитория, клиентом давно используется git-svn, где уже давно есть всё перечисленное и намного больше.
Ваше мнение важно для всех, кто использует svn.
может быть ктото кто испольузет Svn (хотябы 1 человек из ста :)) -- возьмёт да решит-таки изучить/использовать/перейти на Git...практика говорит о том что рано или позно это случается с почти каждым svn-щиком.. а дальше только мысли на подобие "и почему я раньше этого не сделал? зачем я так долго фанатично сопративлялся?" :-)
>практика говорит о том что рано или позно это случается с почти каждым svn-щиком.Чья практика? Есть куча применений, где git попросту неприменим.
> Чья практика? Есть куча применений, где git попросту неприменим....а ещё есть куча применений Svn в случаях когда по хорошему применим Git :-)
Ну и где? Вообще-то функциональность git - надмножество оной svn, так что это бред.
> Ну и где? Вообще-то функциональность git - надмножество оной svn, так что
> это бред.А при чём тут вообще функциональность? Я про удобство использования. В git нет докачки, в git нет удобных номеров ревизий, в git нет возможности работать с частью проекта... Просто у некоторых походу git головного мозга, раз они так легко октазались от столь очевидных удобств.
> А при чём тут вообще функциональность?Действительно - при чём, когда от VCS нам нужна не функциональность, а подпорки под нашу ограниченность и привычки к допотопщине. Признайтесь, вы с git и не работали.
> Я про удобство использования
Удобство - это для начала, нормальный merge и cherry-pick, не говоря уже о rebase, bisect, staging area с add -p, всем фичам по history rewriting да и банальных локальных коммитах. Ну вам конечно, на всё это плевать - вам дорог зухель 33600, вы привыкли к чиселкам и вы привыкли всё запихивать в один репозиторий, чтобы потом выкачивать оттуда части. И громко заявляете что git неприменим. Даже жаль таких как вы.
> Действительно - при чём, когда от VCS нам нужна не функциональность, а подпорки под нашу ограниченность и привычки к допотопщине.В чём допотопщина? В отсутствии 100-мегабитного канала? Ну да, сейчас модно привязывать себя к интернету. Облачные сервисы специально для вас.
>Признайтесь, вы с git и не работали.Конечно, ввиду его полной непригодности и повышенным требованиям к сети.
> Удобство - это для начала, нормальный merge и cherry-pick, не говоря уже
> о rebase, bisect, staging area с add -p, всем фичам по
> history rewriting да и банальных локальных коммитах.Об этом смешно говорить, когда отсутствует столь необходимый функционал. Это как мерседес без мотора.
>Даже жаль таких как вы.
Мне, право, как-то неудобно наблюдать жалость в глазах таких вот самоограниченных людей как вы.
> В чём допотопщина? В отсутствии 100-мегабитного канала?100-мегабитный совершенно необязательно. Отсутствие разрывов связи вобщем-то не от ширины зависит.
> Ну да, сейчас модно привязывать себя к интернету.
А вам это не нравится? А почему вы тогда пользуетесь SVN?! Там даже чтобы лог посмотреть нужно подключение к сети.
> Конечно, ввиду его полной непригодности и повышенным требованиям к сети.
Git, в отличие от, позволяет полноценно работать полностью оффлайн, так что можете прекратить отмазки придумывать.
>Отсутствие разрывов связи вобщем-то не от ширины зависит.Ещё как зависит. Чем дольше сессия, тем больше вероятность, что её разорвут. Да что там говорить, даже браузер фурифокс давно докачку умеют, не говоря уж про какой-то отсталый svn.
>А вам это не нравится? А почему вы тогда пользуетесь SVN?! Там даже чтобы лог посмотреть нужно подключение к сети.В 21-м веке подключение не проблема. Хоть через телефон с шнурком. Только сразу вскрываются все недостатки git. Странно наблюдать их в такой "продвинутой" vcs
>Git, в отличие от, позволяет полноценно работать полностью оффлайн, так что можете прекратить отмазки придумывать.Да, отличный оффлайновый генератор коммитов получается. Только какое это отношение имеет к VCS? В вопросе коллективной разработки, конечно же.
> Ещё как зависит. Чем дольше сессия, тем больше вероятность, что её разорвут.Историю надо скачать один раз. Извращенцы на модемах это могут сделать хоть скопировав .git по правоставной ftp'шечке с докачкой.
> Да, отличный оффлайновый генератор коммитов получается. Только какое это отношение имеет к VCS? В вопросе коллективной разработки, конечно же.
Можно сделать push. Ты не знал?
>Историю надо скачать один раз. Извращенцы на модемах это могут сделать хоть скопировав .git по правоставной ftp'шечке с докачкой.svn log > log.txt Вот тебе и история. А сидеть дома у анлима гораздо большее извращение.
>Можно сделать push. Ты не знал?А про pull ты забыл? Странно, ещё пользователем гит себя называешь.
> svn log > log.txt Вот тебе и история. А сидеть дома у анлима гораздо большее извращение.Так и запишем. Чтобы работать с svn надо руками собрать текстовички с логами для каждого файла и каждой директории, для которой мне может понадобиться посмотреть лог, т.е. для всех.
> А про pull ты забыл? Странно, ещё пользователем гит себя называешь.
Ты давай разберись о чём речь ведёшь, костылевод. push/pull передают только новые коммиты, так что даже твой зухель справится. И гораздо быстрее чем svn в сколь-либо большом дереве обойдёт все директории.
> В чём допотопщина? В отсутствии 100-мегабитного канала? Ну да, сейчас модно привязывать
> себя к интернету. Облачные сервисы специально для вас.Гым, в SVN даже на более старую ревизию без интернета не откатиться если понял что где-то напортачил. Тогда как в git локально лежит вся база изменений - взял да и откатился одной командой. Без интернета. Именно поэтому он столько и льет в первый раз.
Если использовать гит не для задроства в стиле гентусятников "скачал чтобы скомпилить самую-самую версию" а чтобы _разрабатывать_ - это отличная штука. А то что dvcs не очень заточены на ушибленых задротов с манией пересборки свежака из сырцов без участия в разработке - проблемы только этих (бесполезных для окружающих) задротов.
Если у вас не тексты, а PSD какие-нибудь, 90% всего этого не работает. А версии по-прежнему зранить надо - причем не программистам, а людим, для которых SHA1-хеш - это такая разновидность мата.А вот последовательные номера ревизий в централизованном репозитории - очень понятная модель. И ни ветки, ни куча репозиториев, ни, в общем-то, совместная работа им сто лет не нужна - а нужно,чтобы было одно хранилище (поддерживаемое квалифицированным персоналом), из которого можно достать любую версию конкретного документа.
> Если у вас не тексты, а PSD какие-нибудь, 90% всего этого не
> работает. А версии по-прежнему зранить надо - причем не программистам, а
> людим, для которых SHA1-хеш - это такая разновидность мата.А вот последовательные
> номера ревизий в централизованном репозитории - очень понятная модель.
> И ни ветки, ни куча репозиториев, ни, в общем-то, совместная работа им сто
> лет не нужна - а нужно,чтобы было одно хранилище (поддерживаемое квалифицированным
> персоналом), из которого можно достать любую версию конкретного документа.Если наличие центральной точки отказа и пожизненная ограниченность исключительно линейной историей --- для Вас приемлемая плата за 1.2.3.4.5, то таки да, возразить нечего. Кстати, присмотритесь тогда к SCCS --- Вам должно понравиться.
> Если наличие центральной точки отказаВ описываемом случае это скорее плюс, так как эта "точка" обслуживается квалифицированным персоналом, который несомненно наладит регулярное резервное копирование (резервировать то, что собрано в одном месте на порядок проще), а вот локальные коммиты в случае DVCS будут незарезервированы черт знает сколько времени у неквалифицированных пользователей.
Это не говоря уже о том сколько проблем они создадут себе и всем вокруг когда будут пытаться бранчить,мержить,пушить,пулить,... - это вам не простой как ведро update/modify/commit. А на решение всех трудностей будет тратиться время невиновного квалифицированного персонала, у которого, кстати, и своих задач может быть "по горло", но вместо их решения люди будут копаться в чужих конфликтах и бесплодных попытках объяснить, что "Вот здесь надо было сделать вот так, а у вас тут песец получился, который специально захочешь - не повторишь. Что? Вы ничего не трогали? Оно само?".
>> Если наличие центральной точки отказа
> В описываемом случае это скорее плюс, так как эта "точка" обслуживается квалифицированным
> персоналом, который несомненно наладит регулярное резервное копирование (резервировать
> то, что собрано в одном месте на порядок проще),Этот use-case идентичен во всех VCS, в которых есть 'нелокальность'. Ни разу не особенность Subversion. У систем с централизованным репозиторием просто нет ряда use-cases, которые есть в DVCS.
> а вот
> локальные коммиты в случае DVCS будут незарезервированы черт знает сколько времени
> у неквалифицированных пользователей.
> Это не говоря уже о том сколько проблем они создадут себе и
> всем вокруг ..."Ни одна VCS не заменяет коммуникации между участниками процесса".
Тогда твой выбор Mercurial - это простота svn-а (номера ревизий цифрами в локальной копии), есть external-ы для hg svn и git, есть много разнообразных плюшек и фишек, которые есть в svn. Mercurial - это следующий шаг после svn, шаг вперед.
+ нормальный кроссплатформенный GUI - TortoiseHG (на PyQt для Mercurial, работает на всех ОС, а не как TortoiseSVN, который только в нормальном виде только для венды)> А при чём тут вообще функциональность? Я про удобство использования. В git
> нет докачки, в git нет удобных номеров ревизий, в git нет
> возможности работать с частью проекта... Просто у некоторых походу git головного
> мозга, раз они так легко октазались от столь очевидных удобств.
добавлю, что работа с частью репозитория так же возможна, можно коммитить только ту ветку каталога, с которой работал, это как в svn - я так делал в svn и делаю в Mercurial
> добавлю, что работа с частью репозитория так же возможна, можно коммитить только
> ту ветку каталога, с которой работал, это как в svn -
> я так делал в svn и делаю в MercurialПолностью поддерживаю. Есть правда один минус - это ничего не умеющее тормозное г на петоне. А так да.
>Есть правда один минус - это ничего не умеющее тормозное г на петонеА что с питоном не так? И чего оно умело бы, если бы не питон?
> А что с питоном не так? И чего оно умело бы, если бы не питон?Оно бы не умело так зверски тормозить. Питонистов на кол надо - они заботятся только о удобстве своего кодинга, а о том что случится с теми кто пользуется их г@внокодом их вообще не волнует. Особенно прикольна свистопляска с полудюжиной версий питона. Несовместимых, бл.
> добавлю, что работа с частью репозитория так же возможна, можно коммитить только
> ту ветку каталога, с которой работал, это как в svn -
> я так делал в svn и делаю в MercurialТак ни кто не против ртути. Но вот после тестов выяснилось, что докачки опять нет. Зачем нужна тулза с таким убогим функционалом? Зависимость от анлима напрягает меня гораздо сильнее отсутствия децентрализованности.
> добавлю, что работа с частью репозитория так же возможна, можно коммитить только
> ту ветку каталога, с которой работал, это как в svn -
> я так делал в svn и делаю в Mercurialкак сделать checkout части репозитория?
работал с Hg, но данной фичи не обнаружил (((
> как сделать checkout части репозитория?
> работал с Hg, но данной фичи не обнаружил (((А почему, собственно, sin не больше 1? Мне больше надо! ;)
Опишите, мне, пожалуйста, процедуру branch'а, если Вы сделали checkout части репозитория.
Возможность checkout части репозитория ведёт к тому, что каждый каталог есть как-бы репозиторий. А это, в свою очередь, означает, что перемещение источников внутри репозитория создает изрядное количество проблем с историей (что, кстати, и имеем в Subversion; там это усугубляется тем, что branch'а, а заодно и tag'а, собственно-то и нет). И, конечно, возможность checkout части репозитория --- существенно требует единственного (центрального) репозитория.
> Опишите, мне, пожалуйста, процедуру branch'а, если Вы сделали checkout части репозитория.а зачем? для моих задач (к примеру хранение фоток) branch не требуется, а checkout поддиректории - нужен.
> Возможность checkout части репозитория ведёт к тому, что каждый каталог есть как-бы
> репозиторий. И, конечно, возможность checkout части репозитория ---
> существенно требует единственного (центрального) репозитория.Да. Это и нужно.
> В git нет докачкиНа http IIRC. SVN на plain http вообще не вывесить.
> в git нет удобных номеров ревизий
Удобных -- это когда надо бы разумно идентифицировать две разных параллельных модификации одной ревизии (ну работали два человека одновременно каждый в своём офлайне), а никак? :)
Ревизии -- это ахиллесова пята, которая в принципе прибивает к единому номеродателю. А игры в точки вскоре начинают напоминать SNMP какой-то.
Это не говоря о том, что хэши в качестве идентификаторов имеют и другие побочные свойства помимо надёжной проверки наследования -- например, делают осмысленным и достаточно практичным тот же --amend: поправил содержимое -- получилось другое состояние, но со старым вариантом уже не перепутаешь.
> в git нет возможности работать с частью проекта...
Можно рассказать, где используется и осмыслена такая организация проекта? Прям интересно стало (без подколов). Тут вон до git submodules руки не доходят, как-то всё не требуются.
> Просто у некоторых походу git головного мозга, раз они так легко октазались
> от столь очевидных удобств.Про одно Вы неправду сказали, про остальные два -- как минимум неовечидно/противоречиво. И это всё не к тому, какой гит замечательный, а к тому, что критика не по адресу вышла.
PS: а новости -- +1 :)
>На http IIRC. SVN на plain http вообще не вывесить.А тупо посмотреть список файлов и скачать недостающие оно конечно не может. Печально. И что за идиотизм упираться в plain http?
> Ревизии -- это ахиллесова пята, которая в принципе прибивает к единому номеродателю. А игры в точки вскоре начинают напоминать SNMP какой-то.
Ну-ну. Очередная дутая проблема. Ну или любовь делать коммиты на каждый чих.
> Можно рассказать, где используется и осмыслена такая организация проекта? Прям интересноПро модульность товарищ, конечно, не слышал. Это прискорбно.
>Про одно Вы неправду сказали, про остальные два -- как минимум неовечидно/противоречиво. И это всё не к тому, какой гит замечательный, а к тому, что критика не по адресу вышла.По пунктам, пожалуйста. У гита есть докачка? У гита есть читаемые номера ревизий? Гит научился работать с частью дерева проекта? Нет. Поэтому тут я могу услышать только, мягко выражаясь, пустой трёп. Работать он от этого тоже не станет. В отличие от...
> или любовь делать коммиты на каждый чих.вообще-то да: поправил — закоммитил. это утята с svn предпочитают наколбасить мегатонну кода и потом её таким вот блобом коммитнуть. а всё потому, что сервер — централизованый, если туда закоммитить что-то полурабочее (или вообще поломаное), весь бизнес встанет колом. у гитовцев таких странных и надуманых проблем нет: коммить себе хоть каждую строку, билды от этого не лягут. зато отлично видно, что именно менял, как, где, черрипики и бисекты делать удобно.
впрочем, людям с svn это не понять: для них слово «удобство» — ругательное.
Пример ситуации, когда весь репозиторий вообще никому не нужен - орда дизайнеров, сохраняющих в него очередные версии своей работы. У каждого дизайнера - свой каталог, к которому он имеет доступ на запись, к некоторым другим - на чтение. Совместная работа и ветки не нужны как класс - нужна возможность сохранить очередную версию там, где её даже намеренно не прибьёшь, не говоря о случайностях.
>> в git нет возможности работать с частью проекта...
> Можно рассказать, где используется и осмыслена такая организация проекта? Прям интересно
> стало (без подколов). Тут вон до git submodules руки не
> доходят, как-то всё не требуются.Я храню в нем фотки - есть возможность выгрузить фотки одного сезона или одной поездки. Структура каталогов иерархическая. Удобство SVN в том, что удаленно подключаюсь с любого компа и получаешь точную копию фоток. Если случайно удалил, то восстановление - элементарно.
Использование одного! репозитория для всех проектов. Удобно использовать для своих личных приложений (pruf of consept).
Единый репо для несколько малых (до 10 человек) команд пилят различные модули одной системы. На запись можешь вести только в свое приложение, а при необходимости обновить внешние интерфейсы делаешь шаг вверх и update. Дальше одной командой пересобираешь и чужие и свои приложения.
> (pruf of consept).Мде, если вы даже название приложения написать не можете правильно - представляю себе что там в коде творится.
>> (pruf of consept).
> Мде, если вы даже название приложения написать не можете правильно - представляю
> себе что там в коде творится.да, быстро писал слово по звучанию. правильно так: proof of concept
> Есть куча применений, где git попросту неприменим.нету
>нетуА вот с аргументацией опять туго. Походу массовый гипноз, ничего не поделаешь.
> А вот с аргументацией опять туго. Походу массовый гипноз, ничего не поделаешь.Куда нам до универсального аргумента "массовый гипноз".
Гит неприменим, когда нет доверия пользователю в плане грамотного обращения с репозиторием. С SVN он закоммитил на центральный сервер - и всё, никуда результат его работы не денется, локально можно творить что угодно. А права на запись в удалённый гит-репозиторий дают слишком много свобод в плане "начудить". Нет, наверное, там можно какими-то костылями подпереть, но SVN при таком сценарии проще на порядок. Кроме того гит со своей нелинейностью истории и SHA1-хешами создаёт слишком большую когнитивную нагрузку на нетехнических польхователей, которым оно на фиг не надо, а нужен просто список версий документа с комментарием (commit message, но им мы это говорить не будем) и датой сохранения (коммита - но это мы тоже говорить не будем). Имеем действительно удобный версионник для непрограммистов - дизайнеров, юристов и т.п.
> нужен просто список
> версий документа с комментарием (commit message, но им мы это говорить
> не будем) и датой сохранения (коммита - но это мы тоже
> говорить не будем).Еще им часто надо легко и автоматически получать всегда актуальные документы, которые делают коллеги из соседней комнаты, вместо "скинь мне на флешку последний вариант договора" и "Вася на той неделе вроде чего-то менял в смете - позвони ему и ,если он на месте, пусть по почте пришлет". С DVCS ситуация у "нетехнических" пользователей будет похуже чем "принести на флешке" (с флешкой они все-таки обычно могут управиться без посторонней помощи).
> Чья практика? Есть куча применений, где git попросту неприменим.Почему-то мне кажется что случаев когда наоборот - намного больше. Перец с оффлайн-коммитами выше как бы намекает... ;))
Это правда - я лично перешел на git-svn сразу после того как мне его показали.
> Это правда - я лично перешел на git-svn сразу после того как
> мне его показали.Ну так люди легко поддающиеся внушению были всегда. Иначе пришлось бы отрицать такое явление как гипноз.
> Ну так люди легко поддающиеся внушению были всегдаСамовнушению, чтобы сидеть на г-не мамонта и считать что это правильно, вы хотели сказать? Так и CVS используют. Всё проще - есть люди, недостаточно поддающиеся любознательности. Осиль я сам прочитать пару глав pro git чтобы понять что он умеет - перешел бы давно сам. А так мучался пока не показали что есть svn, а есть системы контроля версий.
>Всё проще - есть люди, недостаточно поддающиеся любознательности.А при чём тут любознательность? У гита отсутствует ряд необходимых мне фич. Об этом я прекрасно осведомлён.
>А так мучался пока не показали что есть svn, а есть системы контроля версий.Это опять голословно. Очень похоже на результат внушения.
> А при чём тут любознательность? У гита отсутствует ряд необходимых мне фич.А у SVN отсутствует ряд фич в еще более злобном виде. Самой злобной из проблем является то что оно вообще ничерта не может при отсутствии сервака.
Поэтому:
1) Падение сервака = пи...ц работе! Полный. Надолго.
2) Без интернета или сервака в локалке в принципе нереально работать. У GIT в 100500 раз больше вариантов, вплоть до переноски патчей флоппинетом, если по другому в неких условиях не получается.
3) Отматывать на разные версии - нудно, медленно, геморройно и опять же требует живой сервер. Ублюдство.
Видите ли, падение сервака - это проблема администраторов. Которые могут и профилактические меры принять, и устранить неполадки достаточно быстро. А угробленный локальный репозиторий - это проблема пользователя, который, если он не программист/админ, необходимыми навыками не обладает в получает большой геморрой на ровном месте - особенно потому что был уверен, что всё надёжно.
> Видите ли, падение сервака - это проблема администраторов.Нет, извините, нагнувшаяся работа - это проблема того у кого она нагнулась. Хотя, конечно, если вы заняты протиранием портков на работе - оно конечно да, отмазка удобная. А вот если результативность волнует - тогда опаньки, svn получается дерьмищем полным.
> Которые могут и профилактические меры принять, и устранить неполадки достаточно быстро.
Ну вот допустим выехал я с нотиком на природу, в местность куда даже гсм не достреливает. Ваши предложения по админскому решению вопроса? Админ должен прийти и построить мне там БСку или протащить в окрестности мухосранска эзернет-кабель? В случае гита то - ему похрену что интернета нет, вся база - локально, и я могу работать с ним где угодно "как если бы у меня был доступ к серваку svn". Потому что я сам себе самодостаточный сервак со своей базой. Более того, если рядом оказался Вася желающий засинкаться со мной - мы можем хоть флоппинетом перекинуться своими изменениями. А вот с SVN в этом плане - сплошная попаболь: нет сервера - нет результата. Железобетонно и уныло.
> А угробленный локальный репозиторий - это проблема пользователя,
В SVN нет полноценного локального репозитория, позволяющего отмотать на несколько ревизий в сторону без наличия сервака. А в гите полная база копируется.
> который, если он не программист/админ, необходимыми навыками
> не обладает в получает большой геморрой на ровном месте - особенно
> потому что был уверен, что всё надёжно.Честное слово, плачи нигр о том что микроскопом как-то не очень удобно гвоздь вбивается - меня трогают крайне слабо.
>Самовнушению, чтобы сидеть на г-не мамонта и считать что это правильно, вы хотели сказать?Это вы про гит? Полностью согласен.
> Это вы про гит? Полностью согласен.Git по сравнению с svn - как иномарка vs крестьянская телега. Оба конечно средства передвижения, хрен поспоришь. Но почему-то лошади нынче используются чуть реже чем иномарки.
хрен ваша иномарка проедет по нашим деревенским дорогам
> хрен ваша иномарка проедет по нашим деревенским дорогам…и поэтому мы не будем чинить дороги, лучше пересядем на лошадей.
одно другому, в общем-то, не мешает. но нахрена прокладывать кошерные дороги там, где нужно проехать пару раз в году? неприхотливые лошадки тут всякой поэффективнее будут
право слово, если уж дошло до использования системы контроля версий — то это никак не «раз в год» получается. иначе хватило бы просто тупых каталогов на сервере и архивчика.
вы таки будете в шоке, но где-то действительно и тарболами неплохо обходятся. но это скорее лирика, как и аналогии с лошадьми и машинами.
да, и почему вы считаете, что системы контроля версий нужны только для многочисленных каждодневных коммитов? даю подсказку: текстовые файлы используются не только в программировании
> Рабочие копии мета-данных, ранее разбросанные по всем директориям (каталоги .svn), теперь сохраняются в одном месте - в корне рабочей копии проекта создаётся одна директория ".svn", мета-данные в которой сохраняются с использованием SQLite.Убрали возможность клонирования только части дерева исходников? Чтобы затем работать только с ней...
> В этой же директории хранится и копия изначального содержимого всех файлов проекта (вместо text-bases отныне данные хранятся как pristines).
Вообще мутная фраза. Файлы имеют свойство появляться в процессе развития проекта. Что подразумевается под изначальным содержимым?
> Недостатком использования SQLite являются возможное усложнение резервного копирования, так как простое копирования файла базы во время работы с ней библиотек Subversion может привести к нарушению целостности.
Это совсем печально.
s/клонирования/копирования/С сервера или локально копировать --- не важно.
> Убрали возможность клонирования только части дерева исходников? Чтобы затем работать только с ней...Как раз клонировать можно. Проверял. Вот с остальным проблемы.
> мета-данные в которой сохраняются с использованием SQLite.эпик фейл...
Какой fail? Давно ожидаемое улучшение. Вместо миллиона файлов - одна база.
когда sqlлайтная база распухнет и зафрагментируется, тогда и вкусишь всю прелесть этого решения. Можно похожее найти в ff, где живой поиск в адресной строке через какое-то время начинает дико подвисать на секунды с завидной регулярностью.Это действительно эпик фейл. Для задач SVNа можно сделать своё простое хранилище без каких-либо существенных затрат чч. Нет млять, как это часто бывает последнее время, какой-нибудь олигофрен в проекте прикрутит пушку к мухе.
инстантвин, ясчитаю
Ну приехали, SQLite и одна .svn. Теперь я даже там где вроде бы не нужен git не хочу использовать svn. Видимо, всё-таки, централизованные VCS умерли как класс.
достаточно революционная версия. уместнее было бы назвать svn 2.0, чтобы не путаться в форматах репозитория.
> В случае гита то - ему похрену что интернета нет, вся база - локально, и я могу работать с ним где угодно "как если бы у меня был доступ к серваку svn". Потому что я сам себе самодостаточный сервак со своей базой.у меня репозитарий 950Гб, ты предлагаешь каждому сотрудника носить с собой локальную копию на ноуте? А чо удобно, все под рукой :D У каждого продукта своя ниша применения и не надо путать мягкое с теплым.
> Ну приехали, SQLite и одна .svn.
религия не позволяет использовать? Или будут аргументы?
> когда sqlлайтная база распухнет и зафрагментируется, тогда и вкусишь всю прелесть этого решения.
про дефрагментаторы что нить слышал? Следуя твоей логике NTFS вообще мертвая ФС :D
> религия не позволяет использовать? Или будут аргументы?когда переведёшь свой 950Гб репозиторий на sqlite и svn, тогда и узнаешь все 'прелести' этого решения
> про дефрагментаторы что нить слышал?
мы ещё слышали про DBAшника. Дефрагментаторы это вчерашний день, для такого гогна теперь нужно будет иметь целого DBA.
> у меня репозитарий 950Гб, ты предлагаешь каждому сотрудника носить с собой локальную
> копию на ноуте? А чо удобно, все под рукой :D У
> каждого продукта своя ниша применения и не надо путать мягкое с
> теплым.http://www.opennet.ru/openforum/vsluhforumID3/80746.html#85