сотворил))
что дальше делать?
теперь туда файлы добавляются или проекты целиком?

Готовы аргументировано за базар ответить? Т.е. в svn всё, ну просто всё уже не сырое? и даже этот любимый всеми merge?



commit и diff не покажут разницу конечно. merge -- покажет.




Это твое личное мнение. Я имею представление, поэтому и советую.
Для полного новичка изучать и использовать, что централизованную, что распределенную систему -- абсолютно фиолетово, у него просто нет еще стереотипов в мозгу.




Это ваш выбор, который я не смею оспаривать. Посему -- умолкаю.

Вот моя инструкция для студентов для сетевой версии. Очевидные моменты исключаются при работе на одном компьютере. Да, еще логин и пароль нужно прописать в 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

Для чего служат эти процедуры??
В описании к TortoiseSVN п. 4.1.2. предупреждается:

Продолжаю осваивать SVN, весьма проникся контролем версий, теперь заставляю себя поддерживать порядок!

Использую TortiseSVN.
По ходу работы у меня возникли следующие вопросы:

1. Когда вы оставляете комменты при commit-e, вы используете какую-нибудь четкую структуру записи?? или просто оставляете пометки?? Вообщем интересует структура этих заметок..
2. Возникло желание сделать TODO-лист... возможно ли сделать примерно следующее?: я пишу что мне нужно сделать, потом отмечаю что сделано, пишу к этому комментарии, как можно сделать такое в связке с SVN?
3. Что такое Bug/Issue tracker? Удобно ли этим пользоваться для самого себя в связке с SVN? Какие из них наиболее удобны?
4. Можно ли автоматизировать процесс создания репозитория, создание его структуры, добавления в него новых проектов, и.т.д... с соответствующими комментами, вообщем рутиные процессы? Как это сделать?, придайте мне направление

Да какую придумаете, такая и будет. Совет - не коммитить весь проект целиком. Например, у вас есть само приложение и библиотека обслуживания ЖКИ (хотя наилучший вариант, когда такая библиотека используется как externals). Изменили там, изменили тут - комитте отдельно, пишите отдельные комментарии - будет проще разобраться, если что.
Ну вот у меня например в начале строки комментария [+++] если что-то добавил и [%%%] если что-то изменил. Иногда [***] при каких-нить других ситуациях.


Не совсем понятно, что вы хотите от SVN


Для самого себя - не знаю. В группе удобно. И не обязательно над проектом должно работать несколько человек. Issue tracker может использовать, например, как простейший шедуллер и генератор отчетов для руководства. Из наиболее известных - Trac, мы пользуемтся Redmine - там еще много чего есть кроме баг-трекинга по умолчанию, а в траке надо напрягать админа всякими плагинами, созданием нового проекта и пр.
http://www.mysvn.ru/ - тут можно на 10 МБ бесплатном аккуанте посмотреть, что такое Trac.


Я вообще не понимаю проблемы. Создаете папку, внутри структура папок проекта (можно сделать потом), тыкаетесь, в тортиле выбираете Import и указываете путь хранилищу + папка для проекта в этом хранилище. Все. Никаких шаманских действий, которые описал Dog Pawlowa не нужно (во всяком случае, если работаете с тортилой и под виндой).

Насчет коммита целиком: это конечно правильно, но..
1. это вынудит делать их очень часто и отвлекаться от работы...
2. а если что-нибудь забудешь? (постоянно сверять с HEAD?)


Автоматическое добавления в файл этой информации...


Спасибо за ссылку
Чувствую что это отдельная тема, в которой сначала нужно внимательно разобраться, и задавать вопросы в отдельной ветке...


я скажу "как я хочу", и тогда ИМХО сразу станет понятно в чем проблема
Хочу чтобы одним действием после создания проекта:
1. создался под него репозиторий
2. создались все необходимые "веточки" в нем
3. проект добавился в /trunk
4. и у меня оказалась рабочая копия с "зеленой галочкой"

Еще вопросы:
5. Использую svn:keywords... Добавляю properties ко всему проекту с включенной галочкой "Apply prop. recursively"...Часто добавляю новые файлы в проект... и они оказываются без "svn:keywords"((
Как сделать, чтобы нужные мне "свойства" добавлялись к свежедобавленным файлам?? Использовать хуки? Писать .bat файлы?
6. Какое преимущество можно получить в SVN за счет, присвоения новых номеров ревизий только реально изменившимся файлам?

P.S. Я использую тортиллу, мне она вполне нравиться, но иногда чувствуется, что я делаю очень много лишних кликов
Хотелось бы посмотреть на хорошую(образцовую) организацию всего SVN-хозяйства..

1) почему? я не чаще раза в день коммит делаю. Я не к тому, что изменил/закоммитил, а к тому, что логически разные части проекта должны быть отдельно закомитчены.
2) TortoiseSVN - замечательная напоминалка. Может у вас оверлейные значки на иконках выключены в системе?


все равно не понял. Вы хотите календарный план проекта совместить с SVN? зачем?



У меня всегда был один репозиторий. Зачем вам под каждый проект разные? достаточно разделять на уровне папок. А все остальное Import делает.


никогда этим не озадачивался. Я использую только extenals и ignore, больше по-моему ничего не надо. Если не секрет - зачем?


хм, а разве можно как-то по другому?

Т.е. вы, к примеру, производите коммит раз в день, но при этом производя множество последовательный коммитов отдельных частей?? Правильно понимаю?


Нет, значки включены, даже в тотал-командер встроил, но мне удобнее смотреть изменения через log..


Ну хотелось бы где-нибудь писать что нужно сделать, потом отмечать что это сделал, при этом помечая(автоматом) в какой ревизии это реализовано.. потом можно было бы сделать файл, где в какой ревизии что исправлено.. ну как-то завести "единое окошко" проблем и результатов их устранения(с авто-привязкой к номеру ревизии).. и еще бы неплохо сразу tag при этом делать.. чтобы номер tag-a (release-1.2.3) тоже бы в файл вносился..
что-то типа такого, чтобы автоматом генерилось:



А если он накроется?
И у вас все логи перемешаны для разных проектов??? Или SVN их для папок сам сортирует, только ревизии с "дырками получаются"?


В файле повесил $Id$, понятно кем, когда, в какой ревизии был закомитчен.. ИМХО удобно, если проект выйдет из под SVN-контроля (Export...) останутся привязки в файлах..
Кстати, удобно было бы чтобы в файл автоматом прописывались пофиксченные баги... но, этим, я думаю уже не SVN должен заниматься, у SVN keywords-ов пальцев одной руки хватит чтобы пересчитать))


я некомпетентен в этом вопросе))

Просматривая svn log этого файла вы видите, в каких именно правках этот файл реально изменялся. Аналогично, просматривая svn log для папки, вы видите те и только те правки, в которых менялись файлы в этой папке.

Это вам нужно что-то вроде Trac. spf прикрутил автоматическое формирование файла-отчета об изменениях из лог-сообщений фиксации для scmRTOS. Как он это сделал - я не в курсе. Пишите подробное лог-сообщение при фиксации изменений, это очень полезно.

суть поняли правильно.


дык и смотрите через лог. Это к тому, что можно "что-нибудь забыть"


Trac, Redmine. В общем, баг трекер вам наверное поможет.


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


Сам сортирует. Вы можете посмотреть историю ревизий только для одного файла и увидите только его ревизии.

Для простоты установки можно попробоватьRedmine или Mantis


Все примитивно просто - для этого используется готовый скрипт scn2cl

Подскажите пожалуйста, нужно ли включать в коммиты файлы типов:
*.exe, *.hex, *.elf и.т.д

Аргументы "против":
- Они постоянно меняются при компиляции, и мешаются при коммитах
Аргументы "За":
- сохраняется срез полностью готового проекта, не нужно ничего дополнительно компилить..

У кого что в игнорах?

Так и религиозную войну недолго начать :-) Тем не менее, мои 5 копеек:
Я храню только исходники (включая настройки тулзов для сборки). Считаю, что прошивке не место рядом с ними. Аргументы:
1) Если это не релиз, то толку от двоичного файла мало: всё равно продолжается разработка и тулзы под рукой, так что собрать образ заново легко.
2) Если это релиз, то файл прошивки по-хорошему надо хранить вместе с внутренней документацией на изделие, в которое залита эта прошивка.

но если совсем хочется хранить .elf и другие файлы - то лучше создать скрипты, которые будут автоматом их переносить в Release репозиторий.