[SVN] Как восстановить свои изменения после update?

>Читаю доку, но понять не могу - как можно хотя бы восстановить состояние файлов на то, которое было до команды svn update?

ЕМНИП — никак. Поправьте меня, если я не прав.

никак нельзя востановить, но изменения по svn update не теряются, в конфликтных файлах должно быть что-нибудь типа <<<<<<<<<<<<<<<<<<<<<<<<
код вашего товарища

ваш код
<<<<<<<<<<<<<<<

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

<<<<<<< .mine
ваши изменения
=======
изменения из хранилища

.r<Номер_ревизии_хранилища>

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

Кроме того, будут созданы файлы:
- «Имя_файла_с_расширением.mine». Это копия вашей версии файла.
- «Имя_файла_с_расширением.r<Номер_ревизии_рабочей_копии>». Это файл, который был в рабочей копии до того, как вы его изменили.
- «Имя_файла_с_расширением.r<Номер_ревизии_хранилища». Это текущая версия файла из
хранилища.

P.S.
Если файл бинарный, исходный файл останется неизменным, и создадутся только два файла:
- «Имя_файла_с_расширением.r<Номер_ревизии_рабочей_копии>» - файл, который был в рабочей копии до того, как вы его изменили.
- «Имя_файла_с_расширением.r<Номер_ревизии_хранилища» - текущая версия файла из хранилища.

Я ж говорю - некоторые файлы автоматом объединились (G). Некоторые конфликтуют (C).

К тем которые конфликтуют у меня вопросов нет, они пока сохренены с расширением mine.

Вопрос о файлах, которые автоматом объединились, и в них был исключен весь мой наработанный код.

Конфликтующих файлов всего два, это заголовки, фигня.

Автоматом объединились файлы с кодом, вот их и надо восстановить.

Скорее всего никак. Это ж SVN.

Как минимум стало понятно, что произошло.

Чувак имеет локальный доступ к серверу на котором крутится SVN, изредка лазиет туда, копируя файлы и каталоги напрямую. «Я туда и от туда копирую». В этот раз он в каталог центрального репозитария скопировал свой локальный каталог, причем в этом локальном каталоге небыло сделано update до тех изменений, что я коммитил.

После таких прогонов у меня все и перекосило.

>Чувак имеет локальный доступ к серверу на котором крутится SVN, изредка лазиет туда, копируя файлы и каталоги напрямую.
Жесть, а вообще прежде чем сливать в один и тот же файл, его нужно ризолвить. Автоматический резолв SVN делать не должен, даже если изменения в разных местах файла.

>Автоматический резолв SVN делать не должен, даже если изменения в разных местах файла.
Что?

> Чувак имеет локальный доступ к серверу на котором крутится SVN, изредка лазиет туда, копируя файлы и каталоги напрямую. «Я туда и от туда копирую».

Твой коллега - стопроцентный м!дак. Не трать свое время и силы на работу в одной команде с ним.

>Автоматический резолв SVN делать не должен, даже если изменения в разных местах файла.

Что?

Если версия на сервере новее локальной копии и копия редактировалась, то нужно резолвить вручную. Таких проблем как описано выше, при нормальной работе с svn, нету.

>Чувак имеет локальный доступ к серверу на котором крутится SVN, изредка лазиет туда, копируя файлы и каталоги напрямую.

Ну, теперь передай ему привет.

Поздравляю с удачным началом рабочей недели

Сто раз уже твердили Сене, Спасет нас GIT от удаленья...

> Конфликтующих файлов всего два, это заголовки, фигня.

Автоматом объединились файлы с кодом, вот их и надо восстановить.

ну так svn up -r{последняя неиспорченная ревизия}

svn для того и нужен

> ну так svn up -r{последняя неиспорченная ревизия}

естественно, сначала забэкапь то, что осталось, чтоб не потерять последнее под радостное улюлюканье лоровских знатоков.

да, только в этих ревизиях не будет кода, который автор «писал все выходные». А так да, все круто, конечно.

Как я понял, суть в том, что SVN при автоматическом мердже отчего-то посчитал, что изменения топикстартера - более старые.

Если это так - то единственный способ что-то добыть - сделать dd и грепать до посинения по образу. Если еще не поздно, конечно.

А вообще - это каким же надо быть... программистом, чтобы не бэкапить локальные изменения (хоть в git/hg/bzr, хоть просто в тарболл).

>А вообще - это каким же надо быть... программистом, чтобы не бэкапить локальные изменения (хоть в git/hg/bzr, хоть просто в тарболл).
Это ещё зачем? Система контроля версий уже не помогает в этом?

Централизованная - не всегда помогает.

> Чувак имеет локальный доступ к серверу на котором крутится SVN, изредка лазиет туда, копируя файлы и каталоги напрямую. «Я туда и от туда копирую». В этот раз он в каталог центрального репозитария скопировал свой локальный каталог, причем в этом локальном каталоге небыло сделано update до тех изменений, что я коммитил.

Здесь не совсем понятно: Хранилище имеет свой особый формат - либо используется своя «файловая система» FSFS, либо Berkeley DB, а рабочая копия - это просто обычные каталоги со служебными каталогами .svn. Поэтому неясно что он мог копировать. Если только хранилище целиком (но смысл такого копирования не ясен).
Если же он ничего не копировал, а просто зафиксировал свои изменения, пока вы редактировали свою рабочую копию, то вы можете попробовать убрать «слитые» изменения с помощью команды svn merge. Для этого нужно выполнить команду (только сделайте перед её выполнением на всякий случай копию своей рабочей копии):
svn merge -r N2:N1 путь_к_хранилищу путь_к_рабочей_копии_со_слитыми _изменениями
Здесь:
N1 - номер ревизии, для которой была создана ваша рабочая копия,
а N2 - номер следующей, чужой ревизии, которая была сделана пока вы редактировали вашу рабочую копию.

> Здесь не совсем понятно: Хранилище имеет свой особый формат - либо используется своя «файловая система» FSFS, либо Berkeley DB, а рабочая копия - это просто обычные каталоги со служебными каталогами .svn. Поэтому неясно что он мог копировать. Если только хранилище целиком (но смысл такого копирования не ясен).

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

У него была полная, но устаревшая копия проекта. Он сделал update, потом в свой рабочий каталог залил эту устаревшую копию проекта и закоммитил. В результате файлы в SVN стали «старыми». И тут я делаю update и получаю кашу.


Вот, если интересно почитай:

----- 8< -----

* derxintrea: Что-то ты с файлами на серваке сделал. На серваке в St_client нет версии 1.52, хотя я ее коммитил.
* streloc: странно, вроде не откатывал ни куда
… сейчас посмотрю
… версии 1,52 нет, это имеешь ввиду?
* derxintrea: да, смотри каталог St_client

...

* derxintrea: Понимаешь что ты наделал?
… В пятницу ты за каким-то хреном залил в SVN старые файлы. Минусы в диффе говорят о том, что код был в 84-й ревизии, и был удален в 91-й. Этот код должен быть на месте, он актуальный и я его не удалял. И так по каждому моему файлу.
* streloc: шас откачу до 84 ревизии все твои файлы в директории St_client
… мой косяк закомитил без апдейта из свна, лежали в свне более новые чем я туда положил, а вообще странно, если не апдейтился, то он не должен дать мне закомитеть файлы
* derxintrea: Нахер мне они теперь нужны, когда работа всеравно потеряна
* streloc: надо держать рабочую копию и свн отдельно, это не SourceSafe, тут другие принципы
… так откатывать или не откатывать?
* derxintrea: Принципы такие, что за коммит без апдейта в нормальных конторах увольняют нахер.
* streloc: комит без апдейта не возможен в самом свне
* derxintrea: Ну и как у тебя это получилось?
* streloc: как такое получилось другйо вопрос
… попробуй создай тестовый репозитарий, закомить туда файл, потом из друго источника закомить, без апдейта рабочей директории, потом в ту же директории ты комит сделать ен сможешь, а что ты абсолютно не знаешь как работать с свном, то валить на меня не нужно
* derxintrea: Значит ты напрямую что-то крутишь в самих каталогах, где svn хранилище лежит
* streloc: как раз я туда и от туда только копирую
* derxintrea: ??? Оттуда еще понятно. Но туда копируешь? Это сильно
… Ничего пока не трогай.

...

* derxintrea: Сейчас надо понять какой кусок выпал.
… Ты в пятницу хуйнул в ценральный репозитарий какое-то «сохранение». От какого числа это сохранение?
… И вообще скажи толком, что ты сделал, тока не ври.
… Пятница, время 22:41. Что было тобой сделано?
* streloc: епт, научись работать правильно с свном
* derxintrea: Я то работаю правильно
* streloc: почему все кто тут работаеют не потеряют свои файлы чтобы с свном не делалось, даже рухни он, а ты работаешь правильнее всех и у тебя такие проблемы?
* derxintrea: Объясняй простыми словами, что ты сделал в пятницу.
* streloc: ты свном пользовваться не умеешь, там же логи все сть, все можно посмотреть
* streloc: те грабли на которые ты наступил, черех них все проходят, не ты первый, не ты последний, но если не хочешь терять свои файлы при работе с свном, держи отдельно рабочую директории и свн
* derxintrea: Ты точно напрямую в каталоги svn центрального репозитария ничего не копировал?
* streloc: что подразумевашь под прямым копирования в svn центрального репозитария?
* derxintrea: Там где svn сервер крутится.
… В каталоги сервера ты ничего не копировал?
* streloc: копирование на самом сервере где свн крутиться? у меня туда доступа нет, могу только через сам репозитарий работать
* derxintrea: бля, а кто писал «как раз я туда и от туда только копирую»

...

* derxintrea: Ты что, не помнишь чтоли, что ты делал? Что значит «скорее всего»?
* streloc: я помню что апдейта точно не не делал в тот день, но все люди, все ошибаются
* derxintrea: Объясни тогда, ведь ты знаешь как работает SVN. Если SVN без апдейта не дает закоммитить, то как получилось что изменения в моем файле зафиксированы от твоего имени?

# svn log St_client/objects/mnk/stMainMnk.cpp
------------------------------------------------------------------------
r91 | streloc | 2009-12-04 22:41:10 +0300 (Птн, 04 Дек 2009)
------------------------------------------------------------------------
r84 | xintrea | 2009-11-30 20:34:21 +0300 (Пнд, 30 Ноя 2009)

… Откуда вообще взялись изменения 91 моего файла от твоего имени?

* streloc: скорее всего просто ошибся при апдейте из свана, не забрал файлы при апдейте, и накатил потом старые, вот это признаю, мой косяк
* derxintrea: Как можно «не забрать файлы при апдейте»? Апдейт - это как раз и получение файлов.
* streloc: раскажу лучше как можно потерять файлы
* derxintrea: Нет, ты сначал расскажи как можно «не забрать файлы при апдейте»?
* streloc: расказыал уже
* derxintrea: Тогда рассказывай, как ты делаешь апдейт? В kdesvn? Куда конкретно тыкаешь? Мне проверить нужно, я эту прогу не знаю.
* streloc: Лучше заведи себе две отдельные директории, одну в которой работаешь, вторую для свна
… тогда у тебя вопрос не возникнет, и ты никаким образом не сможешь потерять файлы
… а еще иногда стоит архивировать исходники с локальной копии, так на всякий случай
* derxintrea: Это уже не твои проблемы, есть у меня копия или нет. Сейчас я спрашиваю, как ты делаешь апдейт (то есть получение свежих версий файлов) так, что у тебя исчезают эти свежие версии. Как ты это делаешь?
* streloc: но файлы то ты потерял, а не я или хочешь сказать что я файлы потерял?
… в гуггле задай вопрос как делают апдей из свна и как вообще с ним работаеют
* derxintrea: Конечно, в результате твоих действий. Но я то файлы восстановлю. Но мне нужно знать, какие действия ты делал?
* streloc: востаранилвай, и постарйся не терять, у тебя у одного такие проблемы возникают, ен наводит это на определнную мысль?
* derxintrea: Нет, не наводит. Я спокойно доверяю что CVS что SVN, настраиваю сохранение на самом серваке, где крутится эта система контроля, и все впорядке. Но это когда я делаю.

...

* derxintrea: Снова. Как ты сделал апдейт (то есть получил свежие версии файлов) так, что у тебя исчезли эти свежие версии?
* streloc: обясню после того, как ты раскажешь почему ты можешь потерять файлы
… и никто из тех кого знаю не может потерять файлы
* derxintrea: Я же вижу, что ты в течении пяти минут пять коммитов сделал. В некоторых коммитах неебическое количество файлов. Руками ты их править не мог. Значит, ты их откуда-то копировал.
* streloc: чем ты такой уникальный, что все делаешь правильно, но проблемы при этом есть только утебя?
* derxintrea: Значит ты откуда-то поверх только что заапдейченых файлов залил из какого-то каталога старые версии. Потом закоммитил. Так ты делал или нет?
* streloc: тебе уже 2 раза сказал об этом, читай внимательнее
* derxintrea: Ты об этом не сказал
* streloc: вот [14:21:46] «скорее всего просто ошибся при апдейте из свана, не забрал файлы при апдейте, и накатил потом старые» эту уже третий раз копирую
* derxintrea: Бля тебя хуйпоймешь
… «не забрал файлы при апдейте, и накатил потом старые»
… вот здесь ошибка.
… Правильно будет «забрал файлы при апдейте, и накатил потом старые»
* streloc: знаешь, люди которые тут работают до этого работали в больших конторах, там так же все работали
… может проблема все же у тебя одного, а не у всех
… ?
* derxintrea: Да у меня нет проблем. Я щас файлы восстановлю. Но мне нужно было знать, что произошло, может быть был способ восстановить более простым путем. Придется восстанавливать сложным.
* derxintrea: Все, вопросов к тебе больше не имею.

----- 8< -----

> * streloc: Лучше заведи себе две отдельные директории, одну в которой работаешь, вторую для свна

Интересный стиль работы :) Многое объясняет.

* derxintrea: Принципы такие, что за коммит без апдейта в нормальных конторах увольняют нахер.

Вот примерно поэтому SVN - говно.

P.S. «Стрелок» - это он не из «Лабиринта отражений» взял?

svn всё там разрулит, если не лазить грязными ручёнками в саму базу.

> svn всё там разрулит

Где «там», при апдейт+коммит? Оно разрулит, да. И ты закоммитишь не то, с чем работал. Но с точки зрения SVN всё будет нормально.

>> * streloc: Лучше заведи себе две отдельные директории, одну в которой работаешь, вторую для свна

Интересный стиль работы :) Многое объясняет.

Пришлось сделать инкрементальное копирование через rdiff-backup. Теперь перед апдейтом я его запускаю, потом делаю апдейт, проверяю как работает, дорабатываю немного если нужно, снова инкременталку запускаю если что-то дорабатывал, и делаю коммит.

Дурдом в общем.

Используй git-svn и не парь людям мозг.

А это мысль.

Только не понял, как пользоваться. Это часть гита или нет?

Вот тут написано, что надо писать «git-svn» http://linsovet.com/git-svn-sync-changes

А вот тут написано, что «git svn» http://webdev-notes.blogspot.com/2008/08/git-svn-mini-howto.html

Кажется, я понял в чём дело. Этот человек, который записал старые версии файлов в хранилище, просто неправильно работает с svn:
Он создаёт рабочую копию, но правит файлы не в ней, а в каком-то своём отдельном, простом каталоге. После исправления файлов в этом каталоге, он просто копирует их в рабочую копию.
Это не правильно, так как файлы должны правиться именно в рабочей копии.

При его способе работы он всегда вынужден «вручную» следить за тем, что в его каталоге, где он правит файлы, находятся данные именно той ревизии, для которой была создана рабочая копия. Понятно, что рано или поздно он бы за этим не уследил, что и произошло.
То есть что случилось? Он создал рабочую копию, а потом копированием заменил файлы рабочей копии файлами из своего каталога (а в его каталоге оказались старые версии файлов). Затем он попытался зафиксировать изменения. Судя по всему ревизия, для которой была создана его рабочая копия была последней ревизией хранилища. Поэтому при обновлении рабочей копии перед фиксацией, конфликтов не возникло. И с точки зрения svn всё было правильно: имеется рабочая копия для последней ревизии с изменёнными файлами, поэтому изменения честно были записаны в хранилище.

В общем, мне кажется, что нужно с этим человеком провести профилактическую беседу, сказав, что файлы должны правиться в рабочей копии, при необходимости сославшись на стандартную справку Subversion - svn-book, где описан порядок работы. Иначе у вас всегда будет потенциальная угроза, что он запишет не те версии файлов в хранилище.

А откатить слияние, произошедшее при обновлении, судя по всему, можно было с помощью svn merge. Я попробовал, смоделировав ситуацию на простеньком примере, вроде получилось.

>И ты закоммитишь не то, с чем работал

Не вижу проблем. Посмотрел на мёржи - твоя функциональность не влияет на чужую, и закоммитил. Если влияет, исправил. В чём проблема-то?

> В общем, мне кажется, что нужно с этим человеком провести профилактическую беседу, сказав, что файлы должны правиться в рабочей копии, при необходимости сославшись на стандартную справку Subversion - svn-book, где описан порядок работы. Иначе у вас всегда будет потенциальная угроза, что он запишет не те версии файлов в хранилище.

Беспалезно. Человек неадекватен, абсолютно и окончательно. Так что поможет либо rdiff-backup, либо git-svn, если у него действительно безопасный апдейт.

> Вот тут написано, что надо писать «git-svn»

А вот тут написано, что «git svn»

Это одно и то же. Читай мануалы гита. Начни отсюда: http://git.or.cz/course/svn.html И не парь людям мозг.

>> И ты закоммитишь не то, с чем работал

Не вижу проблем. Посмотрел на мёржи - твоя функциональность не влияет на чужую, и закоммитил. Если влияет, исправил. В чём проблема-то?

Проблема в том, что «чужая» функциональность может повлиять на твою.

После update исходники, с которыми ты работал, могут поменяться. Поэтому следующей командой commit ты коммитишь не то, с чем работал. Об этом tailgunner и говорит.

> Читай мануалы гита.

Всего один вопрос. У git-svn безопасный апдейт? То есть, после команды «git-svn rebase», можно ли вернуть код к состоянию, который был до этой команды?

В SVN имеем проблему:

- Правим код, получаем состояние кода 1
- svn update, получаем состояние кода 2

Как из состояния 2 откатиться в состояние 1 в SVN - только догадки.

Как с этим состоит дело у git-svn?

изучаешь и (если надо) тестируешь точно также, потом коммитишъ. svn -rNN diff часто достаточно, чтобы понять касаются тебя изменения или нет.

>Вопрос о файлах, которые автоматом объединились, и в них был исключен весь мой наработанный код.

Ну дык это легко: svn diff merged-files > mychanges.diff на эти файлы, затем чекаут той ревизии, с которой ты работал и patch -p0 < mychanges.diff. Должно сработать.

>>И ты закоммитишь не то, с чем работал

Не вижу проблем.

Попробуй посмтореть внимательнее.

Посмотрел на мёржи - твоя функциональность не влияет на чужую, и закоммитил. Если влияет, исправил. В чём проблема-то?

Если у вас все всегда так делают и никто никогда не ошибается, то никаких проблем. Но если вы такие идеальные, зачем вам вообще VCS?

>Всего один вопрос. У git-svn безопасный апдейт? То есть, после команды «git-svn rebase», можно ли вернуть код к состоянию, который был до этой команды?

С git-svn ты работаешь с локальным git-репозиторием и его ветками. И регулярно коммитишь свои изменения в git. Если при rebase что-то пойдет не так, у тебя все равно есть свое стабильное локально закоммиченное состояние: rebase ты делаешь в мастере, а свою разработку ведешь в отдельной ветке, коммитишь туда же и мержишь свои изменения в мастер, а когда завершишь и оттестируешь — git svn dcommit и все твои коммиты в master полетят в svn репозитарий.

>Если у вас все всегда так делают и никто никогда не ошибается, то никаких проблем.

Если ты программист, а не кодер, и обладаешь достаточной культурой программировния, ты это тоже будешь делать. Всегда. И не делать так, что у других всё ломается, а ты потом говоришь «а я не знал», или «а мне не сказали». Детский сад, штаны на лямках.

зачем вам вообще VCS?

распределённая разработка взаимозависимых частей некой системы.

> Ну дык это легко: svn diff merged-files > mychanges.diff на эти файлы, затем чекаут той ревизии, с которой ты работал и patch -p0 < mychanges.diff. Должно сработать.

Не сработает. Попробуй сделать сам.

1. Имеем файл module.cpp в котором три функции - init(), draw(), calculate(), коммитим. И после коммита, каталог где лежит этот файл всместе с подвкаталогом .svn копируем в другой каталог (пусть будет save).

2. Дописываем еще одну функцию show().

3. Переходим в каталог save, делаем touch module.cpp и запускаем апдейт и коммит. То есть, эмулируем залитие в SVN устаревшей версии, как это сделал сотрудник. (Он сначала в свой рабочий каталог залил старую версию, поэтому для эмуляции и делаем touch, потом сделал апдейт и коммит).

4. Переходим опять в рабочий каталог. Даем команду svn update. SVN на автомате все разрулит, и мы получим файл module.cpp, в котором будет отсутсвовать функция show(). То есть, терятся изменения, сделанные в пункте 2.


Каким-то образом SVN видит, что на этапе 3 фукнция show() была удалена. И делает то же самое в пункте 4. Видимо, делается это из-за того, что время у файла, залитого из каталога save больше, чем время у файла в основном рабочем каталоге, т.е файл из каталога save считается более новым.

Вот примерно так можно уработать SVN.

>> Если у вас все всегда так делают и никто никогда не ошибается, то никаких проблем.

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

Тогда вопросов нет.

Детский сад, штаны на лямках.

«Детский сад» - это рассчитывать на то, что кто-то там «программист», а не «кодер». Рассчитывать на то, что ты сам - «программист», «будешь делать, всегда» - это тоже детский сад.

Потому что ты облажаешься, и это только вопрос времени.

>Рассчитывать на то, что ты сам - «программист», «будешь делать, всегда» - это тоже детский сад.

Я не рассчитываю, а делаю. Прежде чем лезть в чужую область изучаю что она делает, пишу письмо что конкретно поменял, и др.

Потому что ты облажаешься, и это только вопрос времени.

Если ты так в этом уверен, пусть так и будет, это бесполезный спор. </thread>

> бесполезный спор. </thread>

Это не было спором.

>Не сработает. Попробуй сделать сам.

А ты попробуй не «эмулировать», тем более так неудачно. Если в svn в истории коммитов нет патчей, удаляющих функцию show, функция show останется на месте. Если патчи, удаляющие функцию show есть, то она есть в какой-то ревизии svn, на которую можно откатиться.

Видимо, ты не до конца осознаешь, что svn up — это всего лишь последовательное наложение закоммиченных патчей на рабочую копию в тех случаях, когда файл рабочей копии был изменен. Если бы svn работал так, как ты думаешь, то svn up = потерять все локальные изменения.

Хм, надо подумать об этом. Но

«Если патчи, удаляющие функцию show есть, то она есть в какой-то ревизии svn, на которую можно откатиться.»

это хорошо, но встает вопрос - на какую конкретно ревизию откатываться. Вопрос впринципе решаем.

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

Поиграйся с утилитами diff (желательно diff -u) и патч на локальных файлах. Потом думай об svn репозитарии как о наборе патчей. Понимание придет само.