модификации изделия и SVN

Hello, Shapovalov! You wrote on Mon, 17 Aug 2009 00:01:33 +0000 (UTC):

SAI> Пару лет выпускалась - версия v00_00 (как у нас принято обзывать) SAI> Затем нашли ошибки в ПО - появилась версия v00_01 SAI> И вот произведена модификация платы - соответсвенно версия v01_00 SAI> Hажаль, кое-какое используемое ПО требует абсолютных, а не SAI> относительных путей - поэтому ветка v01 хранится в том же месте, что и SAI> v00, а модификации в прошивках могут быть как в ветке v00, так и в SAI> v01, соответсвенно имеется гемморой по переписыванию из архива в SAI> директорию той ветки, какую собираешься редактировать (ну и изменения SAI> в общей части проекта - если ошибка/модификация общая). SAI> Сейчас проект хранится в e:\projekt\SKD18, а архивы, которые потом из SAI> этого же места пишутся на диск, - в e:\projekt\SKD18\disk\v00_00, SAI> e:\projekt\SKD18\disk\v00_01 и e:\projekt\SKD18\disk\v01_00. SAI> Вводят на предприятии SVN - и вот не понятно как лучше сделать, чтоб SAI> меньше переделывать. SAI> Target - выходит e:\projekt\SKD18\ SAI> Release - e:\projekt\SKD18\disk\

Стоп. Как я понимаю речь идет о рабочих копиях? Содержимое репозитория никак не свзяано с тем, где и как хранятся рабочие копии. Их может быть сколько угодно в любых каталогах.

SAI> А как быть с Tags?

Таги сущетсвуют только в репозитории. Это маркер состояния проекта в опредленной стадии развития.

SAI> Создать в репозитарии e:\projekt\SKD18\versii (можно и Tags написать, SAI> но я сам из-за редкого использования путаюсь, а те кто постарше - SAI> вообще не удобно; если, конечно, из-за того, что вместо Tags будет SAI> versii - будут роблемы, то придётся обозвать Tags) - и там хранить? А SAI> как загружать полседнюю версию выбранной ветки и делать, чтоб общие SAI> модификации один раз правились? Документацию читал, но чего-то SAI> элементарного я не понимаю.

Какую? svn-book.pdf доступна на сайте. Желательно прочитать ее в оригинале.

SAI> Или есть другие варианты?

Во-первых: определяемся с терминоологией.

Пусть создан репозиторий svn://svn.yuorserver.ua/SKD18 - это то место, где хранится проект на сервере со всеми ветками и тагами. Репозиторий создается коммандой svnadmin create на сервере и существует только там.

Принято (не обязательно, но настоятельно рекомендуется) в репозитории создавать три подкаталога:

tags branches trunk

Как они создаются - Глава 5. Repository administration. Adding projects.

В trunk хронится основной "ствол" проекта, в него вносятся изменения по мере развития проекта. В tags складываются "релизные" копии проекта, на самом деле можно считать, что там хранится просто символическая метка, которая указывает на состояние проекта в основной момент времени. В branches хранятся и развиваются "ветки". Они как раз нужны для поддержки старого оборудования.

Все существующие данные изначально импортируются в "ствол". После этого обязательно надо создать рабочию копию, т.е. сделать svn checkout svn://svn.yuorserver.ua/SKD18/trunk. Это команда создаст на локальной машине рабочую копию проекта. Мы работаем только с ней, т.е. все правки вносим только в нее. При необходисмости делаем svn commit (отсылка изменений на сервер). Если над проектом работает несколько человек у кождого должна быть своя рабочая копия, созданная svn checkout. Все изменения в проекте синхронизируются у разных людей только средствами svn (update, commit).

Теперь представим, что проект достиг релизного статуса. Мы создаем таг (Глава 4. Branching and merging. Tags), дапустим rev00_00. для этого даем комманду:

svn copy svn://svn.yuorserver.ua/SKD18/trunk svn://svn.yuorserver.ua/SKD18/tags/rev00_00 -m"Создана ревизия 00_00"

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

cvs checkout svn://svn.yuorserver.ua/SKD18/tags/rev00_00 - получили копию проекта в состоянии ревизии 00_00

Дальнейшую работу над проектом продолжаем только в "стволовой" рабочей копии. tags нужно использовать только для сохранения снапшотов.

Теперь представим, что мы уже создали несколько ревизий (тагов) и хотим от какой-то предыдущей ревизии отпочковать ветку для поддержки старого оборудования:

Для этого создаем в branches копию нужной нам ревизии (или ствола, если нужно почковать от текущего состояния) (раздел Creating a Branch). Создается точно так же коммандой copy. Чтобы теперь работать с кодом ветки нужно сделать checkout новой рабочей копии (допустим ветку мы создали тут svn://svn.yuorserver.ua/SKD18/branches/old_device). Все изменения в код для старого девайса делаем только в рабочей копии данной ветки.

Если есть изменения общие для ствола и веток, то делаем их в любой из копий. Потом делаем svn merge для вненсения измений в другие ветки или ствол. Глава

1. Copying Changes Between Branches.

WBR, AVB

Здравствуйте Alexey V Bugrov пишет: Сразу скажу - СПАСИБО! :)

Вот в нижнем твоём абзаце все слова понятны, но смысл утекал (как и в документации), хорошо, что я до конца письмо дочитал - теперь могу ответить :)

Да

Ясно

Её, только русскую, немного утаревшую. С английским, после облома с документацией на АВР32 этой зимой - пока не решаюсь

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

Сделано

Hа эти грабли я тоже наступил, но дошёл сам, что копировать локально - глупая идея

Ага, в моём случае перехожу в папку e:\projekt\SKD18\disk\ и делаю cvs checkout svn://svn.yuorserver.ua/SKD18/tags/ - получаю в папке e:\projekt\SKD18\disk\ все релизы, чтобы их накатать на диск для наладки? (Дикость, но у наладчиков с нами связь только через компактдиски - инета у них нет и локалки у нас разные).

Ясно

То есть в папке e:\projekt\SKD18\ делаем команду cvs checkout svn://svn.yuorserver.ua/SKD18/branches/old_device - и работаем с версией для старых плат, затем сохраняем: svn commit svn://svn.yuorserver.ua/SKD18/branches/old_device И переходим к версии для новой платы cvs checkout svn://svn.yuorserver.ua/SKD18/trunk ? Если да, то это то, что хотелось

Ясно Спасибо.

----- С уважением, Шаповалов Алексей

Hello, Shapovalov! You wrote to Alexey V Bugrov on Mon, 17 Aug 2009 21:23:02 +0000 (UTC):

SAI> Вот в нижнем твоём абзаце все слова понятны, но смысл утекал (как и в SAI> документации), хорошо, что я до конца письмо дочитал - теперь могу SAI> ответить :) >> Стоп. Как я понимаю речь идет о рабочих копиях? Содержимое репозитория >> никак SAI> Да >> не свзяано с тем, где и как хранятся рабочие копии. Их может быть >> сколько угодно в любых каталогах. SAI> Ясно

Более того, если у вас проект жестко привязан к локальным путям (т.е. не скомпилируется, если сделать чекаут в другой каталог), то можно разные релизы чекаутить в один и тот же каталог, предварительно удалив рабочую копию другой ветки/релиза (не забыв прикоммитить в ней изменения).

Hу русский перевод не читал, осуждать не буду.

Да, получишь папку e:\projekt\SKD18\disk\tags\ внутри которой будут копии проекта для каждого из тагов (версий).

Да.

SAI> затем сохраняем: svn commit SAI> svn://svn.yuorserver.ua/SKD18/branches/old_device

Почти. Просто делаем svn commit, находясь в рабочей копии (в самом верхнем ее каталоге).

SAI> И переходим к версии для новой платы SAI> cvs checkout svn://svn.yuorserver.ua/SKD18/trunk ? SAI> Если да, то это то, что хотелось

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

Если же нам надо теже изменения, что мы сделали в ветке перенести в ствол, то после коммита ветки нужно с помощью комманды svn merge скопировать изменения в ствол. Особенность этой комманды в том, что она копирует в ствол только изменения возникшие между двумя указанными ревизиями (следовательно все прочие изменения в ствол не попадут).

WBR, AVB

Здравствуйте Alexey V Bugrov пишет:

Вот это - что и хотелось, спасибо [skip]

Ясно

----- С уважением, Шаповалов Алексей

Mon Aug 17 2009 05:01, Shapovalov Alexey Ivanovich wrote to All:

SAI> Пару лет выпускалась - версия v00_00 (как у нас принято обзывать) SAI> Затем нашли ошибки в ПО - появилась версия v00_01 SAI> И вот произведена модификация платы - соответсвенно версия v01_00

SAI> Hажаль, кое-какое используемое ПО требует абсолютных, а не относительных SAI> путей - поэтому ветка v01 хранится в том же месте, что и v00, а

help subst пробовал?

SAI> модификации в прошивках могут быть как в ветке v00, так и в v01, SAI> соответсвенно имеется гемморой по переписыванию из архива в директорию SAI> той ветки, какую собираешься редактировать (ну и изменения в общей части SAI> проекта - если ошибка/модификация общая).

А ещё net use /?

SAI> Вводят на предприятии SVN - и вот не понятно как лучше сделать, чтоб SAI> меньше переделывать. SAI> Target - выходит e:\projekt\SKD18\ SAI> Release - e:\projekt\SKD18\disk\ SAI> А как быть с Tags? SAI> Создать в репозитарии e:\projekt\SKD18\versii (можно и Tags написать, но SAI> я сам из-за редкого использования путаюсь, а те кто постарше - вообще не

Мне почему-то кажется, от введения SVN лучше отказаться... Hе потому, что SVN говно и поделка финских студентов, а потому, что с SourceSafe будет ещё хуже.

Я же из сказанного ниасилил ничего.

SAI> роблемы, то придётся обозвать Tags) - и там хранить? А как загружать SAI> полседнюю версию выбранной ветки и делать, чтоб общие модификации один

svn co -r HEAD path ?

SAI> раз правились? Документацию читал, но чего-то элементарного я не SAI> понимаю. SAI> Или есть другие варианты?

Hу можно попробовать ещё почитать документацию.

Если вкратце -- разные версии, если они дальше развиваются -- в разные бранчи. Всё отдаваемое на программирование/производство помечается тегом, пофиг каким. Структура, предположим, что в каждом репозитории по несколько разных проектов, а не один (сильно разные проекты, таки в разных репозиториях):

Trunk (наиболее активно развивающаяся ветвь) проекта, конкретного:

Разные "версии" (для разного железа):

и т.п.

Отданное в производство отмечается как:

...

В принципе тэги нужны не очень, достаточно в самой программе искуственно, в

*.hex внести номер ревизии, чтоб прибор мог его показать, внести в документацию и тэги становятся мало необходимыми. Hо если "нумерация версий", имеется ввиду версий софта, а не для разных модификаций приборов (там стоит говорить не о версиях, а об "вариантах"), не совпадает с номерами ревизий -- удобны тэги, с именами соответствующими версиями. Так обычно делается, но я считаю, удобнее использовать номера ревизий, а про 1.0, 1.1 и т.п. забыть. Хотя конечно со стороны какая-нибудь 631 версия смотрится страшновато.

Ещё что. Обрати внимание -- https. Понятно, ставится апач, dav_svn и всё как везде описывается. Сертификат можно раздать сотрудникам, самоподписанный, потому как покупать $300/год где-то (SSL). Там же можно и Trac и т.п. вещи, на вебсервере. Против голого http и svn:// -- предостерегаю. В первом случае security хромает, во-втором хромает всё, авторизация не через апач, трудности технического плана при большом числе коннектов. Вроде всё сказал.

[ZX]

Mon Aug 17 2009 05:01, Shapovalov Alexey Ivanovich wrote to All:

SAI> Вводят на предприятии SVN - и вот не понятно как лучше сделать, чтоб Да, ещё хотел сказать. Есть два подхода, что держать в Trunk. Либо разработка в бранчах и более стабильная версия в Trunk, либо разработка в Trunk и уход стабильных версий в бранчи (где на них только важные патчи накладываются).

Я считаю, первый вариант более рационален, тем, что позволяет вести параллельно работы в разных направлениях, а второй вариант тут ограничивает одним главным направленем (иначе конфликты в коммите). Поэтому в trunk, считаю, надо держать если не стабильную (она всё-таки в branch, как во втором варианте) версию, то последнюю работающую, всегда собирающуюся. А для экспериментов -- бранчи (как и для совсем стабильных версий).

[ZX]

Tue Aug 18 2009 03:01, Alexey V Bugrov wrote to Shapovalov Alexey Ivanovich:

AVB> Более того, если у вас проект жестко привязан к локальным путям (т.е. не AVB> скомпилируется, если сделать чекаут в другой каталог), то можно разные AVB> релизы чекаутить в один и тот же каталог, предварительно удалив рабочую AVB> копию другой ветки/релиза (не забыв прикоммитить в ней изменения).

Можно делать каждый раз subst, можно net use /persist. Я предпочитаю последний вариант, потому как он остаётся после перезагрузки. Я про винды.

SAI>> Ага, в моём случае перехожу в папку e:\projekt\SKD18\disk\ SAI>> и делаю cvs checkout svn://svn.yuorserver.ua/SKD18/tags/ - получаю в SAI>> папке e:\projekt\SKD18\disk\ все релизы, чтобы их накатать на диск для SAI>> наладки? (Дикость, но у наладчиков с нами связь только через SAI>> компактдиски - инета у них нет и локалки у нас разные).

AVB> Да, получишь папку e:\projekt\SKD18\disk\tags\ внутри которой будут AVB> копии проекта для каждого из тагов (версий).

Он видимо хотел иметь ввиду svn co svn://blablabla DESTINATION_PATH. Ключевое слово -- последнее.

SAI>> затем сохраняем: svn commit SAI>> svn://svn.yuorserver.ua/SKD18/branches/old_device AVB> Почти. Просто делаем svn commit, находясь в рабочей копии (в самом AVB> верхнем ее каталоге).

Hееет. Вначале долго и вдумчиво изучаем svn diff (и svn status). Потом пишем файл комментария по всем комментариям, и только потом делаем commit с этим файлом. Это чтоб потом в визуальном редакторе svn annotate видеть.

Только здесь ещё вопрос, опять же существует два варианта работы: миллион мелких коммитов на файлик-два-три, или один крупный на всё. Я склоняюсь к первому варианту, но он несколько плох, что в trunk в промежутках оказывается несобирающаяся принципиально версия. Почему склоняюсь -- комментировать надо чтоб понятно потом было.

AVB> Если же нам надо теже изменения, что мы сделали в ветке перенести в AVB> ствол, то после коммита ветки нужно с помощью комманды svn merge AVB> скопировать изменения в ствол.

После чего пол-дня изучать *.rej файлы и всё править. Ибо конфликты автомагически оно не всегда может разрешить.

Здравствуйте, Kirill Frolov Hа все три письма Спасибо, в чём я запутался, благодаря Alexey V Bugrov, я разобрался. Subst используется, но там (не в этом проекте, в других) такая каша, что ещй на нём и версии организовывать - ну нах. За год у нас осталась меньше половины разработчиков, ни одного для программ на ПК, некоторые проекты поменяли по паре разработчиков (в текущем разработчик уволился и уехал за 2 дня) - так что сейчас я наооборот, по возможности избавляюсь от софта, требующего абсолютные пути.

Угу, к этому и ползём потихоньку. Hо у нас в лучшие времена было 63 компа, половина из них точно к свн не полезет (физически), на остольной на половине безграммотные юзвери, коим тоже свн не нужон - 20 коннектов

- это много? И как с security при использовании svn:// ?

Как всегда - есть и третий - в Trunk версия под текущее выпускаемое (и подвергаемое всем текущим испытаниям) железо. А в бранчах - лишь то, что когда-то выпускалось и будет исправляться только при [наших] ошибках

Угу. учту. Hо чисто софтового проекта у нас нет.

----- С уважением, Шаповалов Алексей