Зачем делать svn update перед svn commit?

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

давай разверну ответ...

есть репозитарий R и два пользователя U1 и U2. На R лежит файл F. U1 и U2 сделали svn co и принялись дружно редактировать F. U2 сделал коммит своей версии F2. U1 должет сделать svn update, чтобы его версия файла F1 была на основе той версии, что лежит в R. Это а-ля чекпоинт для отправки diff'а c изменениями F1. Еже ли этого не делать, то при попытке закоммитить F1 сервер заругается на конфликт. Оно и правильно. Твой diff не учитывает изменения, которые уже сделал U2.

Это довод за или против?

То есть, если есть конфликт, то svn все равно ругнется? Значит каждый раз update перед commit'ом делать не надо?

Или наоборот надо каждый раз делать update перед commit'ом в качестве превентивного удара по возможным конфликтам?

надо делать update, потом собирать и пускать тесты

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

А в это время кто-то еще успел закоммитить и нужно опять «делать update, потом собирать и пускать тесты» :)

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

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

> А в это время кто-то еще успел закоммитить и нужно опять «делать update, потом собирать и пускать тесты» :)

Да, вы правы

> svn не даст закоммитить изменения, если в репозитарии хранится уже измененная версия. Так что сломать не получится.

Очень даже получится. Скажем, кто-то изменил *.h-файл, который ты не трогал, но используешь. Ты делаешь svn commit, и билд ломается.

P.S. SVN - устаревшее говно.

svn - единственный работающий инструмент на сегодня. Все ваши джиты, базаары и меркуриалы - поделки студентоты на коленке, коя (студентота) настоящих проектов и не писала и даже и о потребностях разработчиков не знает.

К первому апреля еще далеко ;)

билд сломается, а не репозитарий :) уточнять нужно.

> svn - единственный работающий инструмент на сегодня. Все ваши джиты, базаары и меркуриалы - поделки студентоты на коленке

Ты такой жирный, что даже странно, как ты сюда пролез. :-))

хоть кто-то в этом треде в разработке понимает :)

> P.S. SVN - устаревшее говно.

А в mercurial нет partial clone (клонирования части репозитория). И subrepos пока тоже какое-то неюзабельное «говно».

Ага, ага! А возглавляет эти студенческие поделки ClearCase! :)

>Я делаю svn update перед svn commit всегда (на автомате). Но меня спросили: «Зачем?»

Потому что если файлы, которые ты коммитишь, уже были кем-то изменены на сервере, svn скажет «commit failed», и тебе придется делать svn up.

++;

>svn - единственный работающий инструмент на сегодня

Вы таки говорите, что у CVS уже есть конкурент? Надо подумать о переходе.

Маловероятно. Если кто-то изменил *.h файл, то он проверил проект на компилируемость, а значит и затронул и твой файл, чтобы всё продолжало собираться.

U1: Меняем A.h и A.c. Всё компилируется - коммит U2: Изменяем файл B.h, который зависит от А.h, svn up не делаем, компилируем, коммит

В итоге в репозитории сломанная сборка

Сделал ты svn up, запустил тесты, через 20 минут тесты завершились - все в порядке, сделал commit. Да вот только пока ты тесты выполнял кто-то закоммитил индусо-код. И update от сломанного билда не спас.

svn - единственный работающий инструмент на сегодня. Все ваши джиты, базаары и меркуриалы - поделки студентоты на коленке, коя (студентота) настоящих проектов и не писала и даже и о потребностях разработчиков не знает.

А как же ms tfs?

правильно делаешь. исключение - когда апдейт занимает непозволительно много времени.