Комментарии 27
большое спасибо. разжевано довольно подробно, осталось только съесть.
«согласно проектным политикам, пользователь назвал rec98_user1.» — по-моему тут речь идет уже о rec121_user1.
«согласно проектным политикам, пользователь назвал rec98_user1.» — по-моему тут речь идет уже о rec121_user1.
Хорошо написано ) как раз вся суть которую пытался выудить из сухой документации.
Вот тут то я и познал Дзен.
Вот тут то я и познал Дзен.
Можно вопрос?
"… Однако user2 узнает, что за время его работы была исправлена серьезная ошибка, на которую был заведен CR #121 ..."
Вопрос — как он узнает об этом? Раработчику надо постоянно следить за тем, что понакодили все другие разработчики? Рассматриваем случай, например, удаленной работы, когда прямого вербального общения за чашкой кофа между разработчиками нет.
"… Однако user2 узнает, что за время его работы была исправлена серьезная ошибка, на которую был заведен CR #121 ..."
Вопрос — как он узнает об этом? Раработчику надо постоянно следить за тем, что понакодили все другие разработчики? Рассматриваем случай, например, удаленной работы, когда прямого вербального общения за чашкой кофа между разработчиками нет.
Вопросы — нужно!
Отвечая на вопрос, как минимум, способа два:
1. Он столкнулся с ошибкой в поведении системы. Зашел в багтрекер проекта и сделал поиск по нужным словам. Находит запись. Запись находится в состоянии Resolved или Closed (см. предыдущую заметку цикла) — т.е. готово решение.
2. Он столкнулся с ошибкой. Повернулся к коллегам в комнате и громко спросил: «Что-то не пашет вот это хрень при таких вот параметрам входных… Фигле?» :)
В обоих вариантах он далее идет с систему контроля версий и с помощью СМ-политик отпределяет, какая конфигурация ему нужна. Ну и далее — по тексту.
Отвечая на вопрос, как минимум, способа два:
1. Он столкнулся с ошибкой в поведении системы. Зашел в багтрекер проекта и сделал поиск по нужным словам. Находит запись. Запись находится в состоянии Resolved или Closed (см. предыдущую заметку цикла) — т.е. готово решение.
2. Он столкнулся с ошибкой. Повернулся к коллегам в комнате и громко спросил: «Что-то не пашет вот это хрень при таких вот параметрам входных… Фигле?» :)
В обоих вариантах он далее идет с систему контроля версий и с помощью СМ-политик отпределяет, какая конфигурация ему нужна. Ну и далее — по тексту.
автору спасибо за цикл статей.
Подскажите пожалуйста грамотную и бесплатную систему контроля версий, если есть такие
Подскажите пожалуйста грамотную и бесплатную систему контроля версий, если есть такие
Совсем забыл вставить нужную ссылку, добавил её в заметку:
en.wikipedia.org/wiki/Comparison_of_revision_control_software — ольшой список сравнения существующих систем.
Я бы взял на твоём месте CVS, Subversion или Mercurial.
CVS — прост до невозможности и при этом функционален. Для небольших задач отличная вещь. Вот тут неплохое введение:
rsdn.ru/article/devtools/cvs.xml
Subversion — продолжение идеи CVS, делается выходцами из команды CVS. В последние несколько лет стабильно отбирает у него аудиторию. Соответственно, есть большое коммьюнити, не пропадешь. Для понимания принципов работы прочитай
svnbook.red-bean.com/
Mercurial (AKA Hg) имеет другую идеологию (он из распределенных систем контроля), но тоже неплох.
Попробуй эти и ещё что-нибудь вроде git, составь своё собственное мнение.
en.wikipedia.org/wiki/Comparison_of_revision_control_software — ольшой список сравнения существующих систем.
Я бы взял на твоём месте CVS, Subversion или Mercurial.
CVS — прост до невозможности и при этом функционален. Для небольших задач отличная вещь. Вот тут неплохое введение:
rsdn.ru/article/devtools/cvs.xml
Subversion — продолжение идеи CVS, делается выходцами из команды CVS. В последние несколько лет стабильно отбирает у него аудиторию. Соответственно, есть большое коммьюнити, не пропадешь. Для понимания принципов работы прочитай
svnbook.red-bean.com/
Mercurial (AKA Hg) имеет другую идеологию (он из распределенных систем контроля), но тоже неплох.
Попробуй эти и ещё что-нибудь вроде git, составь своё собственное мнение.
Большинство народу все же использует svn.
Из них так же большая часть использует tortoisesvn.
Есть грамотеи (как я) которые умеют делать только update/commit — потому что это просто благодаря клиенту.
Когда речь заходит о ветвлении — мозг вступает в ступор — по докам все вроде ясно — а вот на практике ничего не понятно.
Вчера потратил кучу времени на то чтобы попробывать создать ветку и затем слить её с основной линией разработки (пробывал методом тыка, особо не понимая что делаю).
Вот собственно что я хотел бы спросить:
Видел ли ктонибуть статью с скринами и картинками которая показывала бы как на практике в tartoisesvn клиенте работать с ветками?
Из них так же большая часть использует tortoisesvn.
Есть грамотеи (как я) которые умеют делать только update/commit — потому что это просто благодаря клиенту.
Когда речь заходит о ветвлении — мозг вступает в ступор — по докам все вроде ясно — а вот на практике ничего не понятно.
Вчера потратил кучу времени на то чтобы попробывать создать ветку и затем слить её с основной линией разработки (пробывал методом тыка, особо не понимая что делаю).
Вот собственно что я хотел бы спросить:
Видел ли ктонибуть статью с скринами и картинками которая показывала бы как на практике в tartoisesvn клиенте работать с ветками?
Лично я навскидку не скажу. Мжет кто их апологетов подскажет…
Возможно, придётся писать отдельную заметку :)
Но то, что ветки в тортойзе просто так не сольёшь вместе — не повод отказываться от веток вообще. Проще перети на что-то более дружественное. К примеру, не так давно пролетала заметка про работу git совметно с svn — думаю, тебе есть смысл попробовать.
Возможно, придётся писать отдельную заметку :)
Но то, что ветки в тортойзе просто так не сольёшь вместе — не повод отказываться от веток вообще. Проще перети на что-то более дружественное. К примеру, не так давно пролетала заметка про работу git совметно с svn — думаю, тебе есть смысл попробовать.
byte.ho.com.ua/svn/branches.html
Делал примитивную инструкцию «для внутреннего пользования». Правда пока только по созданию веток. Скоро буду делать merge — может накропаю и по нему инструкцию.
Делал примитивную инструкцию «для внутреннего пользования». Правда пока только по созданию веток. Скоро буду делать merge — может накропаю и по нему инструкцию.
А вот скажите как в cvs в легкую перенести файл из одного пути в другой с сохранением истории версий. Пока делаем это шаманским способом через манипуляцию с файлами itemname,v в репозитории. Или пора пойти в ногу с прогрессом и ставить svn, git...etc???
Собсно, я ведь и написал, что CVS — простая система :) Да, перемещения файлов с историей там нет. Также, как нет атомарных коммитов.
Однако для большого числа проектов и команд эти фичи — скажу страшное — не нужны.
А насчет прогресса — распределенные системы, по сравнению с централизованными репозитариями, имеют свои недостатки, так что я бы не стал однозначно называть это прогрессом. Скорее, ответвление в развитии. Кстати, следующая заметка будет как раз про них.
Однако для большого числа проектов и команд эти фичи — скажу страшное — не нужны.
А насчет прогресса — распределенные системы, по сравнению с централизованными репозитариями, имеют свои недостатки, так что я бы не стал однозначно называть это прогрессом. Скорее, ответвление в развитии. Кстати, следующая заметка будет как раз про них.
И еще вопросец ;) представим был у нас BuzinessLogicForSuperBuzinessActionCodeFile.cs был он вначале меленьким маленьким с парой классов в 200 строк, все четко по ТЗ;) а потом бац через пол года обнаруживается, что он уже 5000 строк и растет прям как бамбук в шри ланке;) После первого этапа рефакторинга он превращается в 20 новых файлов (на 90% просто разбивка классов по разным файлам). Так вот как бы это все оформить в системе контроле версий, чтобы можно было проследить изменения в конкретной функцию от начала ее появления в BuzinessLogicForSuperBuzinessActionCodeFile.cs до перехода ее в отдельный файл.
Случайно набрел на этот топик. Можно запоздалый вопрос?
Почему изменения 130 и 131 идут через интеграционную ветку, а 121 и 98 напрямую в релизную?
Почему изменения 130 и 131 идут через интеграционную ветку, а 121 и 98 напрямую в релизную?
Конечно.
Ветки для обоих изменений были отращены от старой версии — 3. А к моменту интеграции появилась свежая версия. И теперь их надо не только «проапмёржить» обе ветки на релизную ветку (т.е. слить изменения с последними доступными), но и слить их между собой. Поэтому вводится промежуточный шаг — ветка, отрощенная от последней версии на релизной ветке (таким образом будет решена проблема апмёржа). И на этой ветке всё сливается в одно целое (мёрж изменений между собой). И с промежуточного шага (версия 2 на интеграционной ветке) делается переход снова на релизную ветку.
Можно и без него — сначала отрастить ветку для изменения 130 и слить туда изменения, чтобы слить их с релизной веткой. А потом то же самое — для 131. Но это было бы более громоздко. Если учесть, что таких параллельных изменений может быть с десяток одновременно — введение интеграционных веток становится необходимым.
Ветки для обоих изменений были отращены от старой версии — 3. А к моменту интеграции появилась свежая версия. И теперь их надо не только «проапмёржить» обе ветки на релизную ветку (т.е. слить изменения с последними доступными), но и слить их между собой. Поэтому вводится промежуточный шаг — ветка, отрощенная от последней версии на релизной ветке (таким образом будет решена проблема апмёржа). И на этой ветке всё сливается в одно целое (мёрж изменений между собой). И с промежуточного шага (версия 2 на интеграционной ветке) делается переход снова на релизную ветку.
Можно и без него — сначала отрастить ветку для изменения 130 и слить туда изменения, чтобы слить их с релизной веткой. А потом то же самое — для 131. Но это было бы более громоздко. Если учесть, что таких параллельных изменений может быть с десяток одновременно — введение интеграционных веток становится необходимым.
Спасибо, разница получается довольно субъективная и не четкая, но суть понял :)
Внешне разница в том, сколько версий будет на стабильной релизной ветке. В описаном мной случае получается 1 версия на релтизной ветке — т.е. 1 релиз = 1 версия. Если для каждого изменения заводить по версии — получится бардак. Релизная ветка ведь содержит только те версии, которые готовы к выпуску/отгрузке/основы для работы. Так что промежуточные ингтеграционные ветки как раз служат для складирования версий, не предназначенных для широкой публики.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Software Configuration Management // Контроль версий