LINUX.ORG.RU

Синхронизация двух контролей версий, как-то так

 ,


0

2

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

Итак, предположим, у меня есть сайт. Контент на сайте двуязычный, и хочу яя хранить его в VCS. В теории, за каждым изменением в одной версии сайта должен следовать перевод, т.е. изменение в другой версии сайта. На практике, естественно, переводы часто отстают от оригиналов. Хочется как-то запоминать, что «данный коммит является переводом вон того коммита». И видеть, что «этот перевод соответствует оригиналу на вон то число, вот diff того, что изменилось в оригинале».

Как это сделать по уму?

Мой вариант — просто в commit message указывать, до какого коммита-оригинала я актуализировал перевод этим новым коммитом, а потом собственным скриптом отыскивать, у каких файлов есть коммиты, не упомянутые ещё в commit message переводов, т.е. какие файлы требуют перевода.

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

Ответ на: комментарий от emulek

А что, там есть такое, чтобы две ветки параллельно существовали? Если в hg такие же ветки, как в git, то в один момент времени у меня будет развёрнута только одна из них. А у меня всё-таки единый инстанс сайта, просто между некоторыми из его файлов такие вот отношения «оригинал<—>перевод».

greatperson
() автор топика
Ответ на: комментарий от greatperson

А что, там есть такое, чтобы две ветки параллельно существовали?

конечно. Стандартный юзкейс — ветки debug и release. Первая постоянно ломается, но на второй это не сказывается. Вторую только во время релиза мержится с первой, и если надо СРОЧНО что-то исправить (например 0day).

Если в hg такие же ветки, как в git, то в один момент времени у меня будет развёрнута только одна из них.

как может существовать одновременно две версии одного файла?

emulek
()
Ответ на: комментарий от emulek

Хотя, в принципе, можно попробовать каждую языковую версию держать отдельно под VCS. Итого (говорю в терминах git, другого ничего не знаю):

— В репозитории имеем две ветки: english и russian.

— Допустим, меняем какой-то текст в russian.

— Обновляем перевод в english, для VCS оформляем это как мердж из russian в english.

— На сайте имеем две папки: /ru и /en, в каждую из которых чекаутнута своя ветка.

Видимо, так.

greatperson
() автор топика
Ответ на: комментарий от emulek

Я ж и объясняю: одна английская и одна русская. Английская является вечно запаздывающим переводом русской, и хочется всегда знать, насколько именно она актуальна/неактуальна.

greatperson
() автор топика
Ответ на: комментарий от greatperson

На сайте имеем две папки: /ru и /en, в каждую из которых чекаутнута своя ветка.

типа того.

Я ж и объясняю: одна английская и одна русская. Английская является вечно запаздывающим переводом русской, и хочется всегда знать, насколько именно она актуальна/неактуальна.

ну «английская» это типа debug, а русская «release» из примера выше.

emulek
()
Ответ на: комментарий от emulek

как может существовать одновременно две версии одного файла?

Есть подобное даже на уровне FS, которые так и называются - versioning file system.

Что же такое случилось с тобой, что ты стал вторым Эдичкой?

AVC_Verehrer
()
Ответ на: комментарий от AVC_Verehrer

Есть подобное даже на уровне FS, которые так и называются - versioning file system.

со мной всё хорошо. А зачем нужна версионная ФС, если ТС и так юзает VCS? ИМХО это взаимоисключающие параграфы, не?

Что же такое случилось с тобой, что ты стал вторым Эдичкой?

я не стал вторым Эдди, просто у дураков мысли сходятся (:

(если они есть).

emulek
()
Ответ на: комментарий от emulek

ИМХО это взаимоисключающие параграфы, не?

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

Чуть-чуть по теме: бранчи тут можно организовать так, чтобы было видно, что уже переведено (например писать в сообщении к коммиту - перевел коммит <хеш коммита>), но ТС хочет какой-то автоматики, чтобы было видно «сходу».

AVC_Verehrer
()
Ответ на: комментарий от AVC_Verehrer

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

_основная_ задача VCS — версионность. Остальное опциональные багофичи.

И да, просто версионность не имеет никакого смысла без авторства, времени, hash'а, и т.п.

Чуть-чуть по теме: бранчи тут можно организовать так, чтобы было видно, что уже переведено (например писать в сообщении к коммиту - перевел коммит <хеш коммита>), но ТС хочет какой-то автоматики, чтобы было видно «сходу».

AFAIK в hg можно делать diff'ы между ветками. Т.е. можно сравнить две головы. Ну и мерж с трёхпутёвым слиянием думаю тоже поможет. Его можно и доработать, что-бы показывал только не переведённое.

emulek
()
Ответ на: комментарий от emulek

AFAIK в hg можно делать diff'ы между ветками

Да, но в одной ведь всё по-русски, а в другой по-английски.

А может ты имел в виду 3 ветки: русскую(A) синхронизированную с английской(B) и русскую текущую(C) (это, как я понял, он с русского на англ. переводит). Тогда:

1) изменения вносим в C

2) по диффу B и С делаем перевод в A

3) Продвигаем B до C.

4) Повтор :)

Вполне вариант

AVC_Verehrer
()
Ответ на: комментарий от AVC_Verehrer

А может ты имел в виду 3 ветки: русскую(A) синхронизированную с английской(B) и русскую текущую(C)

да. Гугли kdiff3 например(для кед, в vim есть искароппки). Ну и mercurial. Так мержатся версии от двух разрабов, если есть конфликты.

emulek
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.