LINUX.ORG.RU

Проверьте последовательность действий в Subversion

 ,


3

2

Всем привет!

Разбираюсь в subversion. Концептуально все понятно. Но некоторые детали еще в голове не утряслись; особенно беда с каталогами и с merge. Пожалуйста, проверьте последовательность действий внизу: все ли верно?

Ситуация: изначальный проект загружают на сервер subversion (192.168.0.1), а потом Вася и Петя дорабатывают две фичи. Вот как я это понял:

1. Допустим есть проект prj. Для него создаем дерево и помещаем в нужное место файлы:

$ mkdir -p ~/work/prj/trunk
$ mkdir -p ~/work/prj/branches
$ cp -r ~/original_project_location/* ~/work/prj/trunk

Заносим проект в репозиторий:

$ cd ~/work/prj/
$ svn import http://192.168.0.1/repos/prj

-1-

У нас создалась версия 1.

Теперь Вася и Петя хотят добавить по фиче.

2. Они создают ветки:

vasya$ svn copy http://192.168.0.1/repos/prj/trunk http://192.168.0.1/repos/prj/branches/feature_v -m "Feature of Vasya"
Committed revision 2

petya$ svn copy http://192.168.0.1/repos/prj/trunk http://192.168.0.1/repos/prj/branches/feature_p -m "Feature of Petya"
Committed revision 3

   r-2-
-1-|--
   L-3-
Далее они создают у cебя рабочие копии:
vasya$ svn checkout http://192.168.0.1/repos/prj/branches/feature_v ./
petya$ svn checkout http://192.168.0.1/repos/prj/branches/feature_p ./

3. Дорабатывают их и коммитят:

vasya$ svn commit
Committed revision 4

petya$ svn commit
Committed revision 5

   r-2-4-
-1-|-----
   L-3-5-

4. Теперь админ (третье лицо, не-Вася и не-Петя) хочет слить все воедино.

$ mkdir ~/tmp
$ cd ~/tmp
$ svn checkout http://192.168.0.1/repos/prj/trunk #### Update
$ svn merge http://192.168.0.1/repos/prj/branches/feature_v
$ svn commit
Committed revision 6

$ svn delete http://192.168.0.1/repos/prj/branches/feature_v -m "Feature development is completed"
   
-1-|-----6-
   L-3-5---

$ svn merge http://192.168.0.1/repos/prj/branches/feature_p
$ svn commit
Committed revision 7

$ svn delete http://192.168.0.1/repos/prj/branches/feature_p -m "Feature development is completed"

   
-1-|-----6-7-

Все правильно?

UPD: checkout перед merge

★★★★★

Кстати, интересно: что будет при объединении двух веток, если правились одни и те же файлы? Да еще и одни и те же места этих файлов, но по-разному?

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

Я так понял что будет конфликт и конкретно эти файлы не будут объеденены (остальные будут). Путь подтвердят/опровергнут другие, я пока нуб в этом деле, черпаю инфу вот отсюда: http://doc.dvgu.ru/devel/svn/svn.branchmerge.copychanges.html#svn.branchmerge...

Kroz ★★★★★ ()

Теперь админ хочет слить все воедино.

Админ? O_o

$ svn merge -r 1:4 http://svn.example.com/repos/calc/trunk

Насколько я помню SVN, здесь должно быть:

$ svn merge -r 1:4 http://svn.example.com/repos/calc/feature_v

т.е. изменения, сделанные в бранче feature_v сливаются в trunk (подразумевается, что рабочая копия сделана с trunk).

На самом деле, -r 1:4 в этом случае можно не указывать. Подозреваю, что на SVN старше 1.5 при merge вообще не обязательно указвать ревизии (если только ты не хочешь _пропустить_ некоторые ревизии бранча).

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)

В данном случае Петя и Вася должны были добавлять фичи в прямо в trunk, бранч больше подходит для серьезных эксперементов, еще не мешало бы делать tags периодически.

splinter ★★★★★ ()
Ответ на: комментарий от tailgunner

Админ? O_o

Не в названии суть. Третье лицо, не-Вася и не-Петя.

Насколько я помню SVN, здесь должно быть...

То есть так?

$ mkdir ~/tmp
$ cd ~/tmp
$ svn checkout http://192.168.0.1/repos/prj/trunk
$ svn merge http://192.168.0.1/repos/prj/branches/feature_v
$ svn commit
Committed revision 6

$ svn delete http://192.168.0.1/repos/prj/branches/feature_v -m "Feature development is completed"
   
-1-|-----6-
   L-3-5---

P. S. Сорри example.com и calc просочилось из примеров на другом сайте. Должно быть 192.168.0.1 и prj . Исправляюсь...

Kroz ★★★★★ ()
Ответ на: комментарий от splinter

В данном случае Петя и Вася должны были добавлять фичи в прямо в trunk, бранч больше подходит для серьезных эксперементов

1. А если Вася и Петя сделают изменения в одном файле и потом коммит сделают - как будет обработана коллизия? Что, у кого-то коммит не пройдет? Предполагается что Вася и Петя одновременно ведут разработку.
2. Давай пока по моему сценарию.

еще не мешало бы делать tags периодически.

Давай постепенно усложнять систему. Пока без tags.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

А если Вася и Петя сделают изменения в одном файле и потом коммит сделают - как будет обработана коллизия? Что, у кого-то коммит не пройдет?

Давай сразу на Mercurial.

tailgunner ★★★★★ ()
Ответ на: комментарий от Kroz

Напишет, второму, что надо апнутся. Он апнется, посмотрит и закомитит.

anonymous ()
Ответ на: комментарий от tailgunner

Я, например, mercurial'ом пользуюсь. Но что-то так и не проверил: что будет, если изменения внесены в один файл?

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Kroz

по твоему сценарию получается что тебе придется мерджить как можно чаще и если ты затянешь на какое то время то получишь кучу коллизий.

splinter ★★★★★ ()
Ответ на: комментарий от splinter

по твоему сценарию получается что тебе придется мерджить как можно чаще и если ты затянешь на какое то время то получишь кучу коллизий.

Ok. Хоть это и отклонения от основной темы, все равно интересно. Ты предлагаешь все делать в trunk? Хорошо, тогда 2 вопроса:
1. Вася и Петя сделали checkout версии 1 . Потом Вася сделал commit, теперь в транке версия 6. Теперь Петя хочет сделать коммит. Система правильно поймет, что для Пети нужно брать дельту от версии 6, а не от версии 1, которую Петя изначально checkout'ил?
2. Правильно я понимаю, что если будет коллизия, commit не пройдет, а точнее пройдет частично?

Все еще говорим о Subversion.

Kroz ★★★★★ ()
Ответ на: комментарий от splinter

Еще вопрос:
3. Я так понимаю, что при твоем сценарии нужно почаще делать update. Что будет при коллизии? Опять update пройдет частично? Вот тут как-то стремновато.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

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

Коммит не может пройти частично. В описанном случае он просто не пройдет.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

На самом деле, -r 1:4 в этом случае можно не указывать. Подозреваю, что на SVN старше 1.5 при merge вообще не обязательно указвать ревизии

Нашел пруф:

Релиз системы контроля версий Subversion 1.5
...
Возможность отслеживания изменений при слиянии — позволяет проследить когда и где были произведены объединения кода. Функция полезна для работы с «ответвлениями» основного проекта. К настоящему времени реализована только базовая функциональность, поэтому ожидается, что работать слияние будет достаточно медленно. Дальнейшие улучшения запланированы на версию 1.5.1 и выше.

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

Kroz ★★★★★ ()

ТС, у тебя полная каша в голове на счет свн

или не переучивайся из DCVS на CVS, или прочти свн бук.

готов помочь если будет хоть какое то понимание как работает не distributed cvs

ZuBB ★★★★★ ()
Ответ на: комментарий от ZuBB

готов помочь если будет хоть какое то понимание как работает не distributed cvs

Критерий понимания?
Если хочешь помочь - найди ошибки в моем первом посте или подтверди что там все правильно. Уверен, для тебя это дело трех минут.

Kroz ★★★★★ ()
Ответ на: комментарий от ZuBB

ТС, у тебя полная каша в голове на счет свн

Где каша-то? ТС просто нуб, о чем сам и сказал.

tailgunner ★★★★★ ()
Ответ на: комментарий от Kroz

там их достаточно много. все перечислять?

// чувстуется что прочитали некоторое количество манов про СКВ, но про distributed. зачем перескакиваете?

ZuBB ★★★★★ ()

все правильно, только вроде для возврата бранча в транк предполагается у merge опция --reintegrate.

чем она отличается от просто merge я, если честно, не осилил понять.

maloi ★★★★★ ()
Ответ на: комментарий от tailgunner

Теперь Вася и Петя хотят добавить по фиче. Они создают ветки:

vasya$ svn copy http://192.168.0.1/repos/prj/trunk

ничего не видишь? (и єто только 2я комманда из списка)

ZuBB ★★★★★ ()
Ответ на: комментарий от ZuBB

там их достаточно много. все перечислять?

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

// чувстуется что прочитали некоторое количество манов про СКВ, но про distributed. зачем перескакиваете?

Распределенные СКВ старательно игнорировал.

Note: Учитывая, что многие в этом топике ответили что все ок, есть возможность вот так сразу просветить достаточно большое количество людей ;)

Kroz ★★★★★ ()

Если нужны ветки и мерж, то лучше сразу mercurial (hg) или git. Для веток svn плохо подходит (как то Линус Торвальдс насмехался по этому поводу, рассказывая про свой git). Например, мы комиттим в транк, а потом перед самым релизом делаются ветки. Иногда приходится комитить и в транк, и в бранч. Была бы не svn, а какая другая система, думаю, тогда подход бы изменился.

dave ★★★★★ ()
Ответ на: комментарий от Kroz

сейчас нужно сходить по делах. вернусь за ~40мин, «перепишу» ваш пример

ZuBB ★★★★★ ()
Ответ на: комментарий от dave

Для веток svn плохо подходит (как то Линус Торвальдс насмехался по этому поводу, рассказывая про свой git)

Линус тролль дешевый. Merge tracking - это не rocket science, в SVN он давно есть, просто Линус им не пользовался.

tailgunner ★★★★★ ()
Ответ на: комментарий от dave

Если нужны ветки и мерж, то лучше сразу mercurial (hg) или git.

Выбор/сравнение СКВ - за рамками этой темы. Условие задачи - Subversion.
Второе условие задачи - сценарий вверху: завести новый проект, создать две новые ветки, объединить все в одно.

Kroz ★★★★★ ()

Бранчи в svn — это одна огромная жопа. Хотя нет, никакая это не жопа, потому что бранчей в svn просто нет. Держи отдельный чекаут транка для каждой фичи и периодически svn up'ай их. Синхронизировать feature-ветки с апстримом, а потом мержить их обратно = двойной геморрой.

Теперь админ (третье лицо, не-Вася и не-Петя) хочет слить все воедино.

Ни в коем случае не админ. Мейнтейнер, senior developer — словом тот, кто хорошо разбирается в коде проекта.

red_eyed_peguin ()
Ответ на: комментарий от Kroz

да, только последовательность другая. 1. Вася и Петя делают чекаут версии 1. 2. Вася комитит и (!) апдейтится. У него версия 6. 3. Петя тоже хочет закомитить дельту от версии 1, но не тут то было. Надо заапдейтится сначала. Вот во время апдейта у Пети будут конфликты или не будут. Если есть кофликты, Петя должен их исправить в своей рабочей копии и сделать «резольвед». Только тогда Петя сможет закомитить дельту от 6 версии к 7. Если конечно никто уже 7ую не закомитил, а то Пете придётся опять делать апдейт. 3. Комит не может пройти «частично». Пока у тебя есть конфликты в дереве или в файлах ничего не получится.

nanoolinux ★★★★ ()
Ответ на: комментарий от nanoolinux

Комит не может пройти «частично». Пока у тебя есть конфликты в дереве или в файлах ничего не получится.

Ok.

да, только последовательность другая

Выглядит логично. Но возникает вопрос: где тут merge? Мне так кажется, что в случае коллизий merge будет вести себя так же, как и update. А еще нужно перенести все в ветку trunk - это, как я понял, и делает merge. Из этого следует, что merge полностью заменяет update. Вобщем опять неясно.

Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

Из этого следует, что merge полностью заменяет update.

В общем, да.

Вобщем опять неясно.

Есть две крайних модели работы с централизованными VCS: CVS-подобная и DVCS-подобная. В CVS-подобной все толпятся на транке, никакого merge нет - вместо него update. В DVCS-подобной (твой пример) каждому разработчику выделяется свой бранч, и периодически делается merge в транк.

tailgunner ★★★★★ ()
Ответ на: комментарий от Kroz

стоп стоп стоп. это я писал для случая если Вася и Петя в т(р)анке работают.

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

nanoolinux ★★★★ ()
Ответ на: комментарий от tailgunner

там очень мало лишнего, а сложньіх вещей пару штук.

весь его пример сделан. пусть парсит.

да согласен, вьіглядит ужасающе

ZuBB ★★★★★ ()
Последнее исправление: ZuBB (всего исправлений: 1)
Ответ на: комментарий от ZuBB

там очень мало лишнего

Ошибки мог бы и почистить.

да согласен, вьіглядит ужасающе

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

tailgunner ★★★★★ ()

ТС, если ты твердо решил юзать свн, я тебе очень настоятельно рекоммендую прочитать свн бук. Она написана ну очень просто. Если таки не можешь осилить инглиш, то есть перевод на русский. Когда я ее читал там было около 120 страниц

Я, когда только начинал прогать, сделал тоже самое. Могу тебя заверить что это была очень хорошая инвестиция.

ZuBB ★★★★★ ()
Последнее исправление: ZuBB (всего исправлений: 1)
Ответ на: комментарий от Kroz

Я так понимаю, что при твоем сценарии нужно почаще делать update. Что будет при коллизии? Опять update пройдет частично?

Правильно понимаешь, Петя будет сам разрешать коллизии возникающие при update.

splinter ★★★★★ ()
Ответ на: комментарий от ZuBB

Посмотрел я ваш лог. Сразу вопросы:
1. Для создания ветки вы выгружаете весь проект (вместе с branches и trunk). Зачем? Почему не использовать svn copy. Во-первых для проектов большого масштаба это неразумно - загружать кучу файлов да еще и их копий. Во-вторых, как я понял svn copy создает не совсем копию, а только отображает файл в нескольких каталогах, а если файл менялся - сохраняет только изменения.
2. Опять-таки для Васи и Пети вы делает checkout всего проекта. Почему не сделать checkout только того каталога, который нужен. Опять-таки здесь - не принципиально, но в реальных проектах, думаю, это важно.

Если в этом есть какая-то логика - хотел бы ее услышать.

Что-то мне говорит что вы привыкли работать с распределенными СКВ, там, скорее всего так нужно. А здесь...

А здесь мой вариант сработал на 100%. В моем первом сообщении были некоторые неточности (например, нумерация версий), но в целом все правильно. Записал полный лог, сейчас добавлю комментарии и запощу сюда - будущим поколениям.

В любом случае, спасибо за помощь и за книгу. А еще за команду tree - не знал ее.

Kroz ★★★★★ ()
Ответ на: комментарий от tailgunner

Есть две крайних модели работы с централизованными VCS: CVS-подобная и DVCS-подобная. В CVS-подобной все толпятся на транке, никакого merge нет - вместо него update. В DVCS-подобной (твой пример) каждому разработчику выделяется свой бранч, и периодически делается merge в транк.

А вот это золотые слова! Очень упорядочивает понимание того, почему разные люди говорят разные вещи.

Kroz ★★★★★ ()

Рабочий вариант часть 1

Вот лог реализации поставленной задачи. Большой, зато полный, с различными проверками, отображением текущего состояния в каталогах и в репозитории. Комментарии отделяют одну фазу от другой, в остальном все должно быть ясно и так. На имена каталогов/пользователей/файлов не смотрите - взяты только для примера.

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

###########
### Создание исходных условий: три пользователея, репозиторий, исходная локация проекта.
user@host:~> mkdir -p ~/tmp/svn_test/{admin,vasya,petya,repos,original_project_location}
user@host:~> cd ~/tmp/svn_test/original_project_location/
user@host:~/tmp/svn_test/original_project_location> echo -e "Original line 1\nOriginal line 2\nOriginal line 3" > content.txt
user@host:~/tmp/svn_test/original_project_location> cat content.txt 
Original line 1
Original line 2
Original line 3

###########
### Загрузка исходного проекта в репозиторий. В репозитории будут 2 каталога: trunk - основаная версия проекта, branches - ответвления, в которых создаются отдельные фичи, которые потом портируются в основную версию
user@host:~/tmp/svn_test/original_project_location> cd ../repos/
user@host:~/tmp/svn_test/repos> svnadmin create project
user@host:~/tmp/svn_test/repos> tree
.
└── project
    ├── conf
    │   ├── authz
    │   ├── passwd
    │   └── svnserve.conf
    ├── db
    │   ├── current
    │   ├── format
    │   ├── fsfs.conf
    │   ├── fs-type
    │   ├── min-unpacked-rev
    │   ├── revprops
    │   │   └── 0
    │   │       └── 0
    │   ├── revs
    │   │   └── 0
    │   │       └── 0
    │   ├── transactions
    │   ├── txn-current
    │   ├── txn-current-lock
    │   ├── txn-protorevs
    │   ├── uuid
    │   └── write-lock
    ├── format
    ├── hooks
    │   ├── post-commit.tmpl
    │   ├── post-lock.tmpl
    │   ├── post-revprop-change.tmpl
    │   ├── post-unlock.tmpl
    │   ├── pre-commit.tmpl
    │   ├── pre-lock.tmpl
    │   ├── pre-revprop-change.tmpl
    │   ├── pre-unlock.tmpl
    │   └── start-commit.tmpl
    ├── locks
    │   ├── db.lock
    │   └── db-logs.lock
    └── README.txt

11 directories, 27 files
user@host:~/tmp/svn_test/repos> cd ../admin/
user@host:~/tmp/svn_test/admin> mkdir -p project/{trunk,branches}
user@host:~/tmp/svn_test/admin> cp ../original_project_location/* project/trunk/
user@host:~/tmp/svn_test/admin> tree
.
└── project
    ├── branches
    └── trunk
        └── content.txt

3 directories, 1 file
user@host:~/tmp/svn_test/admin> svn import project file:///home/user/tmp/svn_test/repos/project/ -m "Initial project"
Adding         project/trunk
Adding         project/trunk/content.txt
Adding         project/branches

Committed revision 1.
user@host:~/tmp/svn_test/admin> tree ../repos/
../repos/
└── project
    ├── conf
    │   ├── authz
    │   ├── passwd
    │   └── svnserve.conf
    ├── db
    │   ├── current
    │   ├── format
    │   ├── fsfs.conf
    │   ├── fs-type
    │   ├── min-unpacked-rev
    │   ├── rep-cache.db
    │   ├── revprops
    │   │   └── 0
    │   │       ├── 0
    │   │       └── 1
    │   ├── revs
    │   │   └── 0
    │   │       ├── 0
    │   │       └── 1
    │   ├── transactions
    │   ├── txn-current
    │   ├── txn-current-lock
    │   ├── txn-protorevs
    │   ├── uuid
    │   └── write-lock
    ├── format
    ├── hooks
    │   ├── post-commit.tmpl
    │   ├── post-lock.tmpl
    │   ├── post-revprop-change.tmpl
    │   ├── post-unlock.tmpl
    │   ├── pre-commit.tmpl
    │   ├── pre-lock.tmpl
    │   ├── pre-revprop-change.tmpl
    │   ├── pre-unlock.tmpl
    │   └── start-commit.tmpl
    ├── locks
    │   ├── db.lock
    │   └── db-logs.lock
    └── README.txt

11 directories, 30 files
user@host:~/tmp/svn_test/admin> rm -r project/
Kroz ★★★★★ ()

Рабочий вариант часть 2

###########
### Пользователь Vasya пишет новую фичу: меняет существующие файлы и добавляет новые
user@host:~/tmp/svn_test/admin> cd ../vasya/
user@host:~/tmp/svn_test/vasya> svn log -v file:///home/user/tmp/svn_test/repos/project/
------------------------------------------------------------------------
r1 | user | 2012-08-10 20:25:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches
   A /trunk
   A /trunk/content.txt

Initial project
------------------------------------------------------------------------
user@host:~/tmp/svn_test/vasya> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
trunk/
trunk/content.txt
user@host:~/tmp/svn_test/vasya> tree
.

0 directories, 0 files
user@host:~/tmp/svn_test/vasya> svn copy file:///home/user/tmp/svn_test/repos/project/trunk file:///home/user/tmp/svn_test/repos/project/branches/feature_v -m "Feature of Vasya"

Committed revision 2.
user@host:~/tmp/svn_test/vasya> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_v/
branches/feature_v/content.txt
trunk/
trunk/content.txt
user@host:~/tmp/svn_test/vasya> svn checkout file:///home/user/tmp/svn_test/repos/project/branches/feature_v
A    feature_v/content.txt
Checked out revision 2.
user@host:~/tmp/svn_test/vasya> tree
.
└── feature_v
    └── content.txt

1 directory, 1 file
user@host:~/tmp/svn_test/vasya> vi feature_v/content.txt 
user@host:~/tmp/svn_test/vasya> cat feature_v/content.txt
New code of Vasya
Original line 1
Original line 2
Original line 3
user@host:~/tmp/svn_test/vasya> echo "New content of Vasya" > feature_v/content_v.txt
user@host:~/tmp/svn_test/vasya> svn info feature_v/
Path: feature_v
Working Copy Root Path: /home/user/tmp/svn_test/vasya/feature_v
URL: file:///home/user/tmp/svn_test/repos/project/branches/feature_v
Repository Root: file:///home/user/tmp/svn_test/repos/project
Repository UUID: 0e473185-1f23-4413-b9d7-e36e934340c0
Revision: 2
Node Kind: directory
Schedule: normal
Last Changed Author: user
Last Changed Rev: 2
Last Changed Date: 2012-08-10 21:10:20 +0300 (Птн, 10 Авг 2012)
user@host:~/tmp/svn_test/vasya> svn status feature_v/
?       feature_v/content_v.txt
M       feature_v/content.txt
user@host:~/tmp/svn_test/vasya> svn add feature_v/content_v.txt 
A         feature_v/content_v.txt
user@host:~/tmp/svn_test/vasya> svn status feature_v/
M       feature_v/content.txt
A       feature_v/content_v.txt
user@host:~/tmp/svn_test/vasya> svn log -v file:///home/user/tmp/svn_test/repos/project/
------------------------------------------------------------------------
r2 | user | 2012-08-10 21:10:20 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_v (from /trunk:1)

Feature of Vasya
------------------------------------------------------------------------
r1 | user | 2012-08-10 20:25:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches
   A /trunk
   A /trunk/content.txt

Initial project
------------------------------------------------------------------------
user@host:~/tmp/svn_test/vasya> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_v/
branches/feature_v/content.txt
trunk/
trunk/content.txt
user@host:~/tmp/svn_test/vasya> svn commit feature_v/ -m "Feature development completed"
Sending        feature_v/content.txt
Adding         feature_v/content_v.txt
Transmitting file data ..
Committed revision 3.
user@host:~/tmp/svn_test/vasya> svn log -v file:///home/user/tmp/svn_test/repos/project/
------------------------------------------------------------------------
r3 | user | 2012-08-10 21:19:53 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /branches/feature_v/content.txt
   A /branches/feature_v/content_v.txt

Feature development completed
------------------------------------------------------------------------
r2 | user | 2012-08-10 21:10:20 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_v (from /trunk:1)

Feature of Vasya
------------------------------------------------------------------------
r1 | user | 2012-08-10 20:25:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches
   A /trunk
   A /trunk/content.txt

Initial project
------------------------------------------------------------------------
user@host:~/tmp/svn_test/vasya> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_v/
branches/feature_v/content.txt
branches/feature_v/content_v.txt
trunk/
trunk/content.txt

###########
### Пользователь Petya пишет новую фичу: меняет существующие файлы
user@host:~/tmp/svn_test/vasya> cd ../petya/
user@host:~/tmp/svn_test/petya> svn copy file:///home/user/tmp/svn_test/repos/project/trunk file:///home/user/tmp/svn_test/repos/project/branches/feature_p -m "Feature of Petya"

Committed revision 4.
user@host:~/tmp/svn_test/petya> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_p/
branches/feature_p/content.txt
branches/feature_v/
branches/feature_v/content.txt
branches/feature_v/content_v.txt
trunk/
trunk/content.txt
user@host:~/tmp/svn_test/petya> svn checkout file:///home/user/tmp/svn_test/repos/project/branches/feature_p
A    feature_p/content.txt
Checked out revision 4.
user@host:~/tmp/svn_test/petya> tree
.
└── feature_p
    └── content.txt

1 directory, 1 file
user@host:~/tmp/svn_test/petya> vi feature_p/content.txt 
user@host:~/tmp/svn_test/petya> cat feature_p/content.txt
Original line 1
Original line 2
Original line 3
New code of Petya
user@host:~/tmp/svn_test/petya> svn commit feature_p/ -m "Feature development completed"
Sending        feature_p/content.txt
Transmitting file data .
Committed revision 5.
user@host:~/tmp/svn_test/petya> svn log -v file:///home/user/tmp/svn_test/repos/project/
------------------------------------------------------------------------
r5 | user | 2012-08-10 21:24:33 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /branches/feature_p/content.txt

Feature development completed
------------------------------------------------------------------------
r4 | user | 2012-08-10 21:22:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_p (from /trunk:3)

Feature of Petya
------------------------------------------------------------------------
r3 | user | 2012-08-10 21:19:53 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /branches/feature_v/content.txt
   A /branches/feature_v/content_v.txt

Feature development completed
------------------------------------------------------------------------
r2 | user | 2012-08-10 21:10:20 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_v (from /trunk:1)

Feature of Vasya
------------------------------------------------------------------------
r1 | user | 2012-08-10 20:25:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches
   A /trunk
   A /trunk/content.txt

Initial project
------------------------------------------------------------------------
user@host:~/tmp/svn_test/petya> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_p/
branches/feature_p/content.txt
branches/feature_v/
branches/feature_v/content.txt
branches/feature_v/content_v.txt
trunk/
trunk/content.txt
Kroz ★★★★★ ()

Рабочий вариант часть 3

###########
### admin (Мейнтейнер) портирует фичи Васи и Пети в основную ветку.
user@host:~/tmp/svn_test/petya> cd ../admin/
user@host:~/tmp/svn_test/admin> tree
.

0 directories, 0 files
user@host:~/tmp/svn_test/admin> svn checkout file:///home/user/tmp/svn_test/repos/project/trunk
A    trunk/content.txt
Checked out revision 5.
user@host:~/tmp/svn_test/admin> tree
.
└── trunk
    └── content.txt

1 directory, 1 file
user@host:~/tmp/svn_test/admin> svn status trunk/
user@host:~/tmp/svn_test/admin> svn merge file:///home/user/tmp/svn_test/repos/project/branches/feature_v trunk/
--- Merging r2 through r5 into 'trunk':
U    trunk/content.txt
A    trunk/content_v.txt
--- Recording mergeinfo for merge of r2 through r5 into 'trunk':
 U   trunk
user@host:~/tmp/svn_test/admin> svn status trunk/
 M      trunk
M       trunk/content.txt
A  +    trunk/content_v.txt
user@host:~/tmp/svn_test/admin> tree
.
└── trunk
    ├── content.txt
    └── content_v.txt

1 directory, 2 files
user@host:~/tmp/svn_test/admin> cat trunk/content.txt 
New code of Vasya
Original line 1
Original line 2
Original line 3
user@host:~/tmp/svn_test/admin> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_p/
branches/feature_p/content.txt
branches/feature_v/
branches/feature_v/content.txt
branches/feature_v/content_v.txt
trunk/
trunk/content.txt
user@host:~/tmp/svn_test/admin> svn commit trunk/ -m "Merged with feature of Vasya"
Sending        trunk
Sending        trunk/content.txt
Adding         trunk/content_v.txt
Transmitting file data .
Committed revision 6.
user@host:~/tmp/svn_test/admin> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_p/
branches/feature_p/content.txt
branches/feature_v/
branches/feature_v/content.txt
branches/feature_v/content_v.txt
trunk/
trunk/content.txt
trunk/content_v.txt
user@host:~/tmp/svn_test/admin> svn merge file:///home/user/tmp/svn_test/repos/project/branches/feature_p trunk/
--- Merging r4 through r6 into 'trunk':
U    trunk/content.txt
--- Recording mergeinfo for merge of r4 through r6 into 'trunk':
 U   trunk
user@host:~/tmp/svn_test/admin> cat trunk/content.txt 
New code of Vasya
Original line 1
Original line 2
Original line 3
New code of Petya
user@host:~/tmp/svn_test/admin> svn commit trunk/ -m "Merged with feature of Petya"
Sending        trunk
Sending        trunk/content.txt
Transmitting file data .
Committed revision 7.
user@host:~/tmp/svn_test/admin> svn log -v file:///home/user/tmp/svn_test/repos/project/
------------------------------------------------------------------------
r7 | user | 2012-08-10 21:33:53 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /trunk
   M /trunk/content.txt

Merged with feature of Petya
------------------------------------------------------------------------
r6 | user | 2012-08-10 21:31:49 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /trunk
   M /trunk/content.txt
   A /trunk/content_v.txt (from /branches/feature_v/content_v.txt:5)

Merged with feature of Vasya
------------------------------------------------------------------------
r5 | user | 2012-08-10 21:24:33 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /branches/feature_p/content.txt

Feature development completed
------------------------------------------------------------------------
r4 | user | 2012-08-10 21:22:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_p (from /trunk:3)

Feature of Petya
------------------------------------------------------------------------
r3 | user | 2012-08-10 21:19:53 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /branches/feature_v/content.txt
   A /branches/feature_v/content_v.txt

Feature development completed
------------------------------------------------------------------------
r2 | user | 2012-08-10 21:10:20 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_v (from /trunk:1)

Feature of Vasya
------------------------------------------------------------------------
r1 | user | 2012-08-10 20:25:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches
   A /trunk
   A /trunk/content.txt

Initial project
------------------------------------------------------------------------
user@host:~/tmp/svn_test/admin> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
branches/feature_p/
branches/feature_p/content.txt
branches/feature_v/
branches/feature_v/content.txt
branches/feature_v/content_v.txt
trunk/
trunk/content.txt
trunk/content_v.txt
user@host:~/tmp/svn_test/admin> svn delete file:///home/user/tmp/svn_test/repos/project/branches/feature_v -m "Feature of Vasya has been merged; deleting old sources"

Committed revision 8.
user@host:~/tmp/svn_test/admin> svn delete file:///home/user/tmp/svn_test/repos/project/branches/feature_p -m "Feature of Petya has been merged; deleting old sources"

Committed revision 9.
user@host:~/tmp/svn_test/admin> svn list -R file:///home/user/tmp/svn_test/repos/project/
branches/
trunk/
trunk/content.txt
trunk/content_v.txt
user@host:~/tmp/svn_test/admin> svn log -v file:///home/user/tmp/svn_test/repos/project/
------------------------------------------------------------------------
r9 | user | 2012-08-10 21:37:23 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   D /branches/feature_p

Feature of Petya has been merged; deleting old sources
------------------------------------------------------------------------
r8 | user | 2012-08-10 21:36:58 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   D /branches/feature_v

Feature of Vasya has been merged; deleting old sources
------------------------------------------------------------------------
r7 | user | 2012-08-10 21:33:53 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /trunk
   M /trunk/content.txt

Merged with feature of Petya
------------------------------------------------------------------------
r6 | user | 2012-08-10 21:31:49 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /trunk
   M /trunk/content.txt
   A /trunk/content_v.txt (from /branches/feature_v/content_v.txt:5)

Merged with feature of Vasya
------------------------------------------------------------------------
r5 | user | 2012-08-10 21:24:33 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /branches/feature_p/content.txt

Feature development completed
------------------------------------------------------------------------
r4 | user | 2012-08-10 21:22:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_p (from /trunk:3)

Feature of Petya
------------------------------------------------------------------------
r3 | user | 2012-08-10 21:19:53 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   M /branches/feature_v/content.txt
   A /branches/feature_v/content_v.txt

Feature development completed
------------------------------------------------------------------------
r2 | user | 2012-08-10 21:10:20 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches/feature_v (from /trunk:1)

Feature of Vasya
------------------------------------------------------------------------
r1 | user | 2012-08-10 20:25:09 +0300 (Птн, 10 Авг 2012) | 1 line
Changed paths:
   A /branches
   A /trunk
   A /trunk/content.txt

Initial project
------------------------------------------------------------------------
Kroz ★★★★★ ()
Ответ на: комментарий от Kroz

Для создания ветки вы выгружаете весь проект (вместе с branches и trunk). Зачем?

можна выгружать (выгружать == «checkout») любую часть. всю, или тот кусок, с которым будете работать.

Почему не использовать svn copy

Он не для того предназначен (как там на cчет почитать мануал?). Если мне нужно иметь копию файла/директории XYZ в другом месте репозитория/копии репозитория, то тогда делается svn copy.

Что-то мне говорит что вы привыкли работать с распределенными СКВ

Да, за 1,5 года пришлось перестроится. Хотя мне очень нравится следующая фраза (о гите)

бистрий сука, фічастий блять, але вїжджаїш довго

ZuBB ★★★★★ ()
Последнее исправление: ZuBB (всего исправлений: 1)
Ответ на: комментарий от ZuBB

Если мне нужно иметь копию файла/директории XYZ в другом месте репозитория/копии репозитория, то тогда делается svn copy.

Так это ж и нужно!

Хотя мне очень нравится следующая фраза (о гите): бистрий сука, фічастий блять, але вїжджаїш довго

Много видел подобных фраз, но нормального обоснования - не видел. Распределенность нужна далеко не во всех случаях. Может нужно просто поработать с этим чтобы понять? В таком случае не нужно это советовать новичкам.

Общался с товарищем, работает в немаленькой программерской фирме. Спросил что они используют, ответил что svn . Спрашиваю почему не git . Ответ:
1. Если мы передйем на git мы потеряем всю историю, которая сейчас в svn.
2. Проект большой, есть большие бинарные файлы. Если использовать git, на компе у каждого должен быть весь проект с историей, что займет много места. Зачем это нужно? Так каждый выгружает только то, что ему нужно, и только последнюю версию, остальное на сервере.

Kroz ★★★★★ ()
Ответ на: комментарий от ZuBB

как там на cчет почитать мануал?

Положительно. Читаю по Subversion 1.7 . Вот что вычитал:

1. Создавать ветки нужно именно copy , так как если копирова вручную потом могут быть проблемы во время объединения. При copy subversion запоминает родителя файла и при объединении он будет именно объединять, тогда как если копировать в ручную он скажет что в trunk есть совершенно новый файл просто с таким же именем. (Creating a Branch, p98, Dealing with Structural Conflicts, p. 41)
2. merge в чистом виде используется в основном для синхронизации транка (основной ветки разработка) и ветки, над которой сейчас идет работа. Вообще, это считается хорошей практикой периодически делать такие синхронизации (Keeping a Branch in Sync, p 106.).
3. Перед merge нужно делать update ветки, так как после commit у вас может быть многоверсионный (mixed-verision) рабочий каталог, а subversion 1.7 (Keeping a Branch in Sync, p 106.)

Kroz ★★★★★ ()
Ответ на: комментарий от ZuBB

4. Когда работа над веткой заверешена нужно влить ee в транк (именно ветку в транк, а не наоборот) с опцией --reintegrate. Разница, как я ее понял. Допустим мы вливаем транк (из которого была образована ветка) в ветку (во время синхронизации ветки). Без этой опции, subversion берет diff между текущей (HEAD) версией транка и предыдущей (во время предыдущего merge или copy), и эту разницу вливает в ветку (точнее, в рабочий каталог). С опцией, subversion бы взял diff между текущей версией транка и текущей версии ветки (в которую вливаем) и влил бы это в ветку (рабочий каталог). Как сказано, область применения --reintegrate - именно вливание ветки.

Рекомендуемый порядок вливания ветки в транк таков:
# В ветке ^/calc/branches/my-branch
$ svn update
$ svn merge ^/calc/trunk
# Тестирование
$ svn commit

# В транке ^/calc/trunk
$ svn update # или checkout
$ svn merge --reintegrate ^/calc/branches/my-branch
# Тестирование
$ svn commit

(Reintegrating a Branch, p.108)

5. После вливания ветки рекомендуется ее удалить, чтобы не мешала. Все равно она останется в истории, но просто не будет выгружаться при checkout .

Kroz ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.