[svn] Как пользоваться этим ...?

Используй git svn, это просто

Policy блин. Прямо бесит это. Как можно пользоваться софтом у которого есть явные технологические изьяны влияющие на продуктивность при сущестующих альтернативах

> Что вообще побуждает не жечь напалмом любой след этой системы?

То, что есть люди, умеющие ей пользоваться (это не о тебе, конечно).

Ну-ну, что я сделал не так?

клонируем реп (это будет ДОЛГО!)
git svn clone -s http://example.com/my_subversion_repo local_dir
cd local_dir

делаем копию игноров
git svn show-ignore > .gitignore
git add .gitignore

создаем бранчик
git checkout -b git-trunk trunk

склеиваем коммиты
git rebase -i HEAD~3
(и читаем справку которая тут же выползет)

коммитать финальный ченджсет:
git svn dcommit

вот и вся премудрость

с точки зрения Policy всё выглядит так, как будто ты пользуешься svn :)

> Ну-ну, что я сделал не так?

Чтобы тебе ответить, мне нужно описание проблемы, а не твоя истерика по ее поводу.

Спасибо за совет, конечно можно попробовать. Но не хотелось бы что-то накосячить потом.

Была ветка. В ее забыли добавить файл. Не собирается. Я не заметил, создал другую ветку (тоже без этого файла). Когда заметили, сотрудник добавил файл в старую ветку. Merge в новую пишет Skipped missing target.

Проблема решается просто еще и коммитом файла в новую ветку. Костыль блин. Но почему не работает merge? Что если изменения были бы сложные и фалов было бы 100?

и да, коммит полезно делать вот так:

git checkout git-trunk <-- перешли на бранчик, трекающий svn
git svn rebase <-- получили обновления
git rebase feature <-- ребазнули в транк новые изменения
git svn rebase <-- сделали твои изменения самыми последними в истории
git svn dcommit <-- закоммитали тащем-то в svn

вот тебе «минус» гита - скока всего писать надо ;) и понимать, чем ребаз отличается от мерджа

> Но почему не работает merge?

use SVN GUI client, vertexua

Я вот не понимаю, что мешает сделать svn copy old-branch/myfile new-branch/myfile и не кричать про напалм?

Почему этого СПЕЦИАЛЬНО не хочет делать merge?

> Я не заметил, создал другую ветку (тоже без этого файла). Когда заметили, сотрудник добавил файл в старую ветку. Merge в новую пишет Skipped missing target.

Ты переименовал что-то?

Проблема решается просто еще и коммитом файла в новую ветку.

Бгг.

Ты переименовал что-то?

Ничего

Бгг.

Мне тоже кажется смешным способ решения проблем в svn

какой командой мерджил? конкретную строчку

TortoiseSVN

помойму если ты скажешь нечто вроде

svn merge http://svn.example.com/repos/calc/trunk@1910 \
          http://svn.example.com/repos/calc/branches/mybranch@1910

то новые файлы таки должны копироваться

По-моему тоже. Но вот чудо, нет. Он специально гад их не копирует. «Skipped missing target» означает «Я нашел что этого файла нет в этой ветке и я не буду его сюда копировать»

помойму, оно должно спрашивать «хочешь смерджить ревизии, деревья, или реинтегрировать?». Правильный ответ - мерджить деревья.

> Ну-ну, что я сделал не так?

Насрал в толксы вместо того чтобы идти читать документацию.

Ну почему же. Дело ведь не в одной конкретной проблеме, а постоянных костылях и криках «Саня, не комить, подожди!» на весь офис

> Мне тоже кажется смешным способ решения проблем в svn

Тогда почитай документацию и перестань смешить людей. Или хотя бы последуй совету насчет svn cp.

«Вам не нравится что программа не делает за вас, то что делают остальные програмы. Не нужно! Идите читайте документацию какие костыли нужно применить»

Вы хотите сказать, что централизованные системы часто мене гибки, чем распределенные? Таки да. Но именно поэтому часто люди выбирают именно первые.

ЗЫ Интересно, сколько тут бы было матюгов, если б ТС попробовал старый добрый CVS

> Вам не нравится что программа не делает за вас, то что делают остальные програмы.

Ты истеришь («жечь напалмом») по поводу детских проблем.

Идите читайте документацию какие костыли нужно применить

«Плохие, негодные костыли! Верните мне привычные!!!111»

Плохие, негодные костыли! Верните мне привычные!!!111

Вызвать операцию merge чтобы она произвела собственно merge без проблем - костыль?

ы хотите сказать, что централизованные системы часто мене гибки, чем распределенные?

Таки в этом треде есть люди, которые с этим несогласны. Привычка - серьезное дело. Хорошо что у меня она сформировалась к нормальным инструментам

> Ну почему же. Дело ведь не в одной конкретной проблеме, а постоянных костылях и криках «Саня, не комить, подожди!» на весь офис

Это говорит лишь о том, что не один вы не умеете пользоваться subversion'ом.

А как в svn делать локальные коммиты не до конца работающего кода? Все таки это часть работы, ее хотелось бы сохранить, возможно сделать локальную ветку, поисследовав что-то. Может вам хотелось бы воспользоваться фичами рефакторинга в Eclipse? Но нет, в svn нужно ставить плагин в Eclipse и для него, который кстати часто на сложных рефакторингах конфликтует с обычным svn и ломает все на свете. Ну да svn же не умеет определять без сторонеей помощи перемещенные файлы. О скорости вообще молчу.

И это на нашем проекте. Нужен проект еще больше. Смотри Торвальдса. Его проект называется Linux Kernel и там проблемы у них еще тяжелее были

>А как в svn делать локальные коммиты не до конца работающего кода?
shelve в любой IDE

Все таки это часть работы, ее хотелось бы сохранить, возможно сделать локальную ветку,

сделай реальную ветку, в чем проблема то?

Ну да svn же не умеет определять без сторонеей помощи перемещенные файлы.

и совершенно правильно. А что git автоматом запихивает target директорию например в коммит? 0_о

О скорости вообще молчу.

а что с скоростью? у меня нормально все работает

shelve в любой IDE

Это какие-то манипуляции с каталогами и ветками? Почему нельзя коммитить локально? ) Ах, да...

и совершенно правильно. А что git автоматом запихивает target директорию например в коммит? 0_о

А это причем? Эта папка вообще в игнорах. Git детектит копипасту и если источник исчез куда-то, то можно предположить что файл переместили и возможно изменили.

Если выбирать из двух зол (git, svn), то я бы выбрал svn за логичные команды.

угу, hg-svn+mq рулят

Вы что один и тот же участок кода правите ))))))))))))))))
Жистяк :)

Во всех остальных случаях можно комитить )

> А как в svn делать локальные коммиты не до конца работающего кода? Все таки это часть работы, ее хотелось бы сохранить, возможно сделать локальную ветку, поисследовав что-то.

Решил развести тут холивар на тему централизованные vs децентрализованные VCS, чтобы съехать с темы своего неосиляторства команды svn merge?

И это на нашем проекте. Нужен проект еще больше. Смотри Торвальдса. Его проект называется Linux Kernel и там проблемы у них еще тяжелее были

Не знаю что там за проблемы были у Торвальдса, меня его мнение по поводу VCS не волнует. Я работаю в проекте (10 тыс файлов) под svn, сравнимом по размерам с Linux (18 тыс файлов, 2.6.37). И что-то я не вижу никаких ужасов, связанных с svn. Причем у нас разрешается пользоваться git svn, но пользуются этим почему-то единицы.

Решил развести тут холивар на тему централизованные vs децентрализованные VCS, чтобы съехать с темы своего неосиляторства команды svn merge?

Ты тему почитай. Я холивар с первого предложения начал, а то что оно так говняно работает было просто примером. Когда делается merge, то должен блин проихсходить merge без проблем, хоть бы я в консоли, хоть графическим клиентом. Хотя холивар таки уныл, потому что все обычно знают о превосходстве децентрализированных VCS. Просто иногда есть legacy проекты.

> Просто иногда есть legacy проекты.
И legacy разработчики. Которые привыкли к CVS и дальше, чем svn их продвинуть будет сложно

Да. Впрочем иногда именно проекты, где нельзя поменять инфраструктуру. Свыше не заапрувят. У нас все в проекте за децентрализированные. Но нельзя.

> У нас все в проекте за децентрализированные. Но нельзя.

А мне пофиг. Я сам все равно гит (когда приходится) использую как испорченный CVS, мне его навороченные функции нафиг не сдались (я имею о них некое общее представление, но не более того).

Поэтому когда меня начальство спрашивает о том, куда уходить с CVS - я отвечаю как оно есть. Хотите сложностей и мощи - берите git. Хотите простоты перехода и ограничений - берите svn. Мне пофиг.

> когда меня начальство спрашивает о том, куда уходить с CVS - я отвечаю как оно есть. Хотите сложностей и мощи - берите git. Хотите простоты перехода и ограничений - берите svn.

Хорошо иметь простую картину мира.

Мне пофиг

...потому что я всё равно работаю в CVS

> Мне пофиг

...потому что я всё равно работаю в SVN

tailgunner fixed ;)

> Хорошо иметь простую картину мира.
Кто мешает?

...потому что я всё равно работаю в CVS

Именно. VCS системы делятся для меня на те, которые я могу использовать как CVS и те, которые не могу;) Например, SourceSafe я не справлялся использовать как CVS. Раздражало жутко.

> Делаю merge с той ветки. Надпись по этому файлу «Skipping missing target». Да я блин знаю что его там нет! Я хочу чтобы он там появился.

умвр.

Это прекрасно

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

Мне еще нравится скорость и локальные коммиты. Было так что я писал код на ноуте в поезде. И вообще даже для своих проектов небольших хорошо сделать git init и будет история искаропки. Потом по желанию если что-то стоящее, то пушишь это на какой нибудь сервер.

(*с трудом протискиваюсь в Триумфальную Арку*)
Бранчи - для трусов и бездельников! :)

>У нас все в проекте за децентрализированные.
У вас в проекте все просто не желают читать докумантацию.
Это диагноз.
И DVCS не поможет вам от этого излечиться.

Одна задача - один бранч!

> SourceSafe я не справлялся использовать как CVS. Раздражало жутко.
Hehe.
А я перевёл Canada Broadcasting Corporation на Subversion :)