Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 21
Однажды мне ваш топик должен очень помочь. Спасибо, в закладочки. :)
Спасибо. Нет ли информации о том как поддерживают такие действия визуальные средства TortoiseSVN или SubClipse? Возможно, в них уже встроено такое поведение…
Полезно, хотя я все больше отказывюсь от свн в пользу git
и это верно. «Рассмотрим способы их решения.»:
1) Способ первый — использовать git, hg, bzr
2) Способ второй — Берем howto и начинаем фиксить проблемы дизайна svn.
1) Способ первый — использовать git, hg, bzr
2) Способ второй — Берем howto и начинаем фиксить проблемы дизайна svn.
Насколько я знаю и насколько видно из письма Линуса, git не умеет мёржить переименованные и изменённые файлы. Возможно, я ошибаюсь, поэтому и прошу в заметке писать содержательные комментарии о решении данной задачи в других системах управления версиями, а не просто отсылать к ним.
GIT хорошо поддерживает то, о чем вы написали — мердж происходит автоматически.
Конфликт может возникнуть только при стандартной ситуации типа «одна и та же часть файла изменилась в разных бранчах», но к переименованию это никакого отношения не имеет.
Конфликт может возникнуть только при стандартной ситуации типа «одна и та же часть файла изменилась в разных бранчах», но к переименованию это никакого отношения не имеет.
Линус в своём письме утверждает обратное:
For example, let’s say that you have the common commit A, and file “x”, and two paths (B and C) where B has renamed the file “x” to “y”, and C has modified file “x”. You end up with the schenario that our trivial merge fails to handle, and right now we give up, and don’t help the user very much at all.
Насколько я понимаю, на момент написания этого письма (5 сентября 2005 г.) так оно и было.
Но на текущий момент в нашем проекте никаких проблем с мерджингом переименованных файлов не наблюдается.
В теоретические нюансы алгоритма не углублялся — и так ведь работает.
Но на текущий момент в нашем проекте никаких проблем с мерджингом переименованных файлов не наблюдается.
В теоретические нюансы алгоритма не углублялся — и так ведь работает.
Спасибо, тогда это действительно ещё один повод перейти на git.
Переходите, не пожалеете!
Нам сначала было весьма непривычно, но как только мозг освобождается от стереотипов SVN/CVS, приходит осознание того, насколько же это классная штука :)
Нам сначала было весьма непривычно, но как только мозг освобождается от стереотипов SVN/CVS, приходит осознание того, насколько же это классная штука :)
Можно ли перевести на GIT большой проект вместе с историей? Т.к. за жизнь проекта похожие случаи наблюдались неоднократно… Можете посоветовать какие-либо полезные утилиты? Спасибо.
На момент миграции в нашем репозитории было примерно 4500 ревизий.
Миграцию проводил не я, но, насколько я знаю, она прошла абсолютно гладко.
Стандартная программка git-svn отлично с этим справляется.
В инете хватает материалов на эту тему, например вот.
Миграцию проводил не я, но, насколько я знаю, она прошла абсолютно гладко.
Стандартная программка git-svn отлично с этим справляется.
В инете хватает материалов на эту тему, например вот.
Занес в закладки ;-)
После таких статей начинать пользоваться системами контроля версий как-то ссыкотно. Полный бекап кода рулит без альтернатив :).
Системы контроля версий как раз и позволяют вам иметь полный бэкап кода за любую дату и в любой ветке разработки. Плюс в помощь предоставляется автоматическое сравнение правок с подсветкой различий между ними и лог коммитов-сохранений с вашими комментариями, по желанию подробными, также привязываемыми к каждой правке.
Присмотритесь попристальней, поймете, что это благо.
P.S. А архивчики с бэкапами проекта вы наверное датами нумеруете?
Присмотритесь попристальней, поймете, что это благо.
P.S. А архивчики с бэкапами проекта вы наверное датами нумеруете?
> Subversion не смогла применить изменения, т. к. не нашла файл foo.txt в рабочей копии.
> Subversion удалила файл foo.txt и добавила копию файла bar.txt из ветки $source. При этом все изменения в файле foo.txt, произведённые в текущей ветке, оказались утеряны.
Вопрос: если сразу не замечаешь эти нестыковки, кусок кода будет утерян чтоли? Особенно радует, что изменения в текущей ветке оказались утеряны. То есть, коммит прошел, и привет — пиши заново? Если, конечно, сразу внимание обратишь. А то можно и через неделю обнаружить, и вспоминать — а что там было то?
> Subversion удалила файл foo.txt и добавила копию файла bar.txt из ветки $source. При этом все изменения в файле foo.txt, произведённые в текущей ветке, оказались утеряны.
Вопрос: если сразу не замечаешь эти нестыковки, кусок кода будет утерян чтоли? Особенно радует, что изменения в текущей ветке оказались утеряны. То есть, коммит прошел, и привет — пиши заново? Если, конечно, сразу внимание обратишь. А то можно и через неделю обнаружить, и вспоминать — а что там было то?
Имеется в виду, что изменения файла в текущей ветке не попадут в коммит. Но благодаря тому, что любая система управления версиями хранит все предыдущие состояния файла, любой код можно восстановить, просто отменив коммит.
Ну все-таки не «отменить коммит», а вернуться к прежней правке ;)
> Особенно радует, что изменения в текущей ветке оказались утеряны.
Еще раз… Никакие изменения не теряются. Все что вы редактируете, мержите (проводите слияние веток) — эти операции выполняются в вашей рабочей копии проекта. В любой момент времени с помощью svn status, svn diff вы можете с точностью до замененного символа просмотреть, чем отличается ваша раб. копия от крайней HEAD или любой другой правки в хранилище.
Смысл слияния, вроде, прозрачен и понятен всем — например, объединить изменения кода, накопленные во временных ветках, разрабатываемых разными программистами в одну главную ветку, из которой будет собран релиз. Но почему-то, наткнувшись, на проблемы, подобные сабжу, забывается, что команда svn merge — это всего лишь инструмент, помогающий провести объединение кода из разных мест наиболее быстрым образом, поскольку эта команда старается отслеживать всю историю изменений в указанном для слияния диапазоне правок. Конечное слово перед коммитом остается за программистом.
Наивно предполагать, что коммит получится провести сразу после выполнения svn merge, скорее всего, часть файлов войдет в конфликтующее состояние, требующее обязательного «ручного» анализа с принятием/удалением/редактированием своих/чужих вариантов отдельных строк кода, которые в спорных случаях довольно удобным образом помечаются, плюс рядышком в рабочей копии merge подкладывает пару файликов .left, .right с содержимым, взятым из «левой» и «правой» сравниваемых версий соответственно.
Задача сводится к устранению конфликтов в нескольких файлах после merge или update, а не поиску и перепроверке всех измененных мест в проекте.
Автор статьи указал случай, за что ему огромное спасибо (взял на заметку), когда такого конфликта SVN не подсказывает, и теперь на переименования файлов в проекте буду обращать отдельное внимание.
К сожалению, не настолько силен, чтобы дописать какой-нибудь триггер на переименование файлов для отслеживания таких граблей, но статья определенно пошла на пользу.
> Особенно радует, что изменения в текущей ветке оказались утеряны.
Еще раз… Никакие изменения не теряются. Все что вы редактируете, мержите (проводите слияние веток) — эти операции выполняются в вашей рабочей копии проекта. В любой момент времени с помощью svn status, svn diff вы можете с точностью до замененного символа просмотреть, чем отличается ваша раб. копия от крайней HEAD или любой другой правки в хранилище.
Смысл слияния, вроде, прозрачен и понятен всем — например, объединить изменения кода, накопленные во временных ветках, разрабатываемых разными программистами в одну главную ветку, из которой будет собран релиз. Но почему-то, наткнувшись, на проблемы, подобные сабжу, забывается, что команда svn merge — это всего лишь инструмент, помогающий провести объединение кода из разных мест наиболее быстрым образом, поскольку эта команда старается отслеживать всю историю изменений в указанном для слияния диапазоне правок. Конечное слово перед коммитом остается за программистом.
Наивно предполагать, что коммит получится провести сразу после выполнения svn merge, скорее всего, часть файлов войдет в конфликтующее состояние, требующее обязательного «ручного» анализа с принятием/удалением/редактированием своих/чужих вариантов отдельных строк кода, которые в спорных случаях довольно удобным образом помечаются, плюс рядышком в рабочей копии merge подкладывает пару файликов .left, .right с содержимым, взятым из «левой» и «правой» сравниваемых версий соответственно.
Задача сводится к устранению конфликтов в нескольких файлах после merge или update, а не поиску и перепроверке всех измененных мест в проекте.
Автор статьи указал случай, за что ему огромное спасибо (взял на заметку), когда такого конфликта SVN не подсказывает, и теперь на переименования файлов в проекте буду обращать отдельное внимание.
К сожалению, не настолько силен, чтобы дописать какой-нибудь триггер на переименование файлов для отслеживания таких граблей, но статья определенно пошла на пользу.
Спасибо за статью :) Только сегодня ощутили все прелести неотслеживания svn-ом переименований при merge, обошлось правда малой кровью.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Subversion: cлияние переименований файлов