tracking third party code (vendor branches)

[Victor Sudakov]

Коллеги,

То что описано про сабж в SVN
http://svnbook.red-bean.com/en/1.0/ch07s04.html
производит ужасное впечатление. Разархивировать исходники новой версии
стороннего софта поверх рабочей копии vendor branch и потом коммитить
получившееся? Читая "svn status", а потом вручную делая "svn add" и
"svn rm" на новые или не нужные файлы? И даже если не вручную, а
посредством костыля svn_load_dirs.pl, всё равно ужасно. Даже в CVS
было сделано приличнее. Часто встречаю упоминания, что многие
описанный способ не используют, а предпочитают тупо импортировать
каждую новую версию сторонних исходников в отдельную ветку. Дисковое
пространство конечно расходуется расточительно, но оно сейчас дешевое.

Собственно вопрос. А в других VCS, например git, сделано красивее? И
как именно? (имеется в виду конечно случай, когда сторонний софт сам
не в виде репозитория доступен, а например tarball-ом).

[Valentin Nechayev]

VS> То что описано про сабж в SVN
VS> http://svnbook.red-bean.com/en/1.0/ch07s04.html
VS> производит ужасное впечатление. Разархивировать исходники новой версии
VS> стороннего софта поверх рабочей копии vendor branch и потом коммитить
VS> получившееся? Читая "svn status", а потом вручную делая "svn add" и
VS> "svn rm" на новые или не нужные файлы? И даже если не вручную, а
VS> посредством костыля svn_load_dirs.pl, всё равно ужасно. Даже в CVS
VS> было сделано приличнее. Часто встречаю упоминания, что многие
VS> описанный способ не используют, а предпочитают тупо импортировать
VS> каждую новую версию сторонних исходников в отдельную ветку. Дисковое
VS> пространство конечно расходуется расточительно, но оно сейчас дешевое.

Hу так мы имеем по крайней мере решение не хуже, чем в CVS. Там тоже
надо было делать сначала импорт, а затем вычистку изменений. Плавали,
знаем.

VS> Собственно вопрос. А в других VCS, например git, сделано красивее? И
VS> как именно? (имеется в виду конечно случай, когда сторонний софт сам
VS> не в виде репозитория доступен, а например tarball-ом).

Ты не поверишь - но фактически то же самое.


--netch--

[Victor Sudakov]

Post by Valentin Nechayev
VS> Собственно вопрос. А в других VCS, например git, сделано красивее? И
VS> как именно? (имеется в виду конечно случай, когда сторонний софт сам
VS> не в виде репозитория доступен, а например tarball-ом).
Ты не поверишь - но фактически то же самое.

А ты никогда не пытался продумать, каким должен быть правильный
алгоритм сабжа?

[Valentin Nechayev]

VS>> Собственно вопрос. А в других VCS, например git, сделано красивее? И
VS>> как именно? (имеется в виду конечно случай, когда сторонний софт сам
VS>> не в виде репозитория доступен, а например tarball-ом).

Post by Valentin Nechayev
Ты не поверишь - но фактически то же самое.

VS> А ты никогда не пытался продумать, каким должен быть правильный
VS> алгоритм сабжа?

Я не думаю, что тут должен быть какой-то "алгоритм". А вот что полезно
- в поставке к VCS давать скрипт, который бы вызывал команды
add/del/commit/etc. для полного коммита каталога со всеми изменениями.
В таком случае импорт вендорского кода приводился бы просто к вызову
такого скрипта.


--netch--

[Victor Sudakov]

Post by Valentin Nechayev

VS>> Собственно вопрос. А в других VCS, например git, сделано красивее? И
VS>> как именно? (имеется в виду конечно случай, когда сторонний софт сам
VS>> не в виде репозитория доступен, а например tarball-ом).

Post by Valentin Nechayev
Ты не поверишь - но фактически то же самое.

VS> А ты никогда не пытался продумать, каким должен быть правильный
VS> алгоритм сабжа?
Я не думаю, что тут должен быть какой-то "алгоритм". А вот что полезно
- в поставке к VCS давать скрипт, который бы вызывал команды
add/del/commit/etc. для полного коммита каталога со всеми изменениями.
В таком случае импорт вендорского кода приводился бы просто к вызову
такого скрипта.

Hасколько я понимаю, svn_load_dirs.pl и есть такой скрипт. Только
почему-то многие советуют им не пользоваться, а импортировать каждый
новый vendor branch в отдельный каталог, а потом делать
"svn merge --ignore-ancestry" между вендорскими ветками в рабочую
копию.

[Victor Sudakov]

Post by Valentin Nechayev

VS>> Собственно вопрос. А в других VCS, например git, сделано красивее? И
VS>> как именно? (имеется в виду конечно случай, когда сторонний софт сам
VS>> не в виде репозитория доступен, а например tarball-ом).

Post by Valentin Nechayev
Ты не поверишь - но фактически то же самое.

VS> А ты никогда не пытался продумать, каким должен быть правильный
VS> алгоритм сабжа?
Я не думаю, что тут должен быть какой-то "алгоритм".

Тем не менее в разных VCS реализованы разные алгоритмы merge, как
почитаешь - глаза разбегаются. Кроме обычного diff3, есть всякие
staircase merge, simple weave merge etc etc. Возможно какой-то из
алгоритмов особенно хорошо подходит для сабжа.