legotron 0 23 декабря, 2008 Опубликовано 23 декабря, 2008 · Жалоба после изучения "теории" в svnbook, можно переходить непосредственно к практике: пп. "4.1.2. Creating The Repository With TortoiseSVN" в хелпе к TortoiseSVN сотворил)) что дальше делать? теперь туда файлы добавляются или проекты целиком? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
bialix 0 23 декабря, 2008 Опубликовано 23 декабря, 2008 · Жалоба >> под виндой начните с bzr или hg. пользовать централизованную систему а-ля svn на одном компе -- нецелесообразно. использовать децентрализованную (при одном разработчике в проекте) и сырую (bzr) - еще большая глупость Готовы аргументировано за базар ответить? Т.е. в svn всё, ну просто всё уже не сырое? и даже этот любимый всеми merge? Ivan A-R так а что мешает делать тоже самое в бранче SVN ???? (коммиты, диффы и т.д.). commit и diff не покажут разницу конечно. merge -- покажет. Это из разряда войн религий... Это твое личное мнение. Я имею представление, поэтому и советую. Для полного новичка изучать и использовать, что централизованную, что распределенную систему -- абсолютно фиолетово, у него просто нет еще стереотипов в мозгу. Вы правильно говорите, на данный момент я остановился на SVN(личное субъективное мнение новичка) для конкретики.. Это ваш выбор, который я не смею оспаривать. Посему -- умолкаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 31 декабря, 2008 Опубликовано 31 декабря, 2008 · Жалоба Итак.. кто распишет по шагам своими словами какие действия необходимо произвести что-бы ощутить хоть какой-нибудь элементарный результат)) Вот моя инструкция для студентов для сетевой версии. Очевидные моменты исключаются при работе на одном компьютере. Да, еще логин и пароль нужно прописать в conf (спрашивайте, если непонятно) Включение нового проекта под систему контроля версий. 1. Создать директорию New_project в главном репозитории (обычно на сервере) (Может сделать только пользователь, имеющий права на сервере - просить) 2. Выбрать директорию New_project и для нее запустить "Set repository here". (Может сделать только пользователь, имеющий права на сервере - просить) 3. Открыть в ней дир conf и заменить файл svnserve.conf на хранящийся шаблон файла в главном репозитории. (Может сделать только пользователь, имеющий права на сервере - просить) 4. Откорректировать этот файл, указав имя проекта. (Может сделать только пользователь, имеющий права на сервере - просить) 5. Создать директорию Work_here, где будет рабочий проект, на рабочей станции. 6. Скопировать туда пустую структуру хранящихся файлов \branches \tags \trunk из шаблона Template в главном репозитории 7. Импортировать эту структуру в репозиторий import svn://server/new_project 8. Удалить все из Work_here и записать туда только те файлы, которые подлежать контролю версий. 9. Импортировать эти файлы в раздел trunk - import svn://server/new_project/trunk 10. Удалить все файлы из work_here и сделать checkout - файлы будут считаны из репозитория. 11. Убедиться, что файлы правильные - можно начинать работу. 12. После корректировки файлов выполнить commit и обязательно указать смысл изменений Создание новой рабочей копии. 1. Создать новый каталог. 2. Выполнить checkout Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
legotron 0 2 января, 2009 Опубликовано 2 января, 2009 · Жалоба 3. Открыть в ней дир conf и заменить файл svnserve.conf на хранящийся шаблон файла в главном репозитории. (Может сделать только пользователь, имеющий права на сервере - просить) 4. Откорректировать этот файл, указав имя проекта. (Может сделать только пользователь, имеющий права на сервере - просить) Для чего служат эти процедуры?? В описании к TortoiseSVN п. 4.1.2. предупреждается: A repository is then created inside the new folder. Don't edit those files yourself!!!. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
legotron 0 17 января, 2009 Опубликовано 17 января, 2009 · Жалоба Продолжаю осваивать SVN, весьма проникся контролем версий, теперь заставляю себя поддерживать порядок! :) Использую TortiseSVN. По ходу работы у меня возникли следующие вопросы: 1. Когда вы оставляете комменты при commit-e, вы используете какую-нибудь четкую структуру записи?? или просто оставляете пометки?? Вообщем интересует структура этих заметок.. 2. Возникло желание сделать TODO-лист... возможно ли сделать примерно следующее?: я пишу что мне нужно сделать, потом отмечаю что сделано, пишу к этому комментарии, как можно сделать такое в связке с SVN? 3. Что такое Bug/Issue tracker? Удобно ли этим пользоваться для самого себя в связке с SVN? Какие из них наиболее удобны? 4. Можно ли автоматизировать процесс создания репозитория, создание его структуры, добавления в него новых проектов, и.т.д... с соответствующими комментами, вообщем рутиные процессы? Как это сделать?, придайте мне направление:) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex B._ 0 17 января, 2009 Опубликовано 17 января, 2009 · Жалоба 1. Когда вы оставляете комменты при commit-e, вы используете какую-нибудь четкую структуру записи?? или просто оставляете пометки?? Вообщем интересует структура этих заметок.. Да какую придумаете, такая и будет. Совет - не коммитить весь проект целиком. Например, у вас есть само приложение и библиотека обслуживания ЖКИ (хотя наилучший вариант, когда такая библиотека используется как externals). Изменили там, изменили тут - комитте отдельно, пишите отдельные комментарии - будет проще разобраться, если что. Ну вот у меня например в начале строки комментария [+++] если что-то добавил и [%%%] если что-то изменил. Иногда [***] при каких-нить других ситуациях. 2. Возникло желание сделать TODO-лист... возможно ли сделать примерно следующее?: я пишу что мне нужно сделать, потом отмечаю что сделано, пишу к этому комментарии, как можно сделать такое в связке с SVN? Не совсем понятно, что вы хотите от SVN 3. Что такое Bug/Issue tracker? Удобно ли этим пользоваться для самого себя в связке с SVN? Какие из них наиболее удобны? Для самого себя - не знаю. В группе удобно. И не обязательно над проектом должно работать несколько человек. Issue tracker может использовать, например, как простейший шедуллер и генератор отчетов для руководства. Из наиболее известных - Trac, мы пользуемтся Redmine - там еще много чего есть кроме баг-трекинга по умолчанию, а в траке надо напрягать админа всякими плагинами, созданием нового проекта и пр. http://www.mysvn.ru/ - тут можно на 10 МБ бесплатном аккуанте посмотреть, что такое Trac. 4. Можно ли автоматизировать процесс создания репозитория, создание его структуры, добавления в него новых проектов, и.т.д... с соответствующими комментами, вообщем рутиные процессы? Как это сделать?, придайте мне направление:) Я вообще не понимаю проблемы. Создаете папку, внутри структура папок проекта (можно сделать потом), тыкаетесь, в тортиле выбираете Import и указываете путь хранилищу + папка для проекта в этом хранилище. Все. Никаких шаманских действий, которые описал Dog Pawlowa не нужно (во всяком случае, если работаете с тортилой и под виндой). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
legotron 0 20 января, 2009 Опубликовано 20 января, 2009 · Жалоба 1. Когда вы оставляете комменты при commit-e, вы используете какую-нибудь четкую структуру записи?? или просто оставляете пометки?? Вообщем интересует структура этих заметок.. Да какую придумаете, такая и будет. Совет - не коммитить весь проект целиком. Например, у вас есть само приложение и библиотека обслуживания ЖКИ (хотя наилучший вариант, когда такая библиотека используется как externals). Насчет коммита целиком: это конечно правильно, но.. 1. это вынудит делать их очень часто и отвлекаться от работы... 2. а если что-нибудь забудешь? (постоянно сверять с HEAD?) 2. Возникло желание сделать TODO-лист... возможно ли сделать примерно следующее?: я пишу что мне нужно сделать, потом отмечаю что сделано, пишу к этому комментарии, как можно сделать такое в связке с SVN? Не совсем понятно, что вы хотите от SVN Автоматическое добавления в файл этой информации... 3. Что такое Bug/Issue tracker? Удобно ли этим пользоваться для самого себя в связке с SVN? Какие из них наиболее удобны? Для самого себя - не знаю. В группе удобно. И не обязательно над проектом должно работать несколько человек. Issue tracker может использовать, например, как простейший шедуллер и генератор отчетов для руководства. Из наиболее известных - Trac, мы пользуемтся Redmine - там еще много чего есть кроме баг-трекинга по умолчанию, а в траке надо напрягать админа всякими плагинами, созданием нового проекта и пр. http://www.mysvn.ru/ - тут можно на 10 МБ бесплатном аккуанте посмотреть, что такое Trac. Спасибо за ссылку :) Чувствую что это отдельная тема, в которой сначала нужно внимательно разобраться, и задавать вопросы в отдельной ветке... 4. Можно ли автоматизировать процесс создания репозитория, создание его структуры, добавления в него новых проектов, и.т.д... с соответствующими комментами, вообщем рутиные процессы? Как это сделать?, придайте мне направление :) Я вообще не понимаю проблемы. Создаете папку, внутри структура папок проекта (можно сделать потом), тыкаетесь, в тортиле выбираете Import и указываете путь хранилищу + папка для проекта в этом хранилище. Все. Никаких шаманских действий, которые описал Dog Pawlowa не нужно (во всяком случае, если работаете с тортилой и под виндой). я скажу "как я хочу", и тогда ИМХО сразу станет понятно в чем проблема :) Хочу чтобы одним действием после создания проекта: 1. создался под него репозиторий 2. создались все необходимые "веточки" в нем 3. проект добавился в /trunk 4. и у меня оказалась рабочая копия с "зеленой галочкой" :) Еще вопросы: 5. Использую svn:keywords... Добавляю properties ко всему проекту с включенной галочкой "Apply prop. recursively"...Часто добавляю новые файлы в проект... и они оказываются без "svn:keywords"(( Как сделать, чтобы нужные мне "свойства" добавлялись к свежедобавленным файлам?? Использовать хуки? Писать .bat файлы? 6. Какое преимущество можно получить в SVN за счет, присвоения новых номеров ревизий только реально изменившимся файлам? P.S. Я использую тортиллу, мне она вполне нравиться, но иногда чувствуется, что я делаю очень много лишних кликов :( Хотелось бы посмотреть на хорошую(образцовую) организацию всего SVN-хозяйства.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex B._ 0 20 января, 2009 Опубликовано 20 января, 2009 · Жалоба Насчет коммита целиком: это конечно правильно, но.. 1. это вынудит делать их очень часто и отвлекаться от работы... 2. а если что-нибудь забудешь? (постоянно сверять с HEAD?) 1) почему? я не чаще раза в день коммит делаю. Я не к тому, что изменил/закоммитил, а к тому, что логически разные части проекта должны быть отдельно закомитчены. 2) TortoiseSVN - замечательная напоминалка. Может у вас оверлейные значки на иконках выключены в системе? Автоматическое добавления в файл этой информации... все равно не понял. Вы хотите календарный план проекта совместить с SVN? зачем? я скажу "как я хочу", и тогда ИМХО сразу станет понятно в чем проблема :) Хочу чтобы одним действием после создания проекта: 1. создался под него репозиторий У меня всегда был один репозиторий. Зачем вам под каждый проект разные? достаточно разделять на уровне папок. А все остальное Import делает. Использую svn:keywords... Добавляю properties ко всему проекту с включенной галочкой "Apply prop. recursively"...Часто добавляю новые файлы в проект... и они оказываются без "svn:keywords"(( Как сделать, чтобы нужные мне "свойства" добавлялись к свежедобавленным файлам?? Использовать хуки? Писать .bat файлы? никогда этим не озадачивался. Я использую только extenals и ignore, больше по-моему ничего не надо. Если не секрет - зачем? Какое преимущество можно получить в SVN за счет, присвоения новых номеров ревизий только реально изменившимся файлам? хм, а разве можно как-то по другому? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
legotron 0 21 января, 2009 Опубликовано 21 января, 2009 · Жалоба 1) почему? я не чаще раза в день коммит делаю. Я не к тому, что изменил/закоммитил, а к тому, что логически разные части проекта должны быть отдельно закомитчены. Т.е. вы, к примеру, производите коммит раз в день, но при этом производя множество последовательный коммитов отдельных частей?? Правильно понимаю? 2) TortoiseSVN - замечательная напоминалка. Может у вас оверлейные значки на иконках выключены в системе? Нет, значки включены, даже в тотал-командер встроил, но мне удобнее смотреть изменения через log.. все равно не понял. Вы хотите календарный план проекта совместить с SVN? зачем? Ну хотелось бы где-нибудь писать что нужно сделать, потом отмечать что это сделал, при этом помечая(автоматом) в какой ревизии это реализовано.. потом можно было бы сделать файл, где в какой ревизии что исправлено.. ну как-то завести "единое окошко" проблем и результатов их устранения(с авто-привязкой к номеру ревизии).. и еще бы неплохо сразу tag при этом делать.. чтобы номер tag-a (release-1.2.3) тоже бы в файл вносился.. что-то типа такого, чтобы автоматом генерилось: Version history --------------- 1.70 (28.04.1999) New methods: SetDTR, SetRTS, SetBreak, SetXonXoff Properties can be changed during a session 1.60 (10.04.1999) New properties: EventChar, DiscardNull, SyncMethod Extended Parity property Fixed compilation problems Other bug fixes 1.50 (13.03.1999) Read/Write operations in asynchronous/synchronous mode Added OnRx80Full event Extended flow control Added Timeouts property 1.01 (24.10.1998) Added more signal detection functions. Added this documentation. Added PurgeOut function. Fixed some minor bugs. 1.00 (29.09.1998) Basic version of the component У меня всегда был один репозиторий. Зачем вам под каждый проект разные? достаточно разделять на уровне папок. А все остальное Import делает. А если он накроется? :) И у вас все логи перемешаны для разных проектов??? Или SVN их для папок сам сортирует, только ревизии с "дырками получаются"? никогда этим не озадачивался. Я использую только extenals и ignore, больше по-моему ничего не надо. Если не секрет - зачем? В файле повесил $Id$, понятно кем, когда, в какой ревизии был закомитчен.. ИМХО удобно, если проект выйдет из под SVN-контроля (Export...) останутся привязки в файлах.. Кстати, удобно было бы чтобы в файл автоматом прописывались пофиксченные баги... но, этим, я думаю уже не SVN должен заниматься, у SVN keywords-ов пальцев одной руки хватит чтобы пересчитать)) хм, а разве можно как-то по другому? я некомпетентен в этом вопросе)) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Сергей Борщ 119 21 января, 2009 Опубликовано 21 января, 2009 · Жалоба 6. Какое преимущество можно получить в SVN за счет, присвоения новых номеров ревизий только реально изменившимся файлам?Просматривая svn log этого файла вы видите, в каких именно правках этот файл реально изменялся. Аналогично, просматривая svn log для папки, вы видите те и только те правки, в которых менялись файлы в этой папке. Ну хотелось бы где-нибудь писать что нужно сделать, потом отмечать что это сделал, при этом помечая(автоматом) в какой ревизии это реализовано..Это вам нужно что-то вроде Trac. spf прикрутил автоматическое формирование файла-отчета об изменениях из лог-сообщений фиксации для scmRTOS. Как он это сделал - я не в курсе. Пишите подробное лог-сообщение при фиксации изменений, это очень полезно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alex B._ 0 21 января, 2009 Опубликовано 21 января, 2009 · Жалоба Т.е. вы, к примеру, производите коммит раз в день, но при этом производя множество последовательный коммитов отдельных частей?? Правильно понимаю? суть поняли правильно. Нет, значки включены, даже в тотал-командер встроил, но мне удобнее смотреть изменения через log.. дык и смотрите через лог. Это к тому, что можно "что-нибудь забыть" Ну хотелось бы где-нибудь писать что нужно сделать, потом отмечать что это сделал, при этом помечая(автоматом) в какой ревизии это реализовано.. Trac, Redmine. В общем, баг трекер вам наверное поможет. А если он накроется? :) Для этого нужно делать ежедневный бэкап. Кроме того, на многих бесплатных SVN хостингах можно создать только ограниченное количество репозиториев. И у вас все логи перемешаны для разных проектов??? Или SVN их для папок сам сортирует, только ревизии с "дырками получаются"? Сам сортирует. Вы можете посмотреть историю ревизий только для одного файла и увидите только его ревизии. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
spf 0 22 января, 2009 Опубликовано 22 января, 2009 · Жалоба Это вам нужно что-то вроде Trac. Для простоты установки можно попробоватьRedmine или Mantis spf прикрутил автоматическое формирование файла-отчета об изменениях из лог-сообщений фиксации для scmRTOS. Как он это сделал - я не в курсе. Все примитивно просто - для этого используется готовый скрипт scn2cl Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
legotron 0 28 января, 2009 Опубликовано 28 января, 2009 · Жалоба Подскажите пожалуйста, нужно ли включать в коммиты файлы типов: *.exe, *.hex, *.elf и.т.д Аргументы "против": - Они постоянно меняются при компиляции, и мешаются при коммитах Аргументы "За": - сохраняется срез полностью готового проекта, не нужно ничего дополнительно компилить.. У кого что в игнорах? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
scifi 1 28 января, 2009 Опубликовано 28 января, 2009 · Жалоба Подскажите пожалуйста, нужно ли включать в коммиты файлы типов: *.exe, *.hex, *.elf и.т.д Так и религиозную войну недолго начать :-) Тем не менее, мои 5 копеек: Я храню только исходники (включая настройки тулзов для сборки). Считаю, что прошивке не место рядом с ними. Аргументы: 1) Если это не релиз, то толку от двоичного файла мало: всё равно продолжается разработка и тулзы под рукой, так что собрать образ заново легко. 2) Если это релиз, то файл прошивки по-хорошему надо хранить вместе с внутренней документацией на изделие, в которое залита эта прошивка. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SFx 0 28 января, 2009 Опубликовано 28 января, 2009 · Жалоба но если совсем хочется хранить .elf и другие файлы - то лучше создать скрипты, которые будут автоматом их переносить в Release репозиторий. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
