Объявлено (http://svn.haxx.se/dev/archive-2010-11/0475.shtml) о выходе новой версии централизованной системы контроля версий Subversion 1.6.15, в которой отмечено 19 исправлений (http://svn.apache.org/repos/asf/subversion/tags/1.6.15/CHANGES), которые имеют корректирующий характер. Пользователям рекомендуется обязательно провести обновление, так как в версии 1.6.15 исправлены две ошибки, которые могут приводить к краху сервера (DoS-атаке) при определенной активности клиента. Версия Subversion 1.6.14 была пропущена из-за ошибки, обнаруженной на последней стадии выпуска релиза.URL: http://svn.haxx.se/dev/archive-2010-11/0475.shtml
Новость: http://www.opennet.me/opennews/art.shtml?num=28771
Кто-то еще пользуется этим старьём?
Я пользуюсь. Или вы для каждого похода в ларёк за сигаретами по новой ламборджини покупаете ?
-я работаю с X!-А как тебе Y и Z?
-Эээ...ээ. да они хуже!! поэтому я работаю только c X! Чем хуже? эээ.. ты не поймёшь!!
Вместо x и y можно смело подставлять git и svn, qt и gtk, cmake и autotools, bsd и linux; люди скатываются на ругань, ибо они защищаются - они защищают свой уровень компетентности от оскорбительного предположения, что они просто не работали с альтернативами, переходят на личности вместо обсуждения реальных областей применения.
а какая централизованная система лучше чем SVN?Децентрализованные несколько сложнее - у нас в компании до сих пор даже тестовые проекты переводить не хотятЪ )))
Если поставить в организации центральный сервер с Mercurial или Git - оно ну ничем не будет отличаться от централизованной системы.
> Если поставить в организации центральный сервер с Mercurial или Git - оно
> ну ничем не будет отличаться от централизованной системы.а зачем его ставить ? зачем мне гит или меркуриал если я буду работать с ним как с свном ? оно быстрее файлы перекачивает через сеть или памяти в 2 раза меньше жрёт ? а мб на винте места в 3 раза меньше занимает ?
на самом деле оно быстрее.
p.s. сам пользуюсь только subversion
> на самом деле оно быстрее.За счёт чего быстрее? За счёт выкачивания всего и вся?
Быстрее, насчёт памяти - незнаю, насчёт места, да меньше, ещё оно всё в одном каталоге хранит, а не в каждом подкаталоге по .svn. Иногда и это важно.
> Если поставить в организации центральный сервер с Mercurial или Git - оно
> ну ничем не будет отличаться от централизованной системы.Вообще, будет отличаться, как минимум способом доступа на запись, правами доступа (в svn это интегрировано, в git надо внешнюю надстройку ставить)
Гы-гы... Еще как будет отличаться - у девелопера будет выбор - пушать каждое изменение на центральный сервер или комитить в свой локальный индекс пока не получится что-то вменяемое, а потом пушать всю пачку. А не всем нравится, когда у девелопера есть выбор...
>Еще как будет отличаться - у девелопера будет выбор - пушать каждое изменение на центральный сервер или комитить в свой локальный индекс пока не получится что-то вменяемое, а потом пушать всю пачку.Правильно, вместо одного коммитить на каждый чих. Мечта имитатора бурной деятельности!
> Децентрализованные несколько сложнеенаглое враньё..
для Децентрализированных системы -- ВАС НИКТО НЕ ЗАСТАВЛЯЕТ пользоваться _всеми_ функциями...
...вы можете точно также пользоваться только теми функциями которые уже успели освоить в SVN
в этом случае DVCS будет такой же простой как и SVN (лично для вас. а остальные люди В ВАШЕЙ КОМАНДЕ могут использовать полный функционал DVCS чтобы делать свою работу более эффективно)
Есть адекватное описание на русском языке для git или bazaar или mercurial? Несколько раз брался за чтение манов по git, но дальше инсталляции не уходил - не понимаю бонусов DVCS, а для тестинга нужно убедить начальство в необходимости оного.Есть ли удобные тулзы типа TortoiseSVN для DVCS?
> Есть ли удобные тулзы типа TortoiseSVN для DVCS?есть TortoiseHg, TortoiseBzr и даже TortoiseGit
Попробуйте Mercurial. У него базовый набор команд совпадает с SVN. Остальные тоже достаточно интуитивно понятны.
кстати у нас одна репо на все проекты, проект вытягивается как под-под-под директория. Слышал, что git и другие DVCS не поддерживают нужную и довольно простую фичу.А без этого нужно будет писать аЦЦкий скрипт по перегонке проектов каждый в свое репо... и т.п.
> кстати у нас одна репо на все проекты, проект вытягивается как под-под-под
> директория. Слышал, что git и другие DVCS не поддерживают нужную и
> довольно простую фичу.
> А без этого нужно будет писать аЦЦкий скрипт по перегонке проектов каждый
> в свое репо... и т.п.Строго говоря каждый проект логично разместить в отдельных репах. Если речь идет о бранчах, то пользуйтесь соответствующим функционалом.
Вот этот человек переводит, краткий курс по mercurial от Джоеля Спольски.
http://bobrovsky.habrahabr.ru/blog/
>для Децентрализированных системы -- ВАС НИКТО НЕ ЗАСТАВЛЯЕТ пользоваться _всеми_ функциями...Тогда получаем одни минусы. Докачки нет + необходимость толстого канала для git clone + отсутствие человеческой метки для ревизии. Только закапывать, особенно если всеми функциями не пользоваться.
Пользуются и многие.
Представь себе такую ситуацию:
- Есть проект, над которым работают несколько человек физически находящихся в одном офисе,
- Работать с исходниками вне офиса затруднительно, т.к. используется специальное оборудование/софт/ещё что-то, что не утащишь домой/не развернёшь дома,
- Исходный код разумно спроектирован и ежедневные изменения носят локальный характер,
- Исторически проект начинался во времена централизованных VCS и управляется в данный момент SVN,
- В компании SVN интегрирован с системой багтрэкинга и всё давно хорошо работаетТеперь скажи мне Василий, зачем мне всё это ломать и что мне это даст?
Мне работу надо делать, а не "новьё" прикручивать...
видимо это может быть единственное оправдение по которому комуто приходится довольно оправданно всё ещё использовать SVN/CVSв крадце это можно описать предложением "колимся плачем, но едим кактус" :-)
...
> Теперь скажи мне Василий, зачем мне всё это ломать и что мне это даст?
очевидно же! это даст возможность делать более качественный код :-) [чем качественнее инструменты -- тем качественнее результат]
с другой стороны начальство может сказать "нам не нужно качество! нам нужно наконецто доприкрутить вон эту <фигню>, сдать заказчику.. ну а там уже пусть хоть огнём всё горит, главное бабло будет уже у нас в кормане!!"
> очевидно же! это даст возможность делать более качественный код :-) [чем качественнее инструменты -- тем качественнее результат]качество кода не зависит напрямую от качества инструментов. можно и на С/perl написать качественный код, а можно и на C# говнокодить.
> с другой стороны начальство может сказать
начальство обычно задает вопрос - сколько денег принесет (сэкономит) эта замена. Сколько будет стоит замена одной системы на другую (время админов стоит денег) + сколько будет стоить переучить программеров на использование новой тулзы (если знаете каждый час работы стоит денег).
Так вот вопрос - группа программистов в 10 человек пилит проект в SVN/trunk, делают бранчи по релизам (изменяемый, для фиксов) + tags (read-only, для конкретных выпусков что уходят в продакшен).
Какая экономия (поскольку денег это точно не приносит) будет при переходе на DVCS, за счет чего и как это можно реализовать на основе VCS?
Да чем эти DVCS качественнее SVN в приведённых мной условиях-то?
Ты вообще разницу видишь или нет?
Только давай без кактусов, а по делу...
> Мне работу надо делать, а не "новьё" прикручивать...идёте вы по лесу, гуляете...
... и вдруг видите как некий дровосек пилит дерево
..и что-то пилит дерево -- долго-дого-долго ..
(ну пила потомучто тупая, вот и пилит долго)
ну вот вы и говорите дровосеку: "тык ты пилу-то ЗАТОЧИ!, ато ведь ещё несколько дней будешь пилить это дерево (или всю жизнь :))... оно же даже на сантиметор не пропилилось!"
а дравосек вам отвечает: "НЕКОГДА мне пилу точить! мне РАБОТАТЬ надо, пилить дерево! отстань!"
____________________
# p.s.: ну вобщем -- мараль сей басни -- надеюсь вы поняли :-)
Мораль этой басни отношения к теме не имеет. А басня в данном случае звучала бы так:идут тролли, по лесу гуляют...
... и вдруг видят как некий дровосек пилит дерево
.. и нормально пилиттролли подходят и говорят дровосеку:
- Ты чо урод !!!? Этим дерьмом пилишь дерево ?!!! Надо пилить пилой хххх !!! Ну точно ламер !!! Посмотрите на него !!!Басня оканчивается когда дровосек пилит троллей этой пилой, чтобы не лезли ни в своё дело.
работу работать?
1. SVN плохо работает с бранчами. Смерджить новую фнкциональность с отдельной ветки бывает довольно таки затруднительно.2. Часто хочется доделать логически связанный кусок кода и закоммитить его одним куском, чтобы не захламлять лог например.
3. Возможно сейчас это и затруднительно, но если инфраструктура сборки относительно легко переносима на ноут или домашний комп, то вся работа может проходить в оффлайне. Я, например, иногда это делаю в поезде.
4. Ощутимо быстрее на операциях checkout/update.
1. мержить всегда сложно, или где-то используется иное чем diff+patch????
Если два и более человек правят одни и теже строки, но не один автомат не справится с логикой. Остальное решается организационно.2. нет проблем, я так и делаю в SVN
3. Я регулярно из дому работаю с SVN, хотя это и не оффлайн, но зачем коммитить не рабочий код даже в локальное репо?
4. в своей работе еще не дошел да таких объемов чтоб даже заметить это! Хотя помню что джависты вполне могут нагенерировать большие деревья исходников, но я не из тех "ох*их" поэтов.
У централизованной системы свои плюсы - например их проще вязать с трэкером. навыки работы проще, прозрачней и понятней.
> 1. мержить всегда сложно, или где-то используется иное чем diff+patch????Даже с svn используется svn merge или как вариант automerge. И тут как правило случается неприятность. Заключается она в том, что на время merge-а приходится лочить ветку. Иначе все новые коммиты после смердженной ревизии чудным образом теряются.
> Если два и более человек правят одни и теже строки, но не
> один автомат не справится с логикой. Остальное решается организационно.Решить можно всё. Оно вроде как и там и там работает. Но почему, то в DVCS комфортнее. Сами используем SVN на весьма немаленьком проекте. И вроде бы хватает, но хочется плюшек вроде cherry-pick, hq, graphlog, расцветка.
> 3. Я регулярно из дому работаю с SVN, хотя это и не
> оффлайн, но зачем коммитить не рабочий код даже в локальное репо?Код рабочий. Просто не весь. И объем кода подсказывает коммитить его логически законченными кусками. Которые в свою очередь могут развиваться серией коммитов в локальной технической ветке. Потом уже при желании можно коммитить в фиче-ветку.
> У централизованной системы свои плюсы - например их проще вязать с трэкером.
> навыки работы проще, прозрачней и понятней.С меркуриалом у вас не будет проблем. Навыки работы во много схожи.
Я не говорю, что централизованные VCS хуже/лучше. Они хороши и решают ваши задачи. Просто DVCS расширяет спектр доступных инструментов и не страдает некоторыми болезнями того же SVN. Разумеется я не призываю менять SVN на что-либо другое.
> 1. мержить всегда сложно,ох лол :-) ...до того как инженер не познакомитсья с Git/Hg/Bzr -- он так ведь действительно и думает :-D :-D :-D
Каждый раз на очередном проекте прошу клиента поставить SVN для проектной документации. За счет интеграции в виндовый эксплорер это получается самая простая для юзера система контроля версий.
Ребята, а что вы про darcs думаете? У кого-нибудь был опыт использования?
> очевидно же! это даст возможность делать более качественный код :-)
> [чем качественнее инструменты -- тем качественнее результат]жги дальше :D
Если дураку дать бензопилу, то он отпилит себе руки, а умный и топором срубит твое дерево
> # p.s.: ну вобщем -- мараль сей басни -- надеюсь вы поняли :-)
ты очень далек от понимания зачем все это нужно
> ты очень далек от понимания зачем все это нужноа я думаю -- что ты не можешь понять простую вещь:
инженер делает свою работу ИМЕННО ТАК, как ему ПОЗВАЛЯЮТ это делать инструменты :-)
(возможности инструментов -- формируют понимание того каким образом реализовывать работу. какими абстракциями манипулировать)
инструменты DVCS -- фокусируют внимание инженера на том КАКИЕ_СУЩНОСТИ_ПРОЕКТА необходимо менять
но SVN/CVS -- фокусируют внимание на том какие строчки в программном коде были изменены (мешая сохранению причинно-следственной связи.. засовывая все эти изменения в одну большую кучу-неразбириху)
> Если дураку дать бензопилу, то он отпилит себе руки
верно.. если дураку дать возможность пользоваться bzr -- то он точно также может работать в стиле svn [это не эффективно и в какомто смысле можно приравнять к отпиливанию руки :-)]
...но если умному отрубить руку -- то какой от этого будет толк?
Меня больше всего в svn раздражает полное отсутствие логирования.
Иногда бывает, что при комите больших файлов(десятки или сотни МБ) транзакция обрывается, клиент пишет: "соединение закрыто удаленным сервером" (клиент - черепаха) и понять при этом где проблема становится почти не реально.
А в остольном меня все устраивает и перетаскивать кучу репов общим весом в несколько сотен гигов в гит из-за того, что он новее я не собираюсь. А также переобучить больше сотни хомячков не вижу смысла.