A>Могу ошибаться, но в SVN — по-моему, никак.

Оказалось, что вот такая простая команда делает то, что мне нужно:

svn merge http://bla-bla-bbla/svn/project/trunk/src http://bla-bla-bbla/svn/project/branches/b1

Сравнил полученный транк с бранчем — никаких отличий найдено не было.

Нужно сделать merge бранча в транк так чтобы:
1. Если файл есть и в бранче и в транке, то вместо транковского нужно полставить файл из бранча. Не мержить. Просто заменить.
2. Если файл есть в бранче, но нет в транке, то скопировать такой файл в транк.
3. Если файл есть в транке, но его нет в бранче, то удалить файл из транка.

Можно ли такое сделать? Если да — как?

Здравствуйте, Аноним, Вы писали:

А>Можно ли такое сделать? Если да — как?

Могу ошибаться, но в SVN — по-моему, никак. Тут речь идет о слиянии (merge) директорий — причем директорий как отдельных элементов, у которых содержимое — это по сути перечень файлов и оддиректорий. В SVN директории хоть и являются версионными, но они лишь сохраняют snapshot тех файлов, которые есть на момент мёржа, без возможности эти снэпшоты как-то слить.
Хотя, в последних редакциях что-то и поменялось, поправьте кто-нибудь, если это не так.

Кстати, описанную операцию можно сделать в полной мере в IBM Rational ClearCase, но по условиям задачи оно, увы, не подходит

Здравствуйте, Aquary, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>Можно ли такое сделать? Если да — как?

A>Могу ошибаться, но в SVN — по-моему, никак. Тут речь идет о слиянии (merge) директорий — причем директорий как отдельных элементов, у которых содержимое — это по сути перечень файлов и оддиректорий. В SVN директории хоть и являются версионными, но они лишь сохраняют snapshot тех файлов, которые есть на момент мёржа, без возможности эти снэпшоты как-то слить.
A>Хотя, в последних редакциях что-то и поменялось, поправьте кто-нибудь, если это не так.
поправляю: это не так

все нормально мержится. последнее время работаю с subversion 1.6.x ... как там было до 1.6 в точности не помню, но проблем не испытывал...
для более тонкого резолва подобной ситуации в 1.6 заинтродюсили so called 'tree conflict' (читаем здесь)

в целом читать доки про `svn merge` в Subversion Book'e (правда он у них несколько отстает от текущей версии)

Здравствуйте, Аноним, Вы писали:

А>Нужно сделать merge бранча в транк так чтобы:
А>1. Если файл есть и в бранче и в транке, то вместо транковского нужно полставить файл из бранча. Не мержить. Просто заменить.
А>2. Если файл есть в бранче, но нет в транке, то скопировать такой файл в транк.
А>3. Если файл есть в транке, но его нет в бранче, то удалить файл из транка.

А>Можно ли такое сделать? Если да — как?

описанные тобой действия есть обычная задача для систем контроля версий (современных по кр мере)... subversion вполне себе адекватно поддерживает такой стиль разработки (читать про Copy-Modify-Merge). с версии 1.5 появился автоматический merge tracking -- работать в таком стиле стало заметно проще...

Здравствуйте, Аноним, Вы писали:

А>Нужно сделать merge бранча в транк так чтобы:
А>1. Если файл есть и в бранче и в транке, то вместо транковского нужно полставить файл из бранча. Не мержить. Просто заменить.
А>2. Если файл есть в бранче, но нет в транке, то скопировать такой файл в транк.
А>3. Если файл есть в транке, но его нет в бранче, то удалить файл из транка.

А>Можно ли такое сделать? Если да — как?

т.е. тебе по сути надо заменить транк бранчем?
Может тогда просто тупо удалить транк, а бранч назвать транком? Так пойдет?

Здравствуйте, Aquary, Вы писали:
A>Кстати, описанную операцию можно сделать в полной мере в IBM Rational ClearCase, но по условиям задачи оно, увы, не подходит
Интересно, а как это сделать в ClearCase? Просто check out директорию, merge в транк, и checkin?

Здравствуйте, zaufi, Вы писали:

Z>все нормально мержится. последнее время работаю с subversion 1.6.x ... как там было до 1.6 в точности не помню, но проблем не испытывал...

К сожалению не все так гладко. Нормально все смерджится только если не были удалены-перемещены-переименованы файлы в бранче или транке, иначе SVN предупредит о конфликте и мерджить данные файлы придется вручную.

Здравствуйте, Аноним, Вы писали:

А>Интересно, а как это сделать в ClearCase? Просто check out директорию, merge в транк, и checkin?

Совершенно верно — зачекаутить директорию, сделать мёрж (возможно, придется сделать селективный мерж, т.е. взять только определенную дельту) и зачекинить.

Здравствуйте, zaufi, Вы писали:

Z>описанные тобой действия есть обычная задача для систем контроля версий (современных по кр мере)... subversion вполне себе адекватно поддерживает такой стиль разработки (читать про Copy-Modify-Merge). с версии 1.5 появился автоматический merge tracking -- работать в таком стиле стало заметно проще...

Гражданина интересует не просто траджиционный мерж — этого добра как раз хватает в любой нормальной системе контроля версий.
Речь идет о хитром мерже именно директории, как отдельного элемента.

Кстати, мне подсказывают, что коммитить надо не весь воркспейс, а поименно выбранные файлы (в данном случае только директорию) и обязательно с "-N" (нерекурсивно).

On 25/01/2010 13:51, Аноним 27 wrote:

> Можно ли такое сделать? Если да — как?
Судя по описанию — никакая инфа из транка не берётся, тупо всё перезаписывается из бранча. В чём прикол? Почемсу это называется merge?

Здравствуйте, Ytz, Вы писали:

Ytz>Здравствуйте, zaufi, Вы писали:

Z>>все нормально мержится. последнее время работаю с subversion 1.6.x ... как там было до 1.6 в точности не помню, но проблем не испытывал...

Ytz>К сожалению не все так гладко. Нормально все смерджится только если не были удалены-перемещены-переименованы файлы в бранче или транке, иначе SVN предупредит о конфликте и мерджить данные файлы придется вручную.

если имеется ввиду например в бранче удалили файл который в транке изменился, то при попытке заsyncаться с транком вылезет tree conflict и тут надо понять нужны ли те изменения или удаленный в бранче файл таки нафиг не нужен даже со своими изменениями... -- т.е. порезолвить этот конфликт либо в пользу удаления файла либо в пользу сохранения с пришедшими изменениями... ну да сложный выбор... ручками придется поработать (грохнуть не нужное и сделать svn resolved)

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

Здравствуйте, Aquary, Вы писали:

A>Здравствуйте, zaufi, Вы писали:

Z>>описанные тобой действия есть обычная задача для систем контроля версий (современных по кр мере)... subversion вполне себе адекватно поддерживает такой стиль разработки (читать про Copy-Modify-Merge). с версии 1.5 появился автоматический merge tracking -- работать в таком стиле стало заметно проще...

A>Гражданина интересует не просто траджиционный мерж — этого добра как раз хватает в любой нормальной системе контроля версий.
A>Речь идет о хитром мерже именно директории, как отдельного элемента.

и чего в нем такого хитрого?? (ну кроме tree conflictов, которые добавились с версии 1.6, а раньше, ну да... хренова обрабатывались)

A>Кстати, мне подсказывают, что коммитить надо не весь воркспейс, а поименно выбранные файлы (в данном случае только директорию) и обязательно с "-N" (нерекурсивно).
это еще зачем? что значит не весь воркспейс? что такое "воркспейс"... я знаю "про рабочую копию" (work copy)

Здравствуйте, zaufi, Вы писали:

Z>и чего в нем такого хитрого?? (ну кроме tree conflictов, которые добавились с версии 1.6, а раньше, ну да... хренова обрабатывались)

В том и дело, что куча народу сидит на 1.5... ну а SVN, как обычно развивается весьма неспешно. Если "стрелки мёржа" появились в нём относительно недавно, то даж не верится, что появилось разрешение конфликтов с деревьями.

A>>Кстати, мне подсказывают, что коммитить надо не весь воркспейс, а поименно выбранные файлы (в данном случае только директорию) и обязательно с "-N" (нерекурсивно).
Z>это еще зачем? что значит не весь воркспейс? что такое "воркспейс"... я знаю "про рабочую копию" (work copy)

Сорри, work copy, конечно.

.>Судя по описанию — никакая инфа из транка не берётся, тупо всё перезаписывается из бранча. В чём прикол? Почемсу это называется merge?
Ну да — называть это merge не совсем честно.
Но делается это командой merge.

Здравствуйте, Аноним, Вы писали:

> 1. Если файл есть и в бранче и в транке, то вместо транковского нужно полставить файл из бранча. Не мержить. Просто заменить.

A> Оказалось, что вот такая простая команда делает то, что мне нужно:

svn merge http://bla-bla-bbla/svn/project/trunk/src http://bla-bla-bbla/svn/project/branches/b1

А> Ну да — называть это merge не совсем честно.
А> Но делается это командой merge.

-- Вот она, сила моего проклятия Зуамель-Густара!
-- Нет, я так думаю, что это все же не она...

В смысле, AFAIK командой merge делается все же не совсем это, и, скажем даже более того, совсем не это (то есть, не то, что было написано в первом посте)
Насколько я понимаю, merge это сделает только ЕСЛИ в транке и бранче за время существования бранча не вносилось изменений в одни и те же файлы.
То есть, если мержить фактически нечего.

bnk>В смысле, AFAIK командой merge делается все же не совсем это, и, скажем даже более того, совсем не это (то есть, не то, что было написано в первом посте)
bnk>Насколько я понимаю, merge это сделает только ЕСЛИ в транке и бранче за время существования бранча не вносилось изменений в одни и те же файлы.
bnk>То есть, если мержить фактически нечего.

Или я чего-то не понимаю... Но изменения вносились в одни и те же файлы.
И вроди бы сработало.

Здравствуйте, Аноним, Вы писали:

bnk>>В смысле, AFAIK командой merge делается все же не совсем это, и, скажем даже более того, совсем не это (то есть, не то, что было написано в первом посте)
bnk>>Насколько я понимаю, merge это сделает только ЕСЛИ в транке и бранче за время существования бранча не вносилось изменений в одни и те же файлы.
bnk>>То есть, если мержить фактически нечего.

А>Или я чего-то не понимаю... Но изменения вносились в одни и те же файлы.
А>И вроди бы сработало.

Cтранно это... Вроде как это и есть merge..?
прямой обязанностью которого является файлы мержить а не заменять..?

Здравствуйте, bnk, Вы писали:

А>>Или я чего-то не понимаю... Но изменения вносились в одни и те же файлы.
А>>И вроди бы сработало.

bnk>Cтранно это... Вроде как это и есть merge..?
bnk>прямой обязанностью которого является файлы мержить а не заменять..?

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

Век живи — век учись...

On 26/01/2010 03:51, Aquary wrote:

> В том и дело, что куча народу сидит на 1.5... ну а SVN, как обычно
> развивается весьма неспешно. Если "стрелки мёржа" появились в нём
> относительно недавно, то даж не верится, что появилось разрешение
> конфликтов с деревьями.
Мало того, нам как-то не удалось перейти на 1.5 из-за довольно критического бага, который я постил 1.5 года назад! И оно до сих пор не поификшено. Ну его нафиг, все валим на git!

Здравствуйте, ., Вы писали:

.> Ну его нафиг, все валим на git!

Ну тогда уж на Hg

Здравствуйте, ., Вы писали:

.>On 26/01/2010 03:51, Aquary wrote:

>> В том и дело, что куча народу сидит на 1.5... ну а SVN, как обычно
>> развивается весьма неспешно. Если "стрелки мёржа" появились в нём
>> относительно недавно, то даж не верится, что появилось разрешение
>> конфликтов с деревьями.
.>Мало того, нам как-то не удалось перейти на 1.5 из-за довольно критического бага, который я постил 1.5 года назад! И оно до сих пор не поификшено. Ну его нафиг, все валим на git!

ну да на другую vcs переходить проще чем преодолеть свою упертость и изменить layout своего репозитория так чтоб "баг" не аффектил работу...
(ага `svn swithch --relocate` сильно сложнее чем переезд на git/hg)

Здравствуйте, ., Вы писали:
.>Мало того, нам как-то не удалось перейти на 1.5 из-за довольно критического бага, который я постил 1.5 года назад! И оно до сих пор не поификшено.
Хм... Это проявлялось в том, что нельзя запретить запись в корень репозитория? Просто вроде я где-то видел такую (запрещено писать в корень, можно в дочерние папки) конфигурацию репозитория на 1.6.

On 27/01/2010 15:21, zaufi wrote:

> ну да на другую vcs переходить проще чем преодолеть свою упертость и
> изменить layout своего репозитория так чтоб "баг" не аффектил работу...
О переходе на гит я не жалел ни разу. Очень правильная vcs. Hg немного пробовал, лучше svn, но до git не дотягивает.
А layout изменить тяжко — единственный вариант разделять один репозиторий на несколько. Теряется атомарность коммитов.

On 27/01/2010 15:25, Mr.Cat wrote:

> Хм... Это проявлялось в том, что нельзя запретить запись в корень
> репозитория? Просто вроде я где-то видел такую (запрещено писать в
> корень, можно в дочерние папки) конфигурацию репозитория на 1.6.
Не запись, а чтение. Если корень репо читать нельзя, то некоторые операции не работают. В баге есть подробности.

Здравствуйте, ., Вы писали:
.>Если корень репо читать нельзя, то некоторые операции не работают.
Жуть какая. Не совсем представляю, зачем запрещать читать корень, но, конечно, нехорошо ломать то, что работало.

On 27/01/2010 21:34, Mr.Cat wrote:

> .>Если корень репо читать нельзя, то некоторые операции не работают.
> Жуть какая. Не совсем представляю, зачем запрещать читать корень, но,
> конечно, нехорошо ломать то, что работало.
Ну... В общем наверное просто параноя, но типа того, чтобы нельзя было посмотреть список чего есть в репо без соответствующих прав.