Почитать в электронном варианте, присмотреться к содержанию получится только в случае с относительно давно изданной книгой. Где вы найдете текст по неделю назад вышедшей новой версии фотошопа?
Огорчает еще то, что качественно переведенное издание выходит с изрядным временным лагом после выхода оригинала, а чаще уже и после всеобщего признания книги, и переиздания этого самого оригинала за границей.
Ну все-таки не «отменить коммит», а вернуться к прежней правке ;)
> Особенно радует, что изменения в текущей ветке оказались утеряны.
Еще раз… Никакие изменения не теряются. Все что вы редактируете, мержите (проводите слияние веток) — эти операции выполняются в вашей рабочей копии проекта. В любой момент времени с помощью svn status, svn diff вы можете с точностью до замененного символа просмотреть, чем отличается ваша раб. копия от крайней HEAD или любой другой правки в хранилище.
Смысл слияния, вроде, прозрачен и понятен всем — например, объединить изменения кода, накопленные во временных ветках, разрабатываемых разными программистами в одну главную ветку, из которой будет собран релиз. Но почему-то, наткнувшись, на проблемы, подобные сабжу, забывается, что команда svn merge — это всего лишь инструмент, помогающий провести объединение кода из разных мест наиболее быстрым образом, поскольку эта команда старается отслеживать всю историю изменений в указанном для слияния диапазоне правок. Конечное слово перед коммитом остается за программистом.
Наивно предполагать, что коммит получится провести сразу после выполнения svn merge, скорее всего, часть файлов войдет в конфликтующее состояние, требующее обязательного «ручного» анализа с принятием/удалением/редактированием своих/чужих вариантов отдельных строк кода, которые в спорных случаях довольно удобным образом помечаются, плюс рядышком в рабочей копии merge подкладывает пару файликов .left, .right с содержимым, взятым из «левой» и «правой» сравниваемых версий соответственно.
Задача сводится к устранению конфликтов в нескольких файлах после merge или update, а не поиску и перепроверке всех измененных мест в проекте.
Автор статьи указал случай, за что ему огромное спасибо (взял на заметку), когда такого конфликта SVN не подсказывает, и теперь на переименования файлов в проекте буду обращать отдельное внимание.
К сожалению, не настолько силен, чтобы дописать какой-нибудь триггер на переименование файлов для отслеживания таких граблей, но статья определенно пошла на пользу.
Системы контроля версий как раз и позволяют вам иметь полный бэкап кода за любую дату и в любой ветке разработки. Плюс в помощь предоставляется автоматическое сравнение правок с подсветкой различий между ними и лог коммитов-сохранений с вашими комментариями, по желанию подробными, также привязываемыми к каждой правке.
Присмотритесь попристальней, поймете, что это благо.
P.S. А архивчики с бэкапами проекта вы наверное датами нумеруете?
Мне нравится, когда в шутере перед появлением босса показывается эффектный атмосферный ролик с ключевой «кнопкой» на переднем плане, так чтобы можно было сообразить, куда целить. Просто так босса не убьешь — он бессмертный, а, пострелявши в секрет, с десятого выстрела угадать момент, завалить и порадоваться, наконец, «своей» смекалке и меткости =)
Пример — последний босс в обеих частях Max Payne.
Еще маленькая претензия…
Скриншот «Возможность отображения информации на рабочем столе» www.diskwritecopy.com/rus/images/dwc_pro_sshot_2_big.gif весит непозволительно много. Забыли ресайзнуть?
Трафик экономлю (да такое еще бывает=), не ожидал, что за невыдающихся размеров иллюстрацией будет лежать 1280х1024рх…
Дискетку tcm — не трогать! Сам привык к ней издавна и навсегда, похоже)). А тут, на волне отказа от проприетарного софта и с переходом на свободный и бесплатный… Сильно теряюсь, не видя на панели задач узнаваемого логотипчика =( А невразумительная серая пирамидка с глазом — пока что главный минус Unreal Commander'a.
Хорошая иконка по-моему не помешает русскому бесплатному tcm-клону — Unreal Commander x-diesel.com, который мне приглянулся. Не без глюков, конечно, но более полной реализации нужных мне функций tcm я не нашел. Мне нравится и всем рекомендую.
Залог продуктивности — не лениться записывать каждую интересную мысль, чтобы мучительно не вспоминать потом, чего же в голове промелькнуло. Для меня оказалось полезным накидывать таким образом куски, предложения, фразы «наперед», в том числе уже в процессе работы над текстом. Как результат, появляется некий каркас будущего текста, который обрастает разъяснениями, оборотами, примерами и какими-то связками. Каркас этот оказывается несколько удобнее предварительно составляемого плана или содержания. Потому как уже может содержать необходимые слова и формулировки, которые остается только связать между собой.
Независимо от чьих-то рекомендаций и советов (не было их), как только начал пользовать SVN, сам стал описывать изменения в ревизии с префиксами:
+ — добавление функциональности; - — удаление ненужных кусков;
± — изменение с целью улучшения, исправления ошибки.
Не задумывался о том, что тема правильности ведения лога изменений будет вообще где-либо поднята/обнаружена мною, но тем приятнее совпадение мнений:
а) лог коммита — это не просто так, а очень даже может помочь;
б) писать в него надо словами, кратко «проговаривая» каждое изменение;
в) применение символических обозначений улучшает читабельность за счет сокращения количества повторяемых слов;
Совпадение мысли с другой статьей Искусство тратить минуты, экономя часы тоже нашло выражение =)
Для сокращения времени описания правки «потом» при коммите, сразу добавляю описание очередного изменения в файл-заготовку, как только модуль удачно скомпилировался. Добавил новую функцию — в коде откомментировал ее назначение, параметры, важные моменты в реализации, в заготовку лога коммита отписываю:
+ имя_функции(вербализованное, описание, параметров): чего возвращает.
Огорчает еще то, что качественно переведенное издание выходит с изрядным временным лагом после выхода оригинала, а чаще уже и после всеобщего признания книги, и переиздания этого самого оригинала за границей.
> Особенно радует, что изменения в текущей ветке оказались утеряны.
Еще раз… Никакие изменения не теряются. Все что вы редактируете, мержите (проводите слияние веток) — эти операции выполняются в вашей рабочей копии проекта. В любой момент времени с помощью svn status, svn diff вы можете с точностью до замененного символа просмотреть, чем отличается ваша раб. копия от крайней HEAD или любой другой правки в хранилище.
Смысл слияния, вроде, прозрачен и понятен всем — например, объединить изменения кода, накопленные во временных ветках, разрабатываемых разными программистами в одну главную ветку, из которой будет собран релиз. Но почему-то, наткнувшись, на проблемы, подобные сабжу, забывается, что команда svn merge — это всего лишь инструмент, помогающий провести объединение кода из разных мест наиболее быстрым образом, поскольку эта команда старается отслеживать всю историю изменений в указанном для слияния диапазоне правок. Конечное слово перед коммитом остается за программистом.
Наивно предполагать, что коммит получится провести сразу после выполнения svn merge, скорее всего, часть файлов войдет в конфликтующее состояние, требующее обязательного «ручного» анализа с принятием/удалением/редактированием своих/чужих вариантов отдельных строк кода, которые в спорных случаях довольно удобным образом помечаются, плюс рядышком в рабочей копии merge подкладывает пару файликов .left, .right с содержимым, взятым из «левой» и «правой» сравниваемых версий соответственно.
Задача сводится к устранению конфликтов в нескольких файлах после merge или update, а не поиску и перепроверке всех измененных мест в проекте.
Автор статьи указал случай, за что ему огромное спасибо (взял на заметку), когда такого конфликта SVN не подсказывает, и теперь на переименования файлов в проекте буду обращать отдельное внимание.
К сожалению, не настолько силен, чтобы дописать какой-нибудь триггер на переименование файлов для отслеживания таких граблей, но статья определенно пошла на пользу.
Присмотритесь попристальней, поймете, что это благо.
P.S. А архивчики с бэкапами проекта вы наверное датами нумеруете?
Пример — последний босс в обеих частях Max Payne.
Скриншот «Возможность отображения информации на рабочем столе» www.diskwritecopy.com/rus/images/dwc_pro_sshot_2_big.gif весит непозволительно много. Забыли ресайзнуть?
Трафик экономлю (да такое еще бывает=), не ожидал, что за невыдающихся размеров иллюстрацией будет лежать 1280х1024рх…
+ — добавление функциональности;
-— удаление ненужных кусков;± — изменение с целью улучшения, исправления ошибки.
Не задумывался о том, что тема правильности ведения лога изменений будет вообще где-либо поднята/обнаружена мною, но тем приятнее совпадение мнений:
а) лог коммита — это не просто так, а очень даже может помочь;
б) писать в него надо словами, кратко «проговаривая» каждое изменение;
в) применение символических обозначений улучшает читабельность за счет сокращения количества повторяемых слов;
Совпадение мысли с другой статьей Искусство тратить минуты, экономя часы тоже нашло выражение =)
Для сокращения времени описания правки «потом» при коммите, сразу добавляю описание очередного изменения в файл-заготовку, как только модуль удачно скомпилировался. Добавил новую функцию — в коде откомментировал ее назначение, параметры, важные моменты в реализации, в заготовку лога коммита отписываю:
+ имя_функции(вербализованное, описание, параметров): чего возвращает.