Блин, опять я что-ли всех запутал?

В общем насчет externals, и моей идеи.
Все проекты находятся в одном репозитарии на сервере. У каждого проекта есть свой trunk и тэги.
Я хочу опять же в репозитарии, но не привязываясь к конкретному проекту, создать папочку all_models, и в ее свойствах прописать externals к нужным папкам из разных проектов.
Затем ссылку на папку all_models я даю заинтересованным пользователям и они делают чекаут на свои локальные компы. Если я добавляю новый проект, то мне достаточно на сервере изменить свойства папки один раз и пользователи, сделав апдейт, получат себе новые файлы. Таким образом пользователям не нужно заморачиваться со свойствами.

ПС. Ессно то же самое я могу сделать, сделав чекаут папки all_models, изменив ее свойства в рабочей копии и сделав коммит.

Так понятно? Или я что-то делаю не так?

Без разницы, где вы эту папку создадите - на сервере или в РК. На сервере - это надо лезть repo browser, и каждая ошибка фиксируется, в общем, не очень штатно и не удобно. Штатный способ - в РК. После коммита эта папка окажется в репе.

Все действия сводятся к:

1. Создать папку.
2. Создать у этой папки свойства (property) типа svn:externals, у каждого свойства указать пару <название папки> <путь до папки в репе>. Сделать svn commit.
3. При необходимости изменить список этих папок нужно просто добавить/удалить/изменить свойства папки с externals.

Пользователям ничего, кроме checkout и update делать не надо, про свойства им тоже даже знать не надо.

И опять запутали.
На сервере (т.е. локально сидя у этого физического сервера или через TeamViewer) 'папочку' можно сделать только в уже готовом репозитарии. Либо делать новый репозитарий. Т.е. отдельно стоящую 'папочку' не сделать.
Если на самом физическом сервере залезть в директорию где он хранит данные, то не увидите никаких привычных 'папочек'.
Визуальная оболочка VisualSVN тоже особых инструментов не предлагает.

Т.е. все что можно делать если не использовать скрипты, то только конфигурировать полученные после операции checkout директории на компьютере одного из клиентов.
Хотя конечно клиент (TurtioseSVN) может быть и на самом компьютере сервера.
Я так и делаю кстати.
Поскольку SVN невыносимо медленно работает даже на 2 Mbit линиях, я просто на флешке переношу на сервер импортируемые проекты.
Импортирую их там в репозитарий сервера (это будет localhost), там же делаю checkout с сервера обратно в новую локальную директорию на том же физическом компьютере и снова на флешке полученную директорию отношу на рабочий комп.
Там уже ей с помощью меню TurtoiseSVN делаю relocation. Т.е. меняю путь от директории к репозиторию с локального на удаленный домен.

Вот такая дискотека. Все ради науки.

Я имел ввиду через Repo Browser в TortoiseSVN - тогда не надо возле сервера сидеть.


Вы пробовали wordoвский документ открывать на такой линии? Вот это дискач. А от SVN на медленных линиях я тащусь - закончил работу, с чувством глубокого удовлетворения запустил коммит и пошел чай пить/кушать/спать в зависимости от размера. И никаких беспокойств.

Ну да нагружаем SVN чем угодно, только не контролем собственно версий.

А применить стандартный backup по idle не судьба была?
Когда я был озабочен долговечными резервными копиями у меня на стриммер сливалось каждый раз когда я от стола на 5 мин отходил. Даже забывал о существовании бэкапа.

Тогда наверное про SVN еще не знали?

Зачем заморачиваться с backup по idle, если бекапы репозитария настроены на сервере вместе со всеми другими вещами? Зачем мне изучать и настраивать еще один софт, притом на каждом рабочем месте, или если я снесу винду на компе?


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

Потому что в частности SVN не использует сжатие.
Да он пересылает только патчи, но зато каждую рабочую директорию захламляет тучей вспомогательных файлов своей базы данных.
А это и фрагментация диска, и замедление работы антивирусов, и замедление поиска по файлам, и риск получить сбой если какой либо из этих файлов базы данных повредится.
Потом оно конечно пересылаете в свое свободное время, но качать обратно то другим придется в свое рабочее время.
Вообщем SVN явно негодный инструмент и для резервного копирования.




SVN делали для проектов Open Sourse. А не для индивидуалов или производственных фирм.
Open Source это годами ковыряние в текстовых файлах и переливание из пустого в порожнее.
Такие виды деятельности как создание PCB, конструирование, исследования, испытания их никогда не волновали и не волнуют. SVN к ним никак не приспособлен.

Вы сейчас будете внедрять уже устаревшую VCS на фоне новых, распределенных VCS, вроде Git, Mercurial, Bazaar и т.д.
Рекомендую Mercurial.
Меркуриал позволяет все то, что SVN и Git, только удобнее и проще (чем Git, для которого написали аж целую книгу ProGit.).
Простота установки для пользователя - один установщик (TortoiseHG) - и стоит сама VCS и визуальный клиент. Для Git (под Windows ) такого не нашел. Одна сплошная боль.
По преимуществам распределенных VCS хипстеры накатали уже не одну статью, все преимущества там озвучены:
Сравнение Subversion и Mercurial (HG)
Переход на DVCS, Mercurial
Переезд с SVN на Mercurial: личный опыт

Ну и серия статей от одного довольно известного программиста:
Hg Init: Часть 1. Переобучение для пользователей Subversion

Все свои проекты держу на bitbucket.org. Очень удобно, не нужно ничего таскать на флешке.


0. Настройтесь на многократное повторение одного и того же.
1. Должна пойти команда от начальства - с этого дня начинаем жить по новому.
2. Все проекты начинаются в системе контроля версий.
3. Выделяется сервер для централизованного хранения проектов.
4. Минимум одна фиксация за 8 часов работы, например вечером.
5. Зафиксированная версия должна собираться. В редких случаях (масштабный рефакторинг) можно фиксировать несобирающийся проект. Лучше такие штуки пресекать. Проект должен собираться всегда, с самого начала.
6. Начальник контролирует, как часто делаются фиксации. Если реже раза в день - сначала мягко увещевает, затем карает все жестче.
7. Проверяется, правильно ли заведен проект. Проект выкачивается на другую машину и собирается. Если есть особенность сборки проекта - заводится документ, кладется по контроль версий в проект.
8. Старые проект по возможности, плавно (резко здесь нельзя) переводятся на контроль версий.
9. Завести базу знаний, например, на wiki движке. Там постепенно составлять FAQ по работе, успешные приемы, инструкции.
10. (Неплохо бы). Каждый проект ведется минимум 2-мя разработчиками. Достигается знание разработчиками смежных проектов. Тренируются навыки командной работы. Снижается риск потери одного из разработчиков (болезнь, увольнение). Снижается вероятность принятия диких решений, за счет инспекции кода другим разработчиком и принятия решений сообща.


Сообщение отредактировал Slash - Nov 2 2014, 13:14

Хорошая статья.
Только остался неясен момент как же все таки Git упрощает и ускоряет слияние. Что там упрощается.

А таскать по любому надо, и на на флешке, а на диске.

За советы спасибо. Но меня, как того человека, которого не привлек переход на контроль версий, не привлек переход на децентрализованую CVS. Tortoise тоже прекрасно отслеживает коммиты без апдейтов, и externals могут ссылаться на определенную ревизию. Все остальное для меня неактуально пока, а так как человек на хабре описал, так я гит вообще людям не обьясню. Так что пока хватит SVN.

Отличная статья. Спасибо. Хорошо показана ничтожность различий между двумя крайними точками в развитии VCS. Т.е. общая идея: "в новой это сделано удобней, чем в старой". Не более того.
Раньше мы что-то делали командой "dr pr", теперь же то же самое можно сделать, введя команду "pr dr". Насколько продумано! Разработчики потрудились на славу!!

Ну а то, что ниже 0-1-2-3.. - то замечу одно: Следование любым унифицированным процедурам снижает производительность работы. Как минимум в среднесрочной перспективе. Очевидно, что чем больше внимания уделяется процедурным вопросам, тем меньше его остается на основном направлении удара. И наверное не стоит превращатьVCS в систему управления проектами, контроля качества, порядка исполнения и т.п. Она для этого не предназначена. Т.е. конечно есть наиболее удобный с точки зрения VCS порядок работы, но удовлетворяет ли он основным требованиям проекта - большой вопрос.

Поэтому задачу внедрения каких-то автоматизированных систем, требующих от разработчиков следования процедуре, следует решать"по месту" и "по ситуации".

Я, все же, попробую для новой версии firmware попользоваться TortoiseHg.
Читаю этот документ - http://bacher09.org/hgbook/ru/html/

А между тем... Google Go меняет систему контроля версий с Mercurial на Git

Чет какая-то новость из другого мира.
При чем тут электроника и embedded?

Давайте уже тогда все бредовые проекты google здесь пообсуждаем.

Плохой документ для начала. Он старый, 5-летней давности. Не вижу смысла запоминать консольные команды, смотреть их вывод и вообще читать о работе через консоль. Скорее нужно понять основные термины (commit, clone и т.д.) и работать через графическую оболочку HG Workbench и через контекстное меню.

Создаю репозиторий, добавляю файлы через контекстное меню.
Все остальное - через Workbench.

Вот этих двух статей хватит чтобы покрыть большинство потребностей на первое время:
http://dreamhelg.ru/2009/02/tortoisehg/
http://lifeexample.ru/razrabotka-i-optimiz...-mercurial.html

Как лучше, вот так:


Или так:



Это наезд на Меркуриал

Сообщение отредактировал Slash - Nov 15 2014, 03:37