Как разветвить отдельный файл в SVN?

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

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

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

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

wnoise 23.09.2008 01:55
Стоит ли изучать PHP в 2023-2024 годах?
Стоит ли изучать PHP в 2023-2024 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
9
1
10 789
8
Перейти к ответу Данный вопрос помечен как решенный

Ответы 8

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

svn copy myfile.c myfile_branch.c

Ты не понимаешь. Мне нужен один файл с двумя альтернативными ветвями (или «историями» в терминологии некоторых других систем CM). Мне не нужны два связанных, но разных файла.

Michael Carman 23.09.2008 00:41

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

Alexander 23.09.2008 01:03

Я понимаю, что ветка - это всего лишь копия. (Настойчивое требование SVN раскрыть это в пользовательском интерфейсе - одна из моих главных претензий к этому.) Я согласен с ответом «вы не можете этого сделать». Я бы предпочел не использовать молоток для ввинчивания винта. Я просто пытаюсь узнать, какие инструменты доступны.

Michael Carman 23.09.2008 01:27

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

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

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

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

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

Это довольно неудобно, но вполне возможно. Спасибо за вклад.

Michael Carman 23.09.2008 01:05
Ответ принят как подходящий

К сожалению, я думаю, что настоящий ответ здесь заключается в том, что 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 для борьбы со всем беспорядком.

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

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

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

Chris Farmer 23.09.2008 00:59

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

Michael Carman 23.09.2008 01:12

Другой пример - наш проект переходит с одной версии плагина на другую. Это требует изменения свойств затмения. Мы проверяем их. Как сделать так, чтобы люди одновременно запускали старую и новую версию плагина? Было бы неплохо, если бы ветка была такой же, как и другая, за исключением файлов конфигурации eclipse, которые должны быть разными.

Bill K 03.04.2013 02:11

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

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

что-то типа:

// foo.h:
void Foo();

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

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

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

Да, я хочу, чтобы это была функция VCS. Вариант использования был просто простым для понимания примером. Моя реальная ситуация несколько сложнее и не ограничивается C. До сих пор «неправильное решение» для меня означало не SVN.

Michael Carman 23.09.2008 01:20

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

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 (вы должны перейти в каталог заголовка, чтобы он работал), но он может работать.

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

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

Другие вопросы по теме