Как мне разветвить отдельный файл в SVN? - PullRequest
8 голосов
/ 23 сентября 2008

Представляется, что концепция ветвления subversion сфокусирована на создании [не] стабильного ветвления всего репозитория, на котором будет осуществляться разработка. Есть ли механизм для создания веток отдельных файлов?

В случае использования подумайте о файле общего заголовка (* .h), который имеет несколько реализаций исходного кода (* .c) для конкретной платформы. Этот тип филиала является постоянным. Все эти ветви будут развиваться с периодическим слиянием между филиалами. Это резко контрастирует с нестабильными ветвями разработки / стабильного выпуска, которые обычно имеют конечную продолжительность жизни.

Я не не хочу разветвлять весь репозиторий (дешевый или нет), так как это создаст необоснованный объем обслуживания для непрерывного объединения между стволом и всеми ветвями. В настоящее время я использую ClearCase, у которого другая концепция ветвления, которая делает это простым. Меня попросили рассмотреть возможность перехода на SVN, но эта разница в парадигме важна. Меня гораздо больше беспокоит возможность легко создавать альтернативные версии для отдельных файлов, чем такие вещи, как вырезание ветки стабильного выпуска.

Ответы [ 8 ]

9 голосов
/ 23 сентября 2008

Вам не нужно разветвлять весь репозиторий. Вы можете сделать ветви папок в вашем проекте (например, включить папку). Как уже отмечали другие, вы также можете сделать «копию» только одного файла. Получив копию файла или папки, вы «переключаетесь» на разветвленный файл или папку, чтобы работать с версией ветки.

Если вы создадите отдельную папку ветвей в хранилище, вы можете скопировать туда свои разветвленные файлы с помощью команд на стороне сервера:

svn copy svn://server/project/header.h svn://server/branched_files/header.h

Затем вы можете переключить этот файл на branches_files путь к хранилищу

3 голосов
/ 23 сентября 2008

Вот как я понимаю вашу проблему. У вас есть следующее дерево:

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

Тогда вы можете перейти / и использовать функцию svn: externals , чтобы связать ваши заголовки с головой ствола. Он работает только с каталогами и имеет некоторые ограничения в отношении возврата в test.h (чтобы он работал, нужно перейти в каталог заголовков), но он может работать.

3 голосов
/ 23 сентября 2008

К сожалению, я думаю, что реальный ответ здесь заключается в том, что ClearCase справляется с этой ситуацией намного лучше, чем Subversion. С помощью subversion вам необходимо ветвиться что угодно , но ClearCase допускает своего рода идею "ленивого ветвления", которая означает, что разветвленная ветвь только определенной группы файлов, остальные все еще следуют за стволом (или какой бы ветвью вы не занимались) уточните).

Другие решения, представленные здесь, на самом деле не работают так, как вы предполагаете, они просто копируют файл по другому пути. Теперь вы должны сделать странные вещи, чтобы фактически использовать этот файл.

Эм, извините. Это был не очень хороший ответ. Но нет хорошего решения этого с Subversion. Его модель - филиал и слияние.

Редактировать: ОК, поэтому подробно остановимся на том, что сказал crashmstr. Вы могли бы сделать это:

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-клиента bog, чтобы справиться со всем этим беспорядком.

1 голос
/ 23 сентября 2008

Вы действительно нуждаетесь в этой функции в вашем VCS ?

Почему бы не использовать препроцессор C и не использовать #ifdef код, который вам не нужен? Или любой подобный инструмент.

что-то вроде:

// foo.h:
void Foo();

// foo_win32.c
#ifdef _WIN32
void Foo()
{
   ...
}
#endif

// foo_linux.c
#ifdef _GNUC
void Foo()
{
   ...
}
#endif

Иногда, если это не подходит, тогда это не правильное решение.

1 голос
/ 23 сентября 2008

Не думаю, что есть смысл в разветвлении одного файла? Нет способа проверить это с кодом транка?

Вместо этого вы можете взять патч, если хотите отменить изменения и применить их позже.

1 голос
/ 23 сентября 2008

"Ветвь" Subversion - это просто копия чего-то в вашем хранилище. Так что если вы хотите разветвить файл, вы просто сделаете:

svn copy myfile.c myfile_branch.c
0 голосов
/ 23 сентября 2008

Ветвь в Subversion - это именно то, о чем вы говорите. Все файлы являются точной копией ствола, за исключением тех, которые вы меняете. Это методология «дешевой копии», о которой говорится в книге SVN. Единственным предостережением является необходимость время от времени объединять ствол с веткой, чтобы гарантировать, что сделанные в ней изменения отражаются в ветке. Конечно, если эти изменения нежелательны, слияния в ствол-> ветвь не требуется.

Один простой способ разрешить автоматическое объединение изменений в стволе (который имитирует парадигму Clear Case) состоит в использовании сценария ловушки перед фиксацией для объединения изменений в стволе до принятия (фактически всегда хорошая стратегия для предотвращения смещения кода).

0 голосов
/ 23 сентября 2008

Ветка в SVN - это просто копия. Я полагаю, что для того, чтобы сделать это так, как вы надеетесь, вам нужно будет иметь каждую версию файла в отдельном каталоге в хранилище и проверить его в исходной папке. И.Е. рассматривать этот файл как отдельный проект.

...