Замечательно,

// ушёл ставить

>Subversion 1.5 is a superset of all previous Subversion releases, and is considered the current "best" release.

:)))

CVS R.I.P. ?

>Subversion 1.5 is a superset of all previous Subversion releases, and is considered the current "best" release.

как раз поэтому для него и нужен самый лучший когда-либо логотип, сделаный в самом лучшем графическом редакторе. ну вы поняли о чем я.

> Merge tracking: поддерживать ветки должно стать проще: теперь svn следит за тем, какие изменения были merged и какие доступны для merge.

наконец-то

Все таки git лучше, чем сабж, правда я не пользуюсь ни тем ни другим, и предпочитаю полагаться на undo.

Чем это поделие лучше Perforce?

>Чем это поделие лучше Perforce?

Может быть тем, что это не "поделие"?

>> Merge tracking: поддерживать ветки должно стать проще: теперь svn следит за тем, какие изменения были merged и какие доступны для merge.

> наконец-то

Там довольно ограниченный merge tracking (по признаниям самих разрабов).

А какой смысл сравнивать самый распространённый свободный продукт с нишевым проприетарным решением? Может ещё с ClearCase сравним?

>Там довольно ограниченный merge tracking (по признаниям самих разрабов).

это пока. обещают в следующем релизе улучшить механизм.

Интересно, а в этом релизе не реализовали возможность извлекать файлы изменённые с такой-то по такую-то ревизию? Или с такой-то по последнюю?

> Может ещё с ClearCase сравним?

Ну по функционалу ответ очевиден :). Вот только лично для меня свн оказался наиболее удобным решением (ибо открыт и много чего умеет - для маленьких проектов самое то).

>> Может ещё с ClearCase сравним?

> Ну по функционалу ответ очевиден :)

Это можно считать положительным отзывом о ClearCase? А то раньше мне таких не попадалось :)

>Если поставить cvs 1.5, он молча о

Шоман и макском это оказывается одно лицо..

>> Если поставить cvs 1.5, он молча о

> Шоман и макском это оказывается одно лицо..

Шоман себя под макскома чистит!

для управления очень большими проектами (когда много заказчиков, большая команда разработчиков) он имхо удобнее, хотя могу ошибаться - я тогда только начинал... :)

>Merge tracking: теперь svn следит за тем, какие изменения были merged и какие доступны для merge. Поддерживать ветки должно стать проще.

Отлично.

>Конфликты можно разруливать интерактивно в процессе апдейта.

Не помешает.

Сходил, к тому же, по ссылке. API/ABI не сломали. Хорошо. Исправили парочку маленьких назойливых багов в клиенте. Тоже хорошо. В общем, ура. Жду в unstable.

re: CVS R.I.P. ?

Доброе утро )))

re:Все таки git лучше, чем сабж, правда я не пользуюсь ни тем ни другим, и предпочитаю полагаться на undo.

Да Git лучше, как в undo у тебя с ветками? ;-)

> Это можно считать положительным отзывом о ClearCase?

Да, CC чертовски хорош :-).

> Это можно считать положительным отзывом о ClearCase? А то раньше мне таких не попадалось :)

Я один раз встретил. Товарищ восхищался dynamic views (это когда к содержимому репозитория можно обращаться как к сетевой шаре). Соответственно они там хранят скомпилированые бинарники и радуются что никуда ничего не надо деплоить. Довелось мне иметь дело с таким-же подходом. Там каждый бинарник собирал свой человек и соответсвенно _никто_ не мог собрать проект целиком. Опять таки так как каждый компилировал только свой кусок то понятное дело поломать компиляцию в другом месте и не заметить этого элементарно.

Опять-же внутри одного бранча жизнь с clearcase не сильно удобнее той же сетевой шары, поэтому на каждый чих создается свой бранч - иначе вообще труба. Так вот в той статье автор восторгался что что можно выбрать набор произвольных файлов и сделать из этого бранч. Нет у меня сил описывать все грабли, на которые из-за этого приходится наступать (притом что я пытаюсь как можно реже трогать clearcase руками (и каждый раз после этого тщательно мою руки с мылом)). Недавно получил письмо (его разослали по нескольким сотням девелоперов) со списком файлов и просьбой собраться между собой всех кто трогал эти файлы за последний _год_ и понять что с ними сделать так как смержить их нереально.

Понятно, что даже clearcase можно использовать более-менее (причем скорее менее чем более) нормально, но тот же cvs (который вменяемые люди закопали больше 5 лет назад) намного лучше не говоря уж про svn & dvcs.

Закопай cleacase - сделай мир чище!

можно ли зделать проверку оюновлений ? типо если есть обновления обновляемся и т.д. нету спим опред время, а потом опять проверяем ?

если моя телепалка меня не подводит то курить

1) commit-hooks

2) cruisecontrol (или любой другой continuous integration server)

Ненужен. Есть Git, который куда удобнее для работы.

> Ненужен. Есть Git, который куда удобнее для работы.

Ненужен. Есть Mercurial, который гораздо удобнее для работы.

Офигенно! Я очень рад, даже слегка шокирован был, когда прочитал. Сколько же ждали! :)

Многие проекты, правда, уже перешли на git, но сам я пока git не осилил и внедрять его в контору представляется сложной задачей из-за наличия пресловутых виндозников. Для Subversion есть много клиентов и хорошая документация, за счёт этого она действительно популярна.

Поздравляю всех, это весомое событие!

>Ненужен. Есть Git, который куда удобнее для работы.

Ухтыбля... ну-ка раскажи - как 30 девелоперов в одном офисе с пом. git'а будут взаимодействовать? Как говорили немцы: Edem das sein.(кажись так)

Jedem das Seine.

Не флейма ради, а интересно... :

1. Как у него щас с partial trees ?

2. А если ему сэмулировать крэш через kill -9 , он потом поймет, что что-то не так в репозитории?

3. Ну и как у него будет с откатом до рабочего состояния после этого?

СС лучшее что я видел из систем контроля версий. Для небольших проектов разумеется сильно избыточен, да.

"Дайте дураку стеклянный №уй.." Не смешивайте инструмент и процесс разработки. Если процесс гамно то инструмент слабо поможет.

В частности по части письма. Если за "последний год" ни разу не стабилизировался код, не вешалась метка, отсутствует мэйнлайн то о чем мы вообще говорим?

>> Merge tracking: поддерживать ветки должно стать проще: теперь svn следит за тем, какие изменения были merged и какие доступны для merge.

> наконец-то

Оно по-прежнему отстойное (по сути, мало отличается от svnmerge.py), и сливает по этому показателю и git, и hg. Тест-кейсы имеются.

> сам я пока git не осилил и внедрять его в контору представляется сложной задачей из-за наличия пресловутых виндозников.

Внедряй Mercurial.

[я так понял, речь о Mercurial]

> 1. Как у него щас с partial trees ?

Пока не поддерживаются, но работа в этом направлении ведется.

> 2. А если ему сэмулировать крэш через kill -9 , он потом поймет, что что-то не так в репозитории?

Если речь именно о репозитории - да. Там транзакция и с самого начала всё серьезно (в отличие от git 8)).

А вот kill -9 при merge или даже обновлении рабочей копии может ее запортить, наверное.

> 3. Ну и как у него будет с откатом до рабочего состояния после этого?

hg recover.

Ура. Я, правда, с 1.4.2 пока слезать не намерен. Работает - не трожь!

> Ненужен. Есть Mercurial, который куда удобнее для работы.

fixed

>>Ненужен. Есть Git, который куда удобнее для работы.

>Ухтыбля... ну-ка раскажи - как 30 девелоперов в одном офисе с пом. git'а будут взаимодействовать? Как говорили немцы: Edem das sein.(кажись так)

Прекрасно будут взаимодействовать, точно также как и более 50000 по всему миру. BTW у нас в конторе кроме UNIX отдела win отдел тоже использует и никаких проблемм.

windows way:
git-gui

или

unix way:
git status или gitk
git mv xx/x y/yy
git add ...
git commit ...

#а вот и взаимодействие
git pull
git push
#а вот удаление коммита
git revert ....

И в отличии от SVN у них не потеряются файлы при перемещении по дереву . И нету в git пресловутого ключика -f.

Re^2: subversion 1.5.0

> Ненужен. Есть Mercurial, который гораздо удобнее для работы.

засуньте куда нибудь уже свое питонство тормозное

>> Ненужен. Есть Mercurial, который гораздо удобнее для работы.

> засуньте куда нибудь уже свое питонство тормозное

Бгг. Не пробовал - не <censored>.

Re^4: subversion 1.5.0

> Бгг. Не пробовал - не <censored>.

http://www.opennet.ru/opennews/art.shtml?num=15803

Да, оно быстрее совсем уж непотребного Bazaar. Но до git еще легчать и легчать. Интерфейс практически весь с git слизан, особых различий в простоте работы не замечаю.

> http://www.opennet.ru/opennews/art.shtml?num=15803

Единственная значимая операция, на которой Mercurial проиграл - это diff. Используй inotify плагин и будет тебе щастье (он же и время коммита уменьшает).

> Но до git еще легчать и легчать.

Еще раз бгг. Вот когда git во _всех_ тестах будет быстрее, тогда, может быть, будет немного правды в твоих словах. А пока ты пополнил собой длинный список фанбоев.

> Интерфейс практически весь с git слизан

Историю учи - это git наконец-то добрался по юзабельности до Mercurial. Спустя 3 года.

P.S. в реальной жизни проектов величиной с ядро довольно мало, так что результаты интересные, но не более.

у mercurial интерфейс слизан с bitkeeper, а у git с mercurial :)

> у mercurial интерфейс слизан с bitkeeper

Не-а. У Mercurial "среднестатистический" интерфейс, выработанный совместно CVS и SVN :) Ну плюс push/pull, но эти команды не изобретение BK. А вот у git изначально был просто ужоснах под лозунгом "it's just a plumbing".

> СС лучшее что я видел из систем контроля версий. Для небольших проектов разумеется сильно избыточен, да.

1) Отсутсвие атомарных коммитов

2) Необходимость делать check-out перед check-in

10 лет назад такое было допустимо. 5 лет назад - уже нет. Сейчас - это просто маразм.

3) Неоправданно дорогой

4) Требует _ежедневного_ вмешательства администраторов.

5) может быть я не умею его готовить - но commit недельных изменений в hg/svn у меня занимает < 5 минут, то в clearcase > 1 часа.

6) может оно построено неправильно, но получение всех исходников из clearcase занимает 45 минут, из hg - 3 минуты.

может быть вы мало видели?

P.S. может недостаточно четко выразил свою мысль - наличие в vcs пуктов 1) или 2) достаточно чтобы в принципе не смотреть в сторону такой vcs.

кстати git уже научился работать в виндах (не только в cygwin и не только в cli режиме) и как там у него с интеграцией в trac ?

msysgit

>Если поставить cvs 1.5, он молча обновит working copy, и предыдущие >версии работать не смогут.

Может все-таки "если поставить svn 1.5" ?

1. Слышу не первый раз. Но суть что имеется ввиду не понимаю. Если не сложно растолкуйте?

2. На мой взгляд это наоборот достоинство. Чтобы положить в холодильник жирафа необходимо сперва открыть холодильник.

3. Полностью согласен. Но но не вижу как это относится к оценке качества продукта.

4. Только в случае действительно большого проекта когда происходит регулярный синк реплик.

5. Сложно оценивать. У меня таких проблем нет, хотя регулярно комичу недельные изменения, причем чужие. Возможно дело в процессе разработки.

6. Тут тоже не могу ничего сказать ибо даже в дурном сне мне не придет в голову получить ВСЕ исходники. И главное зачем?

Может и мало, кто ж спорит. Но из виденного ничего кроме перфорса не впечатлило. Перфорс же вызвал стойкое желание буээ. Потом пообвыкся.