syoma 1 30 октября, 2014 Опубликовано 30 октября, 2014 · Жалоба Блин, опять я что-ли всех запутал? В общем насчет externals, и моей идеи. Все проекты находятся в одном репозитарии на сервере. У каждого проекта есть свой trunk и тэги. Я хочу опять же в репозитарии, но не привязываясь к конкретному проекту, создать папочку all_models, и в ее свойствах прописать externals к нужным папкам из разных проектов. Затем ссылку на папку all_models я даю заинтересованным пользователям и они делают чекаут на свои локальные компы. Если я добавляю новый проект, то мне достаточно на сервере изменить свойства папки один раз и пользователи, сделав апдейт, получат себе новые файлы. Таким образом пользователям не нужно заморачиваться со свойствами. ПС. Ессно то же самое я могу сделать, сделав чекаут папки all_models, изменив ее свойства в рабочей копии и сделав коммит. Так понятно? Или я что-то делаю не так? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 53 30 октября, 2014 Опубликовано 30 октября, 2014 · Жалоба Все проекты находятся в одном репозитарии на сервере. У каждого проекта есть свой trunk и тэги. Я хочу опять же в репозитарии, но не привязываясь к конкретному проекту, создать папочку all_models, и в ее свойствах прописать externals к нужным папкам из разных проектов. Затем ссылку на папку all_models я даю заинтересованным пользователям и они делают чекаут на свои локальные компы. Если я добавляю новый проект, то мне достаточно на сервере изменить свойства папки один раз и пользователи, сделав апдейт, получат себе новые файлы. Таким образом пользователям не нужно заморачиваться со свойствами. Без разницы, где вы эту папку создадите - на сервере или в РК. На сервере - это надо лезть repo browser, и каждая ошибка фиксируется, в общем, не очень штатно и не удобно. Штатный способ - в РК. После коммита эта папка окажется в репе. Все действия сводятся к: Создать папку. Создать у этой папки свойства (property) типа svn:externals, у каждого свойства указать пару <название папки> <путь до папки в репе>. Сделать svn commit. При необходимости изменить список этих папок нужно просто добавить/удалить/изменить свойства папки с externals. Пользователям ничего, кроме checkout и update делать не надо, про свойства им тоже даже знать не надо. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 30 октября, 2014 Опубликовано 30 октября, 2014 · Жалоба Блин, опять я что-ли всех запутал? В общем насчет externals, и моей идеи. Все проекты находятся в одном репозитарии на сервере. У каждого проекта есть свой trunk и тэги. Я хочу опять же в репозитарии, но не привязываясь к конкретному проекту, создать папочку all_models, и в ее свойствах прописать externals к нужным папкам из разных проектов. Затем ссылку на папку all_models я даю заинтересованным пользователям и они делают чекаут на свои локальные компы. Если я добавляю новый проект, то мне достаточно на сервере изменить свойства папки один раз и пользователи, сделав апдейт, получат себе новые файлы. Таким образом пользователям не нужно заморачиваться со свойствами. ПС. Ессно то же самое я могу сделать, сделав чекаут папки all_models, изменив ее свойства в рабочей копии и сделав коммит. Так понятно? Или я что-то делаю не так? И опять запутали. На сервере (т.е. локально сидя у этого физического сервера или через TeamViewer) 'папочку' можно сделать только в уже готовом репозитарии. Либо делать новый репозитарий. Т.е. отдельно стоящую 'папочку' не сделать. Если на самом физическом сервере залезть в директорию где он хранит данные, то не увидите никаких привычных 'папочек'. Визуальная оболочка VisualSVN тоже особых инструментов не предлагает. Т.е. все что можно делать если не использовать скрипты, то только конфигурировать полученные после операции checkout директории на компьютере одного из клиентов. Хотя конечно клиент (TurtioseSVN) может быть и на самом компьютере сервера. Я так и делаю кстати. Поскольку SVN невыносимо медленно работает даже на 2 Mbit линиях, я просто на флешке переношу на сервер импортируемые проекты. Импортирую их там в репозитарий сервера (это будет localhost), там же делаю checkout с сервера обратно в новую локальную директорию на том же физическом компьютере и снова на флешке полученную директорию отношу на рабочий комп. Там уже ей с помощью меню TurtoiseSVN делаю relocation. Т.е. меняю путь от директории к репозиторию с локального на удаленный домен. Вот такая дискотека. Все ради науки. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 30 октября, 2014 Опубликовано 30 октября, 2014 · Жалоба И опять запутали. На сервере (т.е. локально сидя у этого физического сервера или через TeamViewer) 'папочку' можно сделать только в уже готовом репозитарии. Либо делать новый репозитарий. Т.е. отдельно стоящую 'папочку' не сделать. Если на самом физическом сервере залезть в директорию где он хранит данные, то не увидите никаких привычных 'папочек'. Визуальная оболочка VisualSVN тоже особых инструментов не предлагает. Я имел ввиду через Repo Browser в TortoiseSVN - тогда не надо возле сервера сидеть. Поскольку SVN невыносимо медленно работает даже на 2 Mbit линиях Вот такая дискотека. Все ради науки. Вы пробовали wordoвский документ открывать на такой линии? Вот это дискач. А от SVN на медленных линиях я тащусь - закончил работу, с чувством глубокого удовлетворения запустил коммит и пошел чай пить/кушать/спать в зависимости от размера. И никаких беспокойств. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 31 октября, 2014 Опубликовано 31 октября, 2014 · Жалоба А от SVN на медленных линиях я тащусь - закончил работу, с чувством глубокого удовлетворения запустил коммит и пошел чай пить/кушать/спать в зависимости от размера. И никаких беспокойств. Ну да нагружаем SVN чем угодно, только не контролем собственно версий. А применить стандартный backup по idle не судьба была? Когда я был озабочен долговечными резервными копиями у меня на стриммер сливалось каждый раз когда я от стола на 5 мин отходил. Даже забывал о существовании бэкапа. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 31 октября, 2014 Опубликовано 31 октября, 2014 · Жалоба А применить стандартный backup по idle не судьба была? Когда я был озабочен долговечными резервными копиями у меня на стриммер сливалось каждый раз когда я от стола на 5 мин отходил. Даже забывал о существовании бэкапа. Тогда наверное про SVN еще не знали? Зачем заморачиваться с backup по idle, если бекапы репозитария настроены на сервере вместе со всеми другими вещами? Зачем мне изучать и настраивать еще один софт, притом на каждом рабочем месте, или если я снесу винду на компе? Ну да нагружаем SVN чем угодно, только не контролем собственно версий. Ну мое имхо, что если спросить разработчиков SVN, какова была первичная цель создания SVN, то проблема медленных линий и организация синхронизации по ним была для них на одном из первых мест. Всякие разные версии - это уже следствие решения первой проблемы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 31 октября, 2014 Опубликовано 31 октября, 2014 · Жалоба Зачем заморачиваться с backup по idle, если бекапы репозитария настроены на сервере вместе со всеми другими вещами? Зачем мне изучать и настраивать еще один софт, притом на каждом рабочем месте, или если я снесу винду на компе? Потому что в частности SVN не использует сжатие. Да он пересылает только патчи, но зато каждую рабочую директорию захламляет тучей вспомогательных файлов своей базы данных. А это и фрагментация диска, и замедление работы антивирусов, и замедление поиска по файлам, и риск получить сбой если какой либо из этих файлов базы данных повредится. Потом оно конечно пересылаете в свое свободное время, но качать обратно то другим придется в свое рабочее время. Вообщем SVN явно негодный инструмент и для резервного копирования. Ну мое имхо, что если спросить разработчиков SVN, какова была первичная цель создания SVN, то проблема медленных линий и организация синхронизации по ним была для них на одном из первых мест. Всякие разные версии - это уже следствие решения первой проблемы. SVN делали для проектов Open Sourse. А не для индивидуалов или производственных фирм. Open Source это годами ковыряние в текстовых файлах и переливание из пустого в порожнее. Такие виды деятельности как создание PCB, конструирование, исследования, испытания их никогда не волновали и не волнуют. SVN к ним никак не приспособлен. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Slash 0 2 ноября, 2014 Опубликовано 2 ноября, 2014 (изменено) · Жалоба Столкнулся с по-видимому непосильной задачей - как объяснить человеку, а точнее даже не одному, оставшимся в прошлом веке, как работает SVN (Точнее TortoiseSVN) и почему не надо архивировать и хранить версии всех своих файлов в той-же папке, что такое Коммит и Чекаут, и почему оно ничего не находит в екплорере? Вы сейчас будете внедрять уже устаревшую 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-мя разработчиками. Достигается знание разработчиками смежных проектов. Тренируются навыки командной работы. Снижается риск потери одного из разработчиков (болезнь, увольнение). Снижается вероятность принятия диких решений, за счет инспекции кода другим разработчиком и принятия решений сообща. Изменено 2 ноября, 2014 пользователем Slash Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 3 ноября, 2014 Опубликовано 3 ноября, 2014 · Жалоба Ну и серия статей от одного довольно известного программиста: Hg Init: Часть 1. Переобучение для пользователей Subversion Все свои проекты держу на bitbucket.org. Очень удобно, не нужно ничего таскать на флешке. Хорошая статья. Только остался неясен момент как же все таки Git упрощает и ускоряет слияние. Что там упрощается. А таскать по любому надо, и на на флешке, а на диске. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 3 ноября, 2014 Опубликовано 3 ноября, 2014 · Жалоба За советы спасибо. Но меня, как того человека, которого не привлек переход на контроль версий, не привлек переход на децентрализованую CVS. Tortoise тоже прекрасно отслеживает коммиты без апдейтов, и externals могут ссылаться на определенную ревизию. Все остальное для меня неактуально пока, а так как человек на хабре описал, так я гит вообще людям не обьясню. Так что пока хватит SVN. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
FatRobot 0 3 ноября, 2014 Опубликовано 3 ноября, 2014 · Жалоба Отличная статья. Спасибо. Хорошо показана ничтожность различий между двумя крайними точками в развитии VCS. Т.е. общая идея: "в новой это сделано удобней, чем в старой". Не более того. Раньше мы что-то делали командой "dr pr", теперь же то же самое можно сделать, введя команду "pr dr". Насколько продумано! Разработчики потрудились на славу!! Ну а то, что ниже 0-1-2-3.. - то замечу одно: Следование любым унифицированным процедурам снижает производительность работы. Как минимум в среднесрочной перспективе. Очевидно, что чем больше внимания уделяется процедурным вопросам, тем меньше его остается на основном направлении удара. И наверное не стоит превращатьVCS в систему управления проектами, контроля качества, порядка исполнения и т.п. Она для этого не предназначена. Т.е. конечно есть наиболее удобный с точки зрения VCS порядок работы, но удовлетворяет ли он основным требованиям проекта - большой вопрос. Поэтому задачу внедрения каких-то автоматизированных систем, требующих от разработчиков следования процедуре, следует решать"по месту" и "по ситуации". По преимуществам распределенных VCS хипстеры накатали уже не одну статью, все преимущества там озвучены: Сравнение Subversion и Mercurial (HG) 0. Настройтесь на многократное повторение одного и того же. 1. Должна пойти команда от начальства - с этого дня начинаем жить по новому. 2. Все проекты начинаются в системе контроля версий. 3. Выделяется сервер для централизованного хранения проектов. 4. Минимум одна фиксация за 8 часов работы, например вечером. 5. Зафиксированная версия должна собираться. В редких случаях (масштабный рефакторинг) можно фиксировать несобирающийся проект. Лучше такие штуки пресекать. Проект должен собираться всегда, с самого начала. 6. Начальник контролирует, как часто делаются фиксации. Если реже раза в день - сначала мягко увещевает, затем карает все жестче. 7. Проверяется, правильно ли заведен проект. Проект выкачивается на другую машину и собирается. Если есть особенность сборки проекта - заводится документ, кладется по контроль версий в проект. 8. Старые проект по возможности, плавно (резко здесь нельзя) переводятся на контроль версий. 9. Завести базу знаний, например, на wiki движке. Там постепенно составлять FAQ по работе, успешные приемы, инструкции. 10. (Неплохо бы). Каждый проект ведется минимум 2-мя разработчиками. Достигается знание разработчиками смежных проектов. Тренируются навыки командной работы. Снижается риск потери одного из разработчиков (болезнь, увольнение). Снижается вероятность принятия диких решений, за счет инспекции кода другим разработчиком и принятия решений сообща. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 12 ноября, 2014 Опубликовано 12 ноября, 2014 · Жалоба Я, все же, попробую для новой версии firmware попользоваться TortoiseHg. Читаю этот документ - http://bacher09.org/hgbook/ru/html/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 15 14 ноября, 2014 Опубликовано 14 ноября, 2014 · Жалоба А между тем... Google Go меняет систему контроля версий с Mercurial на Git Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 14 ноября, 2014 Опубликовано 14 ноября, 2014 · Жалоба А между тем... Google Go меняет систему контроля версий с Mercurial на Git Чет какая-то новость из другого мира. При чем тут электроника и embedded? Давайте уже тогда все бредовые проекты google здесь пообсуждаем. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Slash 0 15 ноября, 2014 Опубликовано 15 ноября, 2014 (изменено) · Жалоба Я, все же, попробую для новой версии firmware попользоваться TortoiseHg. Читаю этот документ - http://bacher09.org/hgbook/ru/html/ Плохой документ для начала. Он старый, 5-летней давности. Не вижу смысла запоминать консольные команды, смотреть их вывод и вообще читать о работе через консоль. Скорее нужно понять основные термины (commit, clone и т.д.) и работать через графическую оболочку HG Workbench и через контекстное меню. Создаю репозиторий, добавляю файлы через контекстное меню. Все остальное - через Workbench. Вот этих двух статей хватит чтобы покрыть большинство потребностей на первое время: http://dreamhelg.ru/2009/02/tortoisehg/ http://lifeexample.ru/razrabotka-i-optimiz...-mercurial.html Как лучше, вот так: Самое первое, что вы захотите сделать с новым, неизвестным репозиторием — изучить его историю. Команда hg log предназначена как раз для этого. $ hg log changeset: 4:2278160e78d4 tag: tip user: Bryan O'Sullivan <[email protected]> date: Sat Aug 16 22:16:53 2008 +0200 summary: Trim comments. changeset: 3:0272e0d5a517 user: Bryan O'Sullivan <[email protected]> date: Sat Aug 16 22:08:02 2008 +0200 summary: Get make to generate the final binary from a .o file. changeset: 2:fef857204a0c user: Bryan O'Sullivan <[email protected]> date: Sat Aug 16 22:05:04 2008 +0200 summary: Introduce a typo into hello.c. changeset: 1:82e55d328c8c user: [email protected] date: Fri Aug 26 01:21:28 2005 -0700 summary: Create a makefile changeset: 0:0a04b987be5a user: [email protected] date: Fri Aug 26 01:20:50 2005 -0700 summary: Create a standard "hello, world" program По умолчанию, эта команда выводит краткую информацию о каждом изменении в проекте, которое было зафиксировано. В терминологии Mercurial мы называем эти зафиксированные события ревизией (changeset), потому Или так: При чем тут электроника и embedded? Это наезд на Меркуриал :crying: Изменено 15 ноября, 2014 пользователем Slash Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
