Поможет ли тут система сопровождения версий?

← →
alex_ant (2007-09-18 18:34) [0]

Пару лет в одиночку пишу на Delphi относительно большую систему. Способ сопровождения версий был такой:
1. Решаю, что нужно добавить, что-то новое в систему
2. Копирую проект в новую папку. Название этой папки начинаю цифрой, больше на 1, чем у предыдущей, после цифры пишу название новой функциональности.
3. Вношу все изменения, проверяю и т. д.
4. Если нужно «откатить» систему назад, просто беру всё что нужно из предыдущей папки.
Согласитесь довольно примитивный способ. Последнее время стал замечать, что начинаю путаться в своей системе и изменениях.

Как думаете, поможет ли мне какая-нибудь система сопровождения версий? И какая? Повторюсь, пишу один, и всё на локалхосте (т. е. нет коллективной работы над проектом через сеть).

Буду признателен за ответы.

← →
wicked © (2007-09-18 19:13) [1]

http://subversion.tigris.org
если разберешься - понравится
а разобраться - не трудно

← →
Суслик © (2007-09-18 19:19) [2]

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

поддерживаю svn. разобраться несложно. время на въезд 2-3 дня. до хорошего уровня (в т.ч. и администрирования) недели 3.

← →
Псалтырь (2007-09-18 19:52) [3]

> wicked © (18.09.07 19:13) [1]
>
> http://subversion.tigris.org

+1

← →
Джо © (2007-09-19 02:46) [4]

А я в него так и не въехал. То ли он глючил, то ли я :(

← →
Германн © (2007-09-19 03:10) [5]

> Джо © (19.09.07 02:46) [4]
>
> А я в него так и не въехал. То ли он глючил, то ли я :(
>

Серёг. А это ты про что?

← →
Джо © (2007-09-19 03:30) [6]

> http://subversion.tigris.org

А это я про http://subversion.tigris.org

← →
Германн © (2007-09-19 03:33) [7]

> А это я про http://subversion.tigris.org

Добавлю в закладки.

← →
Иа (2007-09-19 08:46) [8]

http://sourcegear.com/vault/index.html

Однопользовательская версия у них бесплатная. Быстрая, простая и удобная система. К ней надо взять Beyond Compare.

← →
Ricko © (2007-09-19 09:21) [9]

Советую к subversion добавить Trac - систему bag/issue трэкинга

← →
pasha_golub © (2007-09-19 09:32) [10]

> Ricko © (19.09.07 09:21) [9]
>
> Советую к subversion добавить Trac - систему bag/issue
> трэкинга
>

У нас Мантис прикручен. Тоже довольны.

> Джо © (19.09.07 02:46) [4]
>
> А я в него так и не въехал. То ли он глючил, то ли я :(

Серега, прости, но истина дороже. :) По-моему, ты.

← →
Суслик © (2007-09-19 09:37) [11]

поддерживаю Мантис ибо ставится ЗНАЧИТЕЛЬНО проще trac.
просто на несколько порядков.

← →
alex_ant © (2007-09-29 19:01) [12]

А можно к Subversion какой-нибудь графический интерфейс прикрутить на манер Perforce? Для меня посто сопровождение версий с Perforce ассоциируется из коммандной строки как-то тяжко...

И ещё... группирование файлов в проекты Delphi вносит какие-то коррективы в управление версиями? Я просто до этого управлял версиями только для одиночных файлов (CGI-скрипты), боюсь на какие-нибудь грабли наступить...

← →
Суслик © (2007-09-29 21:50) [13]

> alex_ant © (29.09.07 19:01) [12]
> А можно к Subversion какой-нибудь графический интерфейс
> п

tortoisesvn

← →
Суслик © (2007-09-29 21:58) [14]

> alex_ant © (29.09.07 19:01) [12]
>
> И ещё... группирование файлов в проекты Delphi вносит какие-
> то коррективы в управление версиями?

Не скажу, что вопрос ясен на все 100. Но постараюсь.

Я не думаю, что процесс управления исходными кодами Дельфи чем-то отличается от аналогичого процесса для других языков. Пожалуй можно выделить некую проблему сопровождения служебных файлов проекта: *.cfg, *.dof, *.dproj и пр.

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

Поэтому я их в репозитарий не кладу. В Д2007 я не верю *.dproj, который у меня переодически меняется самопроизвольно. Для сборки я написал *.cmd. Ему я верю :) А если кому-то нужно сделать check out - то дельфи ему пересоздаст *.dproj и пусть он сам настраивает себе проект, но *.dproj в репозитарий не кладет.

Помню, что и в старых версиях меня удивляла некая нелогичность *.cfg (кажеца). С одной стороны содержит настройки, с другой локальные пути на компе разработчика.

Резюме:
1. *.pas - никаких особенностей
2. *.dfm - только самопроизвольные изменения (у меня это часто бывает в d2007 - происходит замена на новые свойства: раньше было Height, теперь ImplicitHeight, вроде того). Я таким изменениям делаю revert.
3. *.<служебные файлы проекта> - я их не кладу в репозитарий. Возможно, что в будущем буду класть, когда в Дельфи2008 будет интеграция с SVN и, естественно, статься по best practise от самого Code Gear.

Удачи.

← →
iZEN © (2007-10-02 14:18) [15]

> alex_ant (18.09.07 18:34)
>
> Как думаете, поможет ли мне какая-нибудь система сопровождения
> версий? И какая? Повторюсь, пишу один, и всё на локалхосте
> (т. е. нет коллективной работы над проектом через сеть).
>
> Буду признателен за ответы.

Для индивидуальной разработки весьма полезна система неинкрементного ведения копий проекта по временным точкам: реализация той или иной фичи "замораживается" в проекте птём создания архива всего проекта и приписывния ему временн"ой отметки. Так можно не потерять последние изменения и не таскать с собой кучу архивов с дельтами, в которых легко можно заблудиться: любой архив являет собой готовый к очередной ревизии проект, а не дельту предыдущего релиза.

Комментарии к очередному архиву не надо забывать делать: что выброшено, что изменилось, что появилось новое и по каким причинам это сделано -- это удобно для человека, ведущего проект. Также, впоследствии удобно переходить между "точками заморозки" и откатывать назад с помощью любого инструмента, сравнивающего тексты, выбирая по ходу лучшее решение.
Это как ежедневник.

> [10] pasha_golub © (19.09.07 09:32)
> > Джо © (19.09.07 02:46) [4]
> >
> > А я в него так и не въехал. То ли он глючил, то ли я :
> (
>
> Серега, прости, но истина дороже. :) По-моему, ты.

Та мне стыдно :(
Причем, настолько, что на прошлой неделе сел и разобрался.
Нереально круто оказалось :)

Суслик, спасибо за развёрнутый ответ, но мне кажется ваш подход, не класть служебные файлы в репозиторий, имеет некоторый недостаток. Получается, что если брать в системе контроля версий на редактирование только файлы *.pas, а технические файлы брать из директории проекта как есть, изменения таких файлов уже не будет контролироваться и, следовательно, исчезнет возможность отката. Кнопку случайно передвинул на 3 пикселя, захотел откатить обратно, ан нет, нужно было в брать файл формы на редактирование.

Если же брать на редактирование все файлы проекта и потом после редактирования нужных модулей сабмитить их в репозиторий, получится, что некоторые файлы получат новую версию, но фактически не будут изменены. Тоже какой-то корявый подход — изменил три строчки в Unit1.pas, а весь проект получил новую версию.

Я, честно говоря, вообще не представляю как быть. Разве что брать на редактирование файлы которые будешь редактировать и файлы, которые скорее всего изменятся (но изменятся ли?). Мне кажется должен быть какой-то отлаженный механизм для проектов Delphi...

> Суслик, спасибо за развёрнутый ответ, но мне кажется ваш
> подход, не класть служебные файлы в репозиторий, имеет некоторый
> недостаток. Получается, что если брать в системе контроля
> версий на редактирование только файлы *.pas, а технические
> файлы брать из директории проекта как есть, изменения таких
> файлов уже не будет контролироваться и, следовательно, исчезнет
> возможность отката. Кнопку случайно передвинул на 3 пикселя,
> захотел откатить обратно, ан нет, нужно было в брать файл
> формы на редактирование.

dfm файлы должны быть добавлены в репозиторий

> Если же брать на редактирование все файлы проекта и потом
> после редактирования нужных модулей сабмитить их в репозиторий,
> получится, что некоторые файлы получат новую версию, но
> фактически не будут изменены. Тоже какой-то корявый подход
> — изменил три строчки в Unit1.pas, а весь проект получил
> новую версию.

это идеология subversion - репозиторий имеет один номер версии - последний

> Я, честно говоря, вообще не представляю как быть. Разве
> что брать на редактирование файлы которые будешь редактировать
> и файлы, которые скорее всего изменятся (но изменятся ли?
> ). Мне кажется должен быть какой-то отлаженный механизм
> для проектов Delphi...

никак... с тем, что у всех файлов оди номер ревизии, проблем не вижу
вообще у связки "проект в текстовых исходниках" + svn проблем нету

> спасибо за развёрнутый ответ, но мне кажется ваш подход,
> не класть служебные файлы в репозиторий, имеет некоторый
> недостаток

пока в дельфи не будет ЧЕТКО прописано, что такое служебные файлы и как они влияют на проект я их класть не буду.

*.dproj переодически меняется. Например, изменил настроку range check error на on. потом обратно на off. в итоге в *.dproj вставилась пустая строка. бывает периодически форматирование xml в *.dproj меняется: было записано в несколько строк, стало в одну но широченную.

ну уж нафиг.

*.dfm я конечно кладу.

-----
вообще по поводу философии SVN. в нем нет понятия "взять на редактирование" (есть локи, но они сами не советуют этим пользоваться и если пользоваться, то только для бинарников, где невозможне merge в принципе). нельзя взять текстовый файл на ред-ие. у тебя все уже есть в working copy. меняй как хочешь и что хочешь, но в час Х коммита на сервер ты должен решить, что и как класть. может оказаться такой сценарий:
1. ты сделал update (взял с сервера) файл А при ревижине 333
2. ты добавил в А строку.
3. Ваня Сидоров добавил в А строку и положит на сервер. Ревижин стал 334.
4. ты решил положить свою копию А на сервер.
5. начинаешь класть и ... оба на - ошибка out of date - твой файл устарел: ты пытаешься положить файл отредактированный на основе файла из ревижина 333, а на сервера ревижин 334.

происходит откат всей транзакции.
твои действия?
1. сделать update для A.
2. скорее всего будет автоматический merge, но может быть и конфликт. в итоге в локальной копии у тебя будет лежать А, в котором будут изменения сделанные Ваней и твои. Причем Ванины уже на сервере, твои только у тебя.
3. далее делаешь commit файлу А. Т.к. он был изменен на основе ревижина 334, то коммит пройдет ОК.

при этом перед шагом А ты можешь все-таки воспользоваться локами. иначе есть шанст, что ты никогда не сделаеш коммит, ибо пока готовишь коммит, кто-то закомитил свое :) но это только в больших коллективах само собой.

> 1. сделать update для A.
> 2. скорее всего будет автоматический merge, но может быть
> и конфликт. в итоге в локальной копии у тебя будет лежать
> А, в котором будут изменения сделанные Ваней и твои. Причем
> Ванины уже на сервере, твои только у тебя.
> 3. далее делаешь commit файлу А. Т.к. он был изменен на
> основе ревижина 334, то коммит пройдет ОК.

тут пропущен пункт 2.5 - если файл в конфликте, то нужно поправить его и привести в вид, в котором он должен быть, а затем сделать resolve
в противном случае коммит не удастся

> тут пропущен пункт 2.5 - если файл в конфликте, то нужно
> поправить его и привести в вид, в котором он должен быть,
> а затем сделать resolve
> в противном случае коммит не удастся

да верно, забыл.

← →
2E3639BF (2007-10-07 22:09) [22]

— Но если они снова не захотят? — спросил Див Симбел.

Поможет ли тут система сопровождения версий? Найти похожие ветки