Как мне разветвить отдельный файл в SVN?
https://stackoverflow.com/questions/117415
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Концепция ветвления Subversion, похоже, сосредоточена на создании [не]стабильной ветки всего репозитория, на которой будет осуществляться разработка.Есть ли механизм создания ветвей отдельных файлов?
В качестве примера использования подумайте об общем файле заголовка (*.h), который имеет несколько реализаций исходного кода (*.c) для конкретной платформы.Этот тип филиала является постоянным.Все эти филиалы будут постоянно развиваться с периодическим слиянием между филиалами.Это резко контрастирует с нестабильными ветвями разработки/стабильной версии, которые обычно имеют ограниченный срок действия.
я не хотите разветвить весь репозиторий (дешево или нет), так как это потребует необоснованного объема обслуживания для постоянного объединения ствола и всех ветвей.В настоящее время я использую ClearCase, который имеет другую концепцию ветвления, которая упрощает эту задачу.Меня попросили рассмотреть возможность перехода на SVN, но эта разница в парадигме важна.Меня гораздо больше беспокоит возможность легко создавать альтернативные версии для отдельных файлов, чем такие вещи, как вырезание ветки стабильного выпуска.
Решение
К сожалению, я думаю, что реальный ответ здесь заключается в том, что ClearCase справляется с этой ситуацией намного лучше, чем Subversion.При использовании Subversion вам придется разветвляться все, но ClearCase допускает своего рода идею «ленивого ветвления», которая означает, что разветвляется только определенная группа файлов, остальные по-прежнему следуют по магистрали (или по той ветке, которую вы укажете).
Другие решения, представленные здесь, на самом деле не работают так, как вы предполагаете, они просто копируют файл по другому пути.Теперь вам придется делать странные вещи, чтобы действительно использовать этот файл.
Эм, извини.Это был не очень хороший ответ.Но в Subversion нет хорошего решения этой проблемы.Его модель — ветвление и слияние.
Редактировать:Хорошо, давайте продолжим то, что сказал крашмстр.Вы можете сделать это:
svn cp $REP/trunk/file.h $REP/branched_files/file.h
svn co $REP/trunk
svn switch $REP/branched_files/file.h file.h
Но ничего себе! Это склонно к ошибкам.Всякий раз, когда вы выполняете svn st, вы увидите это:
svn st
S file.h
Немного шумно это.А когда вы захотите разветвить несколько файлов или модулей в большом репозитории исходного кода, это станет очень запутанным.
На самом деле, здесь, вероятно, есть достойный проект для моделирования чего-то вроде разветвленных файлов ClearCase со свойствами svn и переключениями, написания оболочки вокруг стандартного svn-клиента, чтобы справиться со всем этим беспорядком.
Другие советы
Вам не нужно разветвлять весь репозиторий.Вы можете создавать ветки папок в своем проекте (например, папку включения).Как отмечали другие, вы также можете сделать «копию» только одного файла.Получив копию файла или папки, вы «переключаетесь» на разветвленный файл или папку для работы с версией ветки.
Если вы создадите отдельную папку ветвей в репозитории, вы можете скопировать туда свои разветвленные файлы с помощью команд на стороне сервера:
svn copy svn://server/project/header.h svn://server/branched_files/header.h
Затем вы можете переключить этот файл на использование branches_files путь к репозиторию
Вот как я понимаю вашу проблему.У вас есть следующее дерево:
time.h time.c
и вам нужно отклонить его для нескольких архитектур:
time.h is comon time.c (for x386), time.c (for ia64), time.c (for alpha),...
Также в вашей текущей VCS вы можете сделать это, создав столько ветвей из time.c, сколько необходимо, и когда вы извлекаете файлы из VCS, вы автоматически проверяете последний time.h из общего канала и последний time.c из ветки. вы работаете над.
Проблема, которая вас беспокоит, заключается в том, что если вы используете SVN при проверке ветки, вам придется очень часто объединять time.h из магистрали или рисковать работать над более старым файлом (по сравнению с магистралью), такой объем накладных расходов неприемлем. тебе.
Однако в зависимости от структуры вашего исходного кода может быть решение.представь, что у тебя есть
/ /headers/ /headers/test.h /source/ /source/test.c
Тогда вы можете разветвить / и использовать СВН: внешние устройства функция, позволяющая связать ваши заголовки с головкой багажника.Он работает только с каталогами и имеет некоторые ограничения в отношении возврата в test.h (чтобы это работало, вам нужно зайти в каталог заголовка), но это может сработать.
«Ветка» Subversion — это просто копия чего-то в вашем репозитории.Итак, если вы хотите разветвить файл, вам просто нужно сделать:
svn copy myfile.c myfile_branch.c
Я не думаю, что есть смысл разветвлять один файл?Нет возможности проверить по транковому коду?
Вместо этого вы можете использовать патч, если хотите отменить изменения и применить их позже.
Вы уверены, что вам действительно нужна эта функция? в вашей системе контроля версий ?
Почему бы не использовать препроцессор C и #ifdef убрать ненужный код?Или любой подобный инструмент.
что-то вроде:
// foo.h:
void Foo();
// foo_win32.c
#ifdef _WIN32
void Foo()
{
...
}
#endif
// foo_linux.c
#ifdef _GNUC
void Foo()
{
...
}
#endif
Иногда, если что-то не подходит, значит, это неправильное решение.
Ветка в SVN — это просто копия.Я считаю, что для того, чтобы сделать это так, как вы надеетесь, вам нужно будет разместить каждую версию файла в отдельном каталоге репозитория и извлечь ее в исходную папку.И.Е.относитесь к этому файлу как к отдельному проекту.
Ветка в Subversion — это именно то, о чем вы говорите.Все файлы являются точной копией ствола, за исключением тех, которые вы меняете.Это метод «дешевой копии», о котором говорится в книге SVN.Единственный нюанс — необходимость время от времени объединять ствол с веткой, чтобы быть уверенным, что внесенные там изменения отразятся в ветке.Конечно, если эти изменения нежелательны, слияния магистралей и ветвей не требуется.
Одним из простых способов разрешить автоматическое объединение изменений в магистральном канале (что имитирует парадигму Clear Case) является использование сценария перехвата перед фиксацией для объединения изменений в магистральном канале перед фиксацией. (фактически, это всегда хорошая стратегия предотвращения дрейфа кода).
