[skipped]

Вообщем не по делу... но всем большое спасибо за обсуждение в этом топике. Больше часа потратил на прочтение и не разочаровался. Поулчил кучу информации к размышлению.

Да простят меня модераторы за offtopic

Здравствуйте, LeeMouse, Вы писали:

LM>Использую SVN в "нормальных" проектах уже 3-й год. До этого пользовался SSF ( фуфло ) и CVS ( тоже мрачно в сравнении с SVN ).
Рад за вас.

AC>>Ответ будет страниц на 20. Если вы не понимаете зачем нужна параллельная разработка, значит ваш проетк не дошел до нее. Значит и сознание не дошло.

LM> :)))
LM>Много болтовни когда толкут воду в ступе... Параллельная разработка не подразумевает редактирование одних и тех же СТРОК в исходниках. Все остальные случаи параллелизма SVN разруливает отлично.
Есть масса способов параллельной разработки. перчислю основные:
Линейный
Конкурирующий
Интеграционный
Один бренч на одну задачу
Бренч на релиз
Подпроектный
Мультикомандный
Компонентный
Платформенный
Приватный

Зачастую разные люди вносят изменения в одну и ту же строку (готов отдельно поговорить на тему один подрядчик — 100 заказчиков и для каждого свои докрутки доводки.. итд)

Если не секрет, вы можете рассказать в скольки проектах одновременно работаете и сколько у вас разработчиков (конкретики не надо — только порядок)



AC>>Я уже 5 лет занимаюсь тем, что перевожу "дозревшие" компании на более высокий уровень. Слава богу, что в полседние годы уже идут люди не CVS и сурсейва, а с PVCS, где тоже есть и сборка и праллельное ветвление....

LM>ГЫЫЫЫ :))) Спасибо, мы уж как-нить без таких "поднимателей" обойдемся, ОК ?

Нет не ОК!
Быть совершенно здоровым и чуствовать себя здоровым — ЭТО НЕ ОДНО И ТОЖЕ, уважаемый...
У нас просто разное видение. Я могу давать оценку, основываясь не на книжках, а на РЕАЛЬНОМ опыте внедрений не в один десяток компаний.
И работать приходилось с многими сурс системами и методлогиями...
Вам явно нужно расширить амбразуру собственного сознания. ОК?

AC>>У меня к вам вопрос:

LM>Хоть и не ко мне, отвечу :-)

AC>>Предствавим, что у вас была версия файла main.cpp... через какое то время нашли в старой версии ошибку. Еее нужно исправить. Напишите, как вы ее будете исправлять в SVN

LM>ЛЕГКО И НЕПРИНУЖДЕННО. Или Вам конкретные команды привести? Или что?? В ЧЁМ собственно заключается вопрос? Если почитаете-таки доку по SVN, ищите слова "branches" и "tags" — популярно всё обсказано на чистом аглицком :-)
Доку будут читать, когда будут смотреть SVN. Меня интересует даже не столько выполнение последовательности команд, сколько организация процесса у вас...
Можете написать соклько времени уходит на исправление бага в старой версии проекта? Знает ли об этом менеджер? Как это тестируется?


LM>Удачи в "поднимании" :))
Удачи в расширении кругозора и в этике общения :super:

Здравствуйте, PPA, Вы писали:

PPA>Здравствуйте, bkat, Вы писали:
Разрешите я встряну :)

LM>>>ЛЕГКО И НЕПРИНУЖДЕННО. Или Вам конкретные команды привести? Или что?? В ЧЁМ собственно заключается вопрос? Если почитаете-таки доку по SVN, ищите слова "branches" и "tags" — популярно всё обсказано на чистом аглицком :-)
У меня рацинализаторское предложение: давайт не будем друг друга отправлять к документации. Вполне возможно послушав друг друга договориться, а не говорить о разном...

B>>Плюс СС в том, что там уже ушли от прямого использования "branches" и "tags".
Прямого и не было. Увидеть дерево можно, а иногда и нужно. Только хорош тот проект, гдя для юзера все прозрачно (для ЮЗЕРА)

PPA>В SVN не уходили, там никогда небыло прямого использования веток и тэгов.
PPA>"branches" и "tags" это просто общепринятые названия каталогов в которые копируются срезы ствола разработки.
Можно рассказать подробнее? В ответ я могу рассказать как происходит формирование и продвижение базовых линий (базовых версий) в ClearCase.

B>>Это все скрыто.

PPA>В SVN все открыто. и большой вопрос что является плюсом.
Ладно, везде все открыто если уметь смотреть


B>>tags еще немного видно под соусом baseline

PPA>причем тут соус я не понял
PPA>но тэг он и в африке тэг — фиксация дерева исходников в определенном состоянии.
PPA>в SVN это делается командой copy в любое удобное место, которое потом не забудешь :)
расскажите

PPA>а вот как можно тег видеть _немного_ я :xz:

B>>ну а "бранчи"
B>>большинство и не видит в явном виде.

PPA>от того, что он видит это в неявном виде, суть контроля версий не меняется,
PPA>вероятно, в CC общедоступные понятия назвали другими словами.
:wow: это уже перебор.... Да везде оно названо одинаково. Ну если не везде, то почти везде

Здравствуйте, alex-consult, Вы писали:

AC>Здравствуйте, PPA, Вы писали:

B>>>Плюс СС в том, что там уже ушли от прямого использования "branches" и "tags".
AC>Прямого и не было. Увидеть дерево можно, а иногда и нужно. Только хорош тот проект, гдя для юзера все прозрачно (для ЮЗЕРА)

Контроль версий, предназнчен в первую очередь для программиста.
юзеры в моем понимании — это "тетя маша" которая путает enter c esc, и забывает иногда включать принтер

PPA>>В SVN не уходили, там никогда небыло прямого использования веток и тэгов.
PPA>>"branches" и "tags" это просто общепринятые названия каталогов в которые копируются срезы ствола разработки.
AC>Можно рассказать подробнее? В ответ я могу рассказать как происходит формирование и продвижение базовых линий (базовых версий) в ClearCase.

Репозиторий svn представляет собой просто версионную файловую систему. в которой после каждого комита фиксируется
ее новое состояние и увеличивыется номера ревизии у репозитория
в итоге по этому номеру и анализу лога можно вытянуть любое зафиксированое ранее состояние

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

в которые копировать по своему усмотрению любые состояния разработки

http://svnbook.red-bean.com/en/1.0/ch04s06.html

Выпустили версию 1.0 выполняете:

$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/tags/release-1.0 \
-m "Tagging the 1.0 release of the 'calc' project."

Committed revision 351.

Теперь в каталоге "/repos/calc/tags/release-1.0" находится срез "/repos/calc/tags/trunk"
если нужно достать "release-1.0" программист может это может сделать 2-мя путями:

svn checkout http://svn.example.com/repos/calc/tags/release-1.0

или

svn checkout -r351 http://svn.example.com/repos/calc/trunk


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

PPA>>причем тут соус я не понял
PPA>>но тэг он и в африке тэг — фиксация дерева исходников в определенном состоянии.
PPA>>в SVN это делается командой copy в любое удобное место, которое потом не забудешь
AC>расскажите

Выше рассказал.
А как это выглядит в СС ?

> PPA>в SVN это делается командой copy в любое удобное место, которое
> расскажите

PPA уже маленько рассказал, я хотел маленько дополнить, как строится новое дерево в репозитории.

Более точно это можно прочитать вот здесь http://subversion.tigris.org/files/documents/15/17/svn-design.html#Repository%20Structure я лишь дам небольшую выписку от туда (в собственной интерпретации)

Что храниться в реопзитории. В нем есть список правок (revisions), каждый элемент этого списка ссылается на корень (корневой узел каталог) дерева правки. Дерево состоит из узлов (node), узлы могут быть либо каталогами либо файлами. В узлах каталогов хранятся ссылки на дочерние узлы. В общем всё как в обычных деревьях. Теперь, что происходит при изменении в дереве, то есть при фиксации (commit) изменений.

Допустим у нас было вот такое дерево

       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |
          |
       ___|_____
      |D        |
      |         |
      |   A     |      /* два ссылки, `A' и `B'. */
      |    \    |
      |   B \   |
      |__/___\__|
        /     \
       |       \
       |        \
    ___|___   ___\____
   |D      | |D       |
   |       | |        |
   |       | | fish   |   /* одна ссылка, `fish'. */
   |_______| |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |  /* одна ссылка, `tuna'. */
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |   /* (содержимое файла tuna) */
                   |________|

файл tuna был изменён, происходит фиксация изменений. Вначале создаётся новый tuna узел содержащий последнюю модификацию tuna

                         ________
                        |F       |
                        |        |
                        |        |
                        |________|

Затем создаётся новый узел для родительского каталога файла tuna:

                 ________
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

Дальше делается то же самое:

              ________
             |D       |
             |        |
             | fish   |
             |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

Теперь мы дошли до директории которая ссылается не только на только что построенное поддерево (A/fish/tuna) но и на поддерево B которое в данной правке не изменялось. То есть наш новый узел (в данном случае это корневой узел) будет содержать ссылку на новое поддерево A, и сошлётся на узел B директории из предыдущей правки

       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |
          |
       ___|_____             ________
      |D        |           |D       |
      |         |           |        |
      |   A     |           |   A    |
      |    \    |           |    \   |
      |   B \   |           |   B \  |
      |__/___\__|           |__/___\_|
        /     \               /     \
       |    ___\_____________/       \
       |   /    \                     \
    ___|__/   ___\____              ___\____
   |D      | |D       |            |D       |
   |       | |        |            |        |
   |       | | fish   |            | fish   |
   |_______| |___\____|            |___\____|
                  \                     \
                   \                     \
                 ___\____              ___\____
                |D       |            |D       |
                |        |            |        |
                | tuna   |            | tuna   |
                |___\____|            |___\____|
                     \                     \
                      \                     \
                    ___\____              ___\____
                   |F       |            |F       |
                   |        |            |        |
                   |        |            |        |
                   |________|            |________|

Мы дошли до корня, новое дерево построено, в списке правок появляется новая запись с номером 2 которая ссылается на наше новое дерево

       ______________________________________________________
      |___1_______2________3________4________5_________6_____...
          |        \
          |         \__________
       ___|_____             __\_____
      |D        |           |D       |
      |         |           |        |
      |   A     |           |   A    |
      |    \    |           |    \   |
      |   B \   |           |   B \  |
      |__/___\__|           |__/___\_|
        /     \               /     \
       |    ___\_____________/       \
       |   /    \                     \
    ___|__/   ___\____              ___\____
   |D      | |D       |            |D       |
   |       | |        |            |        |
   |       | | fish   |            | fish   |
   |_______| |___\____|            |___\____|
                  \                     \
                   \                     \
                 ___\____              ___\____
                |D       |            |D       |
                |        |            |        |
                | tuna   |            | tuna   |
                |___\____|            |___\____|
                     \                     \
                      \                     \
                    ___\____              ___\____
                   |F       |            |F       |
                   |        |            |        |
                   |        |            |        |
                   |________|            |________|

Что происходит с репозиторием когда происходит копирование. Допустим есть вот такое дерево

       ______________________________________________________
    ...___6_______7________8________9________10_________11_____...
          |
          |
       ___|_____
      |D        |
      |         |
      |   A     |
      |    \    |
      |   B \   |
      |__/___\__|
        /     \
       |       \
       |        \
    ___|___   ___\____
   |D      | |D       |
   |       | |        |
   |       | | fish   |
   |_______| |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

копирую каталог A в T, получаю новое дерево такого вида

       ______________________________________________________
      |___6_______7________8________9________10_________11_____...
          |        \
          |         \
       ___|_____   __\______
      |D        | |D        |
      |         | |         |
      |   A     | |    A    |
      |    \    | |    |    |
      |   B \   | |  B |  T |
      |__/___\__| |_/__|__|_|
        /     \    /   |  |
       |    ___\__/   /  /
       |   /    \    /  /
    ___|__/   ___\__/_ /
   |D      | |D       |
   |       | |        |
   |       | | fish   |
   |_______| |___\____|
                  \
                   \
                 ___\____
                |D       |
                |        |
                | tuna   |
                |___\____|
                     \
                      \
                    ___\____
                   |F       |
                   |        |
                   |        |
                   |________|

Таким образом, если после 7мой правки, не будет вносить никаких изменений в /T, /T будет всегда ссылаться на содержимое /A 6той правки, то есть по сути дела /T это и есть tag для /A 6той правки. Если же в /T будут вноситься изменения они будут идти параллельно с /A то есть в этом случае /T будет выступать в роли ветки.

К версии 2.0, разработчики SVN планируют добавить полезные вещи для упрощения сливания ветвей. В настоящий момент есть команды diff и merge, но они не отслеживают например то, что в какой-то из правок уже были произведены сливания изменений из одной витки в другую, то есть эта задача кладётся на плечи пользователя SVN.

В документации в SVN указывается, что braches и tags в SVN реализованно посредством копий. Видно, что копирование всего проекта целиком, это всего лишь создание ещё одного узла.

> с записью в базе багов/запросов на изменение.
> Можно ли такое же проделатьс SVN?

Уже упоминался TortoiseSVN. Так вот, в нем это можно сделать. Для этого
заведены специальные property которые хранятся в репозитории, а TortoiseSVN их
специальным образом обрабатывает. Посмотри в документации к TortoiseSVN раздел

4.10. Integration with Bugtracking Systems / Issue trackers

А что б никто не забывал писать комментарии к commit'ам, в той же TortoiseSVN
есть property tsvn:minlogmsgsize

> PPA уже маленько рассказал, я хотел маленько дополнить, как строится новое дерево в репозитории.

Монстр!

Здравствуйте, Sashko, Вы писали:

S>К версии 2.0, разработчики SVN планируют добавить полезные вещи для упрощения сливания ветвей. В настоящий момент есть команды diff и merge, но они не отслеживают например то, что в какой-то из правок уже были произведены сливания изменений из одной витки в другую, то есть эта задача кладётся на плечи пользователя SVN.

А пока что можно пользоваться вот таким скриптиком: SvnMerge

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

AC>Рад за вас.

Я тоже

AC>Есть масса способов параллельной разработки. перчислю основные:
AC>Линейный
AC>Конкурирующий
AC>Интеграционный
AC>Один бренч на одну задачу
AC>Бренч на релиз
AC>Подпроектный
AC>Мультикомандный
AC>Компонентный
AC>Платформенный
AC>Приватный

Ну, я не теоретик — я таки практик... Перечисленные Вами термины и словосочетания как-то не впечатлили...
Я согласен с одним древним: "краткость — сестра таланта", и "добродетель в простоте". Т.е. чем проще — тем лучше.
В связи с чем процесс следует планировать с целью минимизации интерференции между разработчиками.
Причем деление должно ( ИМХО ) соответствовать уровням архитектуры — то есть сначало крупное разделение,
с небольшими интерфейсами между частями, каждая часть отдельной команде ( департаменту ), и далее вниз по уровням
архитектуры продукта. И всё будет шелковистым

AC>Зачастую разные люди вносят изменения в одну и ту же строку (готов отдельно поговорить на тему один подрядчик — 100 заказчиков и для каждого свои докрутки доводки.. итд)

Редактирование одной и тойже строки в одно и то же время — некомпетентность руководителя команды, ответственной за компонент,
в котором находится файли с этой злосчастной строчкой

AC>Если не секрет, вы можете рассказать в скольки проектах одновременно работаете и сколько у вас разработчиков (конкретики не надо — только порядок)

Сейчас в одном проекте ( стартап ), разрабатываем и поддерживаем продукты небольшими независимыми командами.

AC>>>Я уже 5 лет занимаюсь тем, что перевожу "дозревшие" компании на более высокий уровень. Слава богу, что в полседние годы уже идут люди не CVS и сурсейва, а с PVCS, где тоже есть и сборка и праллельное ветвление....

AC>Вам явно нужно расширить амбразуру собственного сознания. ОК?

Хммм.... Скорость и качество моей работы более чем удовлетворяет моего работодателя... От добра добра не ищут.

AC>Можете написать соклько времени уходит на исправление бага в старой версии проекта? Знает ли об этом менеджер? Как это тестируется?

Вопрос некорректный. Время исправления "бага" зависит от сложности работ, необходимых для его исправления.
Если Вы имеете в виду задержки из-за системы контроля версий — в случае SVN они нулевые

AC>Удачи в расширении кругозора и в этике общения

Взаимно

Здравствуйте, meridian, Вы писали:

K>>1) Советую все-таки прочитать GPL. Да, она неприемлима для большинства комерческих разработок, но совершенно по другой причине.
K>>2) Среди лицензий, принятых в opensource, есть вполне подходящие для закрытого проекта. Та же BSD License, к примеру.
K>>3) Microsoft, Sun, еще пачка компаний того же уровня -- несолидные компании? Ну извините.(с)
M>Извиняю, читайте предэд. посты, где писал, что не имеются ввиду впоследствии открытые коды

А я говорил про открытые впоследствии коды?! Где???

И прочтите GPL, я Вас умоляю. Дабы не смешить окружающих.

Здравствуйте, Yampolski_Nikita, Вы писали:

Y_N>Привет всем.

Y_N>Господа, интересует сабж. Т.е. что вы считаете наилучшим инструментом контроля версий ? Что вы используете ? Почему ? Интересует функциональность, мультиплатформенность, гибкость — такие вот параметры.

Y_N>Прошу высказаться.

Y_N>Спасибо заранее.

Слышал еще о такой системе, гибриг CVS и VSS, если я правильно понял..
Vault называется, Краткое описание

Интерестно, кто-то пользовался?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, meridian, Вы писали:

WH>Вы меня похоже не слышите. Я говорю что если делать по уму то необходимость в правке одного файла двумя людми вобще не должна возникать. А если необходимость таких действий вобще появляется и не важно что при этом надо делать мержить или просить освободить ресурс это в любом случае бардак и нужно серьезно задуматься над архитектурой.

Научи делать по уму, о гуру разработок.