После почти двух лет разработки вышла (http://permalink.gmane.org/gmane.comp.version-control.subver...) новая версия Subversion 1.5. Среди особенностей (http://subversion.tigris.org/svn_1.5_releasenotes.html) нового релиза можно выделить:- Возможность отслеживания изменений при слиянии — позволяет проследить когда и где были произведены объединения кода. Функция полезна для работы с «ответвлениями» основного проекта. К настоящему времени реализована только базовая функциональность, поэтому ожидается, что работать слияние будет достаточно медленно. Дальнейшие улучшения запланированы на версию 1.5.1 и выше.
- Интерактивное разрешение конфликтов — теперь, при обнаружении конфликтов при выполнении команд update/switch/merge, клиентская программа предлагает варианты устранения противоречий.
- Поддержка списка изменений (changelist) — управляемый клиентской программой список, позволяющий запомнить имена файлов для последующего выполне...
URL: http://subversion.tigris.org/svn_1.5_releasenotes.html
Новость: http://www.opennet.me/opennews/art.shtml?num=16581
Если Improved support for large deployments on FSFS, via sharding
перевели как Возможность разбиения репозитория на разделы,то это не совсем верно это не разделы, а 2-х уровневая иерархия директорий на FS.
Централизованные системы контроля версий MUST DIE.
GIT в народ :) !!!
Не так то это просто.... "мышки мучались, кололись, но продолжали жрать кактусы".
Уважаемый, Вы хоть одной системой контроля версий попользуйтесь, для начала, а уже потом кричите "маст дай" и так далее.
он прав. сабж это ужас.
много лет мучался с cvs. когда ушел на mercurial это как глоток свежего воздуха
Что-то ваша логика не прозрачна. Пользовались значит CVS, а ужас почему-то SVN.
Автор знает, что CVS != SVN, или для него черное и белое - всё едино?
>Автор знает, что CVS != SVN, или для него черное и белое
>- всё едино?абсолютно пофиг, просто ли ерунда, или «улучшеная ерунда». как ерунду не улучшай, ответ всё равно один: git.
Вы сами в биореактор пройдёте, или вам дорогу указать?Есть некие инструменты (CVS, SVN). Возможно, для всех ваших задач они не подходят, а git подходит.
Есть некие инструменты (молоток, отвёртка). Возможно, для всех ваших задач они не подходят, а микроскоп подходит.
Некоторые гвозди микроскопами забивают, им это удобно. Дык пожалуйста. Что, разве от этого молотки хуже? Не умеете ими пользоваться, или не хотите - пожалуйста.
С тем же успехом можно до посинения спорить, что лучше: emacs или NetBeans.
Мой опыт с системами контроля версий (load time :))
6 лет CVS (с 1996 года)
2 года SUBVERSION (с 2002 года)
3 года BITKIPER (с 2001 года)
2 года GNU ARCH (с 2004 года)
2 года GIT (с 2006 года)Средний размер проекта 100M
Размер GIT репозиториев моего отдела 2.5GbТак что я понимаю о чем говорю.
Централизованные системы контроля версий must die!
Расскажите, как недостатки или архитектурные особенности систем контроля версий сказывались на рабочем процессе Вашего отдела ?
PS: Или у Вас: "Существует два мнения - мое и неправильное" ?PPS:
>3 года BITKIPER (с 2001 года)
Так и не запомнили, как оно правильно называется ?
вопрос прям как при приеме на работу :-)
или у прокурора...
>Так и не запомнили, как оно правильно называется ?а чего его помнить?
про централизованные системы не скажу, но этот BitKeeper точно надо отправить на пенсию.
но с почетом...
все таки заслужил.
Недостатки CVS, SVN.
0. Коммиты не атомарны (и что бы там не писли разработчики SVN они за слова не отвечают)
1. Плохо работает с branch
a) проблеммы с историей при merge
b) проблеммы с коммитами на win машинах
c) проблеммы со скоростью работы
d) просто это не удобно
2. bisect отсутствует (поиск льва в пустыне)
3. проблеммы с историей и merge если переименованы файлы и их кто-то правил (фактически эта фича в SVN не работает в нетепличных условиях)
4. все работает медленно (значительно медленнее bitkip)
5. система допускает потерю изменений при неосторожной работе
6. система централизованная (это большой недостаток для распределенного проекта)
7. репозиторий занимает дохрена
8. дохрена лишних сервисных файлов
9. SVN за собой тянет шоблу библиотек и тяжело настроить native сборки для embedded продуктов.
10. нет достаточной поддержки subproject.Недостатки bitkiper
1. непомерно дорогая лицензия для коммерческого использования.
2. для GPL проектов использовать нельзя (и вообще они очень плохо поступили в 2005году и мне пришлось много гемороится чтобы перетаскивать свои linux-ppc и linux-mips ветки на git)
3. bitkiper значительно тормознее GIT
4. нет нативной интеграции с bugzilla
5. нет достаточной поддержки subproject.Недостатки GNU ARCH
1. под windows работает только под cygwin
2. локальный репозиторий занимает недопустимо много места.
3. работает тормознее bitkiper
4. нет нативной интеграции с bugzillaНедостатки GIT
1. нет нативной интеграции с bugzilla (однако это вопрос времени)
>Недостатки GIT
>1. нет нативной интеграции с bugzilla (однако это вопрос времени)2. Нет "нативной" поддержки модели разработки всё-дерево-в-одном-репозитарии. (FreeBSD)
3. Нет "нативной" поддержки разработчиков с ограниченными возможностями. (Win*)
4. Всё никак не перепишут самые "нативные" части с питона на. (Kolchoogin)
5. "Сложный он. Это ж сколько сил надо-то, чтоб всё *это* осилить. Ну, да, мне и не особо надо-то." (?;ммм... награда :-P ищет своего Героя)
6. Торвальдс обозвал меня <вставить цитату из google-видео>! %``-(
>Недостатки bitkiperНе возможность за два года запомнить название инструмента, сводит все ваше "авторитетное" мнение к нулю.
>>Недостатки bitkiper
>
>Не возможность за два года запомнить название инструмента, сводит все ваше "авторитетное"
>мнение к нулю.Я пользовался алиасом bk, а имя инструмента намеренно искажено т.к. эти ребята коммерческие козлы и я потерял историю изменений двух своих embedded веток ядер из-за их политики отношния к opensource. (и не надо упрекать меня за то, что не слежу за политикой производителя ПО, а в место этого работаю)
BTW. в свое время bitkeeper был хорошим инструментом, теперь RIP т.к. есть git, hg, bz.
PS. Меня бесят посты в листах рассылок типа ребята я тут вам поднял GIT зеркало из своего SVN, тока вы туда не комитте всеравно я каждый раз его заново создаю. И следующий пост... Ребята я тут еще раз переименовал пару файлов ато SVN куда-то дел мой коммит две недели назад. И вслед за ним извените я не помню, что там было в merge конфликте двух веток пофикшено вы уж сами разбирайтесь...
Сам-то понял что сказал?
Пользуем SVN для коллективной рабы не представляем как можно былобы жыть без неё