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

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From Russian to

Threaded View
Здравствуйте
Есть прибор - пусть будет СКД18.
Пару лет выпускалась - версия v00_00 (как у нас принято обзывать)
Затем нашли ошибки в ПО - появилась версия v00_01
И вот произведена модификация платы - соответсвенно версия v01_00
Hажаль, кое-какое используемое ПО требует абсолютных, а не относительных
путей - поэтому ветка v01 хранится в том же месте, что и v00, а
модификации в прошивках могут быть как в ветке v00, так и в v01,
соответсвенно имеется гемморой по переписыванию из архива в директорию
той ветки, какую собираешься редактировать (ну и изменения в общей части
проекта - если ошибка/модификация общая).
Сейчас проект хранится в e:\projekt\SKD18, а архивы, которые потом из
этого же места пишутся на диск, - в e:\projekt\SKD18\disk\v00_00,
e:\projekt\SKD18\disk\v00_01 и e:\projekt\SKD18\disk\v01_00.
Вводят на предприятии SVN -  и вот не понятно как лучше сделать, чтоб
меньше переделывать.
Target - выходит e:\projekt\SKD18\
Release - e:\projekt\SKD18\disk\
А как быть с Tags?
Создать в репозитарии e:\projekt\SKD18\versii (можно и Tags написать, но
я сам из-за редкого использования путаюсь, а те кто постарше - вообще не
удобно; если, конечно, из-за того, что вместо Tags будет versii - будут
роблемы, то придётся обозвать Tags) - и там хранить? А как загружать
полседнюю версию выбранной ветки и делать, чтоб общие модификации один
раз правились? Документацию читал, но чего-то элементарного я не понимаю.
Или есть другие варианты?
-----
С уважением, Шаповалов Алексей


Re: модификации изделия и 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 для вненсения измений в другие ветки или ствол. Глава
4. Copying Changes Between Branches.

WBR,
        AVB



Re: модификации изделия и SVN
Здравствуйте
Alexey V Bugrov пишет:
Сразу скажу - СПАСИБО!
:)
Quoted text here. Click to load it
Вот в нижнем твоём абзаце все слова понятны, но смысл утекал (как и в
документации), хорошо, что я до конца письмо дочитал - теперь могу
ответить :)
Quoted text here. Click to load it
Да
Quoted text here. Click to load it
Ясно
Quoted text here. Click to load it
Её, только русскую, немного утаревшую. С английским, после облома с
документацией на АВР32 этой зимой - пока не решаюсь
Quoted text here. Click to load it
Вот сдесь я и сбойнул - с подачи того, кто эту систему начинал у нас
первым, я упёрто считал, что так же должно быть и локально - и начинал
делать.
Quoted text here. Click to load it
Сделано
Quoted text here. Click to load it
Hа эти грабли я тоже наступил, но дошёл сам, что копировать локально -
глупая идея
Quoted text here. Click to load it
Ага, в моём случае перехожу в папку e:\projekt\SKD18\disk\
и делаю cvs checkout svn://svn.yuorserver.ua/SKD18/tags/ - получаю в
папке e:\projekt\SKD18\disk\ все релизы, чтобы их накатать на диск для
наладки? (Дикость, но у наладчиков с нами связь только через
компактдиски - инета у них нет и локалки у нас разные).
Quoted text here. Click to load it
Ясно
Quoted text here. Click to load it
То есть в папке 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   ?
Если да, то это то, что хотелось

Quoted text here. Click to load it
Ясно
Спасибо.
-----
С уважением, Шаповалов Алексей


Re: модификации изделия и SVN
Hello, Shapovalov!
You wrote to Alexey V Bugrov on Mon, 17 Aug 2009 21:23:02 +0000 (UTC):

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

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

 >  SAI>> Tags будет versii - будут роблемы, то придётся обозвать Tags) - и
 >  SAI>> там хранить? А как загружать полседнюю версию выбранной ветки и
 >  SAI>> делать, чтоб общие модификации один раз правились? Документацию
 >  SAI>> читал, но чего-то элементарного я не понимаю.
 >>
 >> Какую? svn-book.pdf доступна на сайте. Желательно прочитать ее в
 >> оригинале.
 SAI> Её, только русскую, немного утаревшую. С английским, после облома с
 SAI> документацией на АВР32 этой зимой - пока не решаюсь

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

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

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

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

Да.

 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 скопировать
изменения в ствол. Особенность этой комманды в том, что она копирует в ствол
только изменения возникшие между двумя указанными ревизиями (следовательно
все прочие изменения в ствол не попадут).

 >> Если есть изменения общие для ствола и веток, то делаем их в любой из
 >> копий. Потом делаем svn merge для вненсения измений в другие ветки или
 >> ствол. Глава 4. Copying Changes Between Branches.
 SAI> Ясно
 SAI> Спасибо.


WBR,
        AVB



Re: модификации изделия и SVN
Здравствуйте
Alexey V Bugrov пишет:
Quoted text here. Click to load it
[skip]
Quoted text here. Click to load it
Вот это - что и хотелось, спасибо
[skip]
Quoted text here. Click to load it
Ясно
Quoted text here. Click to load it
Ясно
Quoted text here. Click to load it
Ясно
-----
С уважением, Шаповалов Алексей


Re: модификации изделия и SVN
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 файлы и всё править. Ибо конфликты
автомагически оно не всегда может разрешить.


модификации изделия и SVN
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 (наиболее активно развивающаяся ветвь) проекта, конкретного:

  https://server.name/svn/project_name/trunk/main.c

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

  https://server.name/svn/project_name/branches/v00_00/main.c и т.п.

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

  https://server.name/svn/project_name/tags/v536/main.c ...

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

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

[ZX]


модификации изделия и SVN
Mon Aug 17 2009 05:01, Shapovalov Alexey Ivanovich wrote to All:

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

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

[ZX]


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

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

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

Quoted text here. Click to load it
Как всегда - есть и третий - в Trunk версия под текущее выпускаемое (и
подвергаемое всем текущим испытаниям) железо. А в бранчах - лишь то, что
когда-то выпускалось и будет исправляться только при [наших] ошибках
Quoted text here. Click to load it
Угу. учту. Hо чисто софтового проекта у нас нет.
-----
С уважением, Шаповалов Алексей


Site Timeline