|
|
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Являюсь Delphi - разработчиком. Слышу уже много раз про такое чудо, как системы контроля версий. Кажется, что это решение всех проблем и серебряная пуля. Но вот почему-то у меня никак с ними не получается и хотелось бы понять, что я делаю не так. На данный момент сместо СКВ использую WinMerge - чтобы сравнить разные версии своего приложения. Как мне поможет СКВ - если: 1) Куски кода часто мигрируют между файлами. Например, функция была расположена в одном модуле, перенесла её в другой. Сами модули могут переименовываться и мпенять своё местоположение в структуре каталогов. 2) Файлы проекта часто переименовываются - например, модуль uAddCustomer.pas - переименовано в uAddClient.pas и перемещено из папки \Units в папку \BonusUnits 3) Переменные периодически переименовываются. Например, в проекте переменная называется ShowHints и присутствует в 220 модулях проекта. Потребовалось переименовать её в ShowHints2 - чтобы проверить и обьработать все куски кода, где она используется. Имя переменной оставлено в итоге ShowHints2. Бывают ситуации (и не так уж редко) - когда подбирается более удачное название переменной - и старая переменная заменяется во всём проекте. 4) Куча справочных и прочих файлов, которые меняются и мешаются при Merge. 5) Правки есть не только в pas-файлах - но и в вордовских/excel-файлах проекта, а также в FDB файлах. Они СКВ никак не отслеживаются. 6) Иногда код из одних файлов (например кеуски кода в Блокноте, которые ранее были в проекте - например, скачаны из Интернета "про запас") перекидывается в pas-файлы, а потом сами файлы Блокнота удаляются, либо модифицируются и переименовываются/меняют своё положение. и еще куча различных ситуаций - сразу и не перечислишь В итоге уже через 7 дней после работы с проектом WinMerge показывает кашу и невозможно понять, где именно были сделаны реально важные изменения, а где мелкие правки, какой код, когда и куда был перемещён. Через 30 дней процедура Merge уже становится абсолютно бессмысленной, т. к. может показать, что изменения были, скажем, в 300 файлах. Но ведь тут пишут, что СКВ реально помогают и решают все проблемы, связанные с отслеживанием измннений в проекте. Но у меня вот не получается. Что я делаю не так? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2022, 23:48 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Наталья87, ККК, Ну или если серьезно, то коммитить надо ежедневно (компилирующийся проект) и после каждых серьезных пертурбаций, а никак не через 7 дней.... И это не только для Дельфи, а везде так ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.01.2022, 23:58 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Наталья87 Что я делаю не так? В вашей ситуации проще всего найти команду, которая уже использует системы контроля версий, и влиться в нее. Вас там всему научат. Если хотите учиться самостоятельно - возьмите настоящую систему контроля версий, а не то, что вам кажется похожим на нее. Я бы git рекомендовал, он мне больше всего нравится. И документация хорошая, и даже на русский переведена, если это вдруг для вас важно. Идея контроля версий простая. Вы написали какой-то код, сделали снимок состояния кода - "комит" (кстати, народ, как по-русски правильно - "комит" или "коммит"? ). Потом сделали какие-то изменения, сделали еще один снимок. И так далее. А потом уже с помощью системы контроля версий будете смотреть, что там вообще происходит, как меняется и т. д. К тому же, каждый комит можно (нужно) снабжать комментариями - что и зачем вы поменяли. Можно делать ветвления кода, возвращаться назад и т. д. Это не сложно, просто к этому надо привыкнуть. Комитить лучше почаще. Не каждые пять минут, конечно, но каждое логически завершенное изменение - имеет смысл. Например, исправили баг - комит. Даже если исправление состоит из одного символа. А если изменение все тянется и тянется и никак не дойдет до логического конца - ну просто раз в какое-то время, раз в день, например. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 01:44 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Никанор Кузьмич кстати, народ, как по-русски правильно - "комит" или "коммит"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 03:38 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Я использую Delphi7 и TortoiseSVN - клиент для svn. Для однопользовательской работы он же может сделать локальное хранилище. Мне потом понадобилась многопользовательская работа - я поставил отдельный сервер Subversion. Нужно не забывать что само хранилище тоже нужно бэкапить. У TortoiseSVN есть нормальный перевод интерфейса и документации на русский язык. И не только на русский. Документацию можно скачать отдельно, в PDF или HTML виде. https://tortoisesvn.net/support.html https://tortoisesvn.net/docs/release/TortoiseSVN_ru/index.html В начале там хорошо описаны основы работы с SVN. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 07:04 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Наталья87 4) Куча справочных и прочих файлов, которые меняются и мешаются при Merge. Файлы которые взяты извне, и в данном проекте не меняются - обычно нет смысла контролировать их в СКВ. Для этого их можно либо разместить вне папки под контролем СКВ, либо поставить в игнор в СКВ. Наталья87 5) Правки есть не только в pas-файлах - но и в вордовских/excel-файлах проекта, а также в FDB файлах. Они СКВ никак не отслеживаются. СКВ предназначены для контроля текстовых файлов. Бинарные тоже может, но только в виде поменялся/не поменялся. Что конкретно в них поменялось - увидеть не получится. Если "FDB файлах" - это база Firebird, то как правило нужно фиксировать не данные а метаданные. Можно например сделать экспорт всех метаданных в файл, и система будет смотреть, изменилось ли содержание файла. Но выгружать нужно всегда в одном и том же формате и одним и тем же инструментом. Если делать это через IBExpert то есть риск что формат поменяется (версии IBExpert выходят довольно часто) и тогда СКВ может не увидеть фактических изменений. Я изменения в метаданных провожу патчами - sql-файлы с кодом, который вносят изменения в базу. В самой базе фиксируется какой патч был выполнен последним, и ведется контроль что бы по ошибке не были наложены патчи с непоследовательной нумерацией. В итоге - сами файлы-патчи хорошо и сами по себе показывают что поменялось, но благодаря тому что они включаются в коммит, в котором сделаны изменения и в Delphi-коде - хорошо видно что поменяли в базе и в приложении. Практически все правки в проекте сначала записываю в виде задачи в системе контроля задач, у нас это Redmine. В коммите пишу номер задачи. В самой задаче пишу номер коммита в SVN (номер ревизии). Номер задачи так же пишу в комментариях в Dekphi-коде, и в комментариях объектов в базе, что бы можно было почитать для чего это сделано, и что было еще сделано по этой задаче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 07:20 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Наталья87, В свое время я пользовался teamsource, потом множеством других. Давненько это было. Хе-хе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 10:36 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
fraks [li]например git
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 15:27 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
git весьма прост для изучения и использования, если использовать его не через командную строку, а через какой нибудь приличный GUI. Я например использую GitKraken, он хоть и платный, зато имеет очень низкий порог входа и при этом очень мощный по своему функционалу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 22:24 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Dimitry Sibiryakov fraks [li]например git
Если у вас одна команда совместно работающая над проектом - лучше брать svn. Намного удобнее и проще со всех точек зрения. Если у вас несколько независимых команд работают над проектом - берите git. Он такой замороченный не просто чтоб свести своих пользователей с ума. Если работаешь в одиночку, да без сервера, то можно взять rcs - просто, легко, удобно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 22:41 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
White Owl Если у вас одна команда совместно работающая над проектом - лучше брать svn. Намного удобнее и проще со всех точек зрения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.01.2022, 23:26 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
asutp2 git весьма прост для изучения и использования, если использовать его не через командную строку, а через какой нибудь приличный GUI. Я например использую GitKraken, он хоть и платный, зато имеет очень низкий порог входа и при этом очень мощный по своему функционалу. Это относится ко всем СКВ. Кстати, полноценных халявных оболочек (не плагинов в IDE) я нашел не так уж и много: - SourceTree (git + mercurial (HG)) - Tortoise SVN/HG/Git - древний RapidSVN - чуть менее древний fuel-scm для Fossil (не пробовал) asutp2 White Owl Если у вас одна команда совместно работающая над проектом - лучше брать svn. Намного удобнее и проще со всех точек зрения. Нормальной нумерацией коммитов, отсутствием ректальной системы пуллреквестов, простой командной строкой @White Owl - rcs для топика с дельфями вряд ли подойдет - *nix-only ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 01:10 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
White Owl Ага. Вот только 99% процентов людей обожающих git и хающих svn не выходят за рамки возможностей svn. Если у вас одна команда совместно работающая над проектом - лучше брать svn. Намного удобнее и проще со всех точек зрения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 04:07 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Siemargl @White Owl - rcs для топика с дельфями вряд ли подойдет - *nix-only При отсутствии сети и серверов - rcs единственный выбор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 04:30 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Никанор Кузьмич White Owl Ага. Вот только 99% процентов людей обожающих git и хающих svn не выходят за рамки возможностей svn. Если у вас одна команда совместно работающая над проектом - лучше брать svn. Намного удобнее и проще со всех точек зрения. Git в принципе не может быть удобнее человеку. Он может быть удобнее компании-корпорации, но не отдельным разработчикам. Объясняю на пальцах: Subversion - это серверная система контроля версий. Не распределенная, а серверная. Тут каждый разработчик является полноценным maintainer'ом. В pull request'ах просто нет нужды. Репозиторий - один единственный и находится на сервере. Ты хочешь исправить код в паре исходников? Делаешь svn update (получаешь текущую ревизию себе в локальную копию), исправляешь код в той паре исходников, делаешь svn commit. Всё. Тебе система сама обнаружит что были изменения в каких-то файлах и отошлет их на сервер. И, кстати, не надо делать add каждый {неприличное_слово} раз, как в git... А вот в git предполагается что ты (человек-developer) делаешь изменения в своем репозитории, потом делаешь этот самый pull request и ждешь когда специальный человек-maintainer проверит твою работу и вытащит из твоего местечкового репозитория в репозиторий выше уровнем, ну или отправит эти изменения обратно на доработку. Это полезно для корпораций и с учетом что ты работаешь в команде отвечающей за малый участок большого проекта. Повторюсь: Каждый разработчик может залезть в любой участок проекта? Тогда бери svn. Хочешь разбить проект на модули и чтоб каждая отдельная команда работала только над своим модулем - бери git. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 05:19 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
White Owl Никанор Кузьмич пропущено... Я работал и с тем, и с другим. Мне лично git удобнее. Причем независимо от того, какое количество фич контроля версий мне нужно. Ну и пул-реквесты - как я понимаю, в svn отсутствуют. Git в принципе не может быть удобнее человеку. Он может быть удобнее компании-корпорации, но не отдельным разработчикам. Объясняю на пальцах: Subversion - это серверная система контроля версий. Не распределенная, а серверная. Тут каждый разработчик является полноценным maintainer'ом. В pull request'ах просто нет нужды. Репозиторий - один единственный и находится на сервере. Ты хочешь исправить код в паре исходников? Делаешь svn update (получаешь текущую ревизию себе в локальную копию), исправляешь код в той паре исходников, делаешь svn commit. Всё. Тебе система сама обнаружит что были изменения в каких-то файлах и отошлет их на сервер. И, кстати, не надо делать add каждый {неприличное_слово} раз, как в git... А вот в git предполагается что ты (человек-developer) делаешь изменения в своем репозитории, потом делаешь этот самый pull request и ждешь когда специальный человек-maintainer проверит твою работу и вытащит из твоего местечкового репозитория в репозиторий выше уровнем, ну или отправит эти изменения обратно на доработку. Это полезно для корпораций и с учетом что ты работаешь в команде отвечающей за малый участок большого проекта. Повторюсь: Каждый разработчик может залезть в любой участок проекта? Тогда бери svn. Хочешь разбить проект на модули и чтоб каждая отдельная команда работала только над своим модулем - бери git. А pull - это как раз аналог svn (cvs) update. Да, хочу заметить, что (как минимум для винды) у git вполне удобный родной гуи-интерфейс присутствует (уже). Архи-удобный тем, что ненавязчиво предлагает добавить новые файлы в репозиторий при коммите (не подпадающие под критерий игнорирования). Благодаря чему не надо "не забывать делать add". Так что даже никакие Tortise не нужны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 08:00 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
White Owl При отсутствии сети и серверов - rcs единственный выбор. Почему это? Например в том же TortoiseSVN в комплекте идет локальный сервер. С TortoiseGit думаю примерно так же. Git под винду тоже встречал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 08:08 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Для SVN есть только один бесплатный GUI клиент, которым в принципе как-то можно пользоваться - TortoiseSVN. Но он работает только под Windows. Для Linux есть RabbitVCS, ещё под Eclipse есть Subversive и Subclipse, но непонятно они ещё сопровождаются или нет. Единственный более-менее приличный клиент под Linux - SmartSVN, но он платный. Короче, есть большая проблема с GUI. Если TortoiseSVN по какой-то причине не подходит, то либо покупать SmartSVN, либо мучиться с бесплатными и полузаброшенными клиентами. Вторая большая проблема, что SVN просто капец как тормозит. Для теста запустил команду log на одном из репозиториев - занимает 10-15 секунд. Команда list - 2 секунды. Сравнить допустим две ветки в RabbitVCS/Subversive/Subclipse - наверное полминуты или минуту (отправляется просто гигантское количество запросов в репозиторий). Можно запускать сравнение и идти кофе заваривать. Но это полбеды, эта штука покажет список измененных файлов, а потом ещё чтобы посмотреть изменения в каждом из файлов нужно секунд 5-10. Это делает работу просто невыносимой. TortoiseSVN и SmartSVN работают почему-то быстрее, не сказать что летают, но терпимо. Наконец, третья проблема - не очень удобно ревьювить код. Одно дело я в gitlab вижу назначенные на меня pull-request, могу без особых сложностей и тормозов через веб-интерфейс посмотреть что изменилось в коде, написать комментарии. В SVN всего этого нет. Конечно как-то приходится пользоваться svn, но это больше мучение чем работа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 10:44 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
White Owl Git в принципе не может быть удобнее человеку. Он может быть удобнее компании-корпорации, но не отдельным разработчикам. ...пропущено... А вот в git предполагается что ты (человек-developer) делаешь изменения в своем репозитории, потом делаешь этот самый pull request и ждешь когда специальный человек-maintainer проверит твою работу и вытащит из твоего местечкового репозитория в репозиторий выше уровнем, ну или отправит эти изменения обратно на доработку. Это полезно для корпораций и с учетом что ты работаешь в команде отвечающей за малый участок большого проекта. Я вот например для нескольких своих личных проектов использую git без всяких проблем. Там я единственный разработчик, и нет никаких других специальных людей, но при этом ведутся разные ветки, точно также могу сделать pull реквест из одной в другую и т.д. И выше справедливо заметили, что git очень быстр. Сравниваю свой же опыт работы с svn, когда все реально тормозило не по детски.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 11:16 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Ну, как я и сказал, в SVN сделали быстрой ровно одну операцию: сравнение текущего состояния рабочей копии с последней закоммиченной. Всё остальное загубили насмерть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 14:39 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Извините за глупый вопрос. О каких пулл-реквестах в гите идет речь? Разве это к гиту относится? Я почему-то думал, что это фича всяких битбакетов-гитхабов-гитлабов. То есть вот я сделал локально git init, git branch, потом решил перенести изменения из бранча в мастер и... Тут как-то делается пулл-реквест? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 15:22 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Ares_ekb Конечно как-то приходится пользоваться svn, но это больше мучение чем работа. После git работа с svn вспоминается как ад. В git просто надо с самого начала более-менее понять как он работает и тогда с ним никакой проблемы работать нет - хоть с командной строки, хоть с gui - я, например, практически все делаю в нем из командной строки и не вижу в этом ничего сложного, gui обычно только для разруливания конфликтного мержа, или посмотреть какую-нибудь замороченную историю с кучей ветвлений. И я бы наоборот советовал изучение git именно с командной строки и начинать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 15:58 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Alexander A. Sak, да, согласен, это действительно фича не самого git, а разных надстроек. Но для svn я ничего подобного не видел. Обычно просто на словах говорится или где-нибудь в Jira пишется, что нужно посмотреть такую-то ветку или что по ней есть такие-то вопросы или что её можно мержить и т.п. Если бы для SVN был аналог GitLab, то требования к клиенту сильно упростились бы, не нужно было бы сравнивать ветки (в svn это работает достаточно медленно). То, что для SVN таких систем нет (может я о них не знаю) на мой взгляд это тоже минус. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 17:16 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Вспомнил ещё одну фичу, от которой за джва года использования svn уже успел отвыкнуть. В git сначала комитишь, потом обновляешься из основного репозитория и сливаешь ветки, разрешая конфликты. В svn сначала обновляешься, потом разрешаешь конфликты, потом комитишь. В svn есть шанс таким образом похерить свои изменения. У меня такого не было, но поначалу, когда волею судеб переходил с git на svn, то было страшно обновляться из репозитория, незакомитив свои изменения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 17:23 |
|
||
|
Системы контроля версий и Delphi
|
|||
|---|---|---|---|
|
#18+
Alexander A. Sak Извините за глупый вопрос. О каких пулл-реквестах в гите идет речь? Разве это к гиту относится? Я почему-то думал, что это фича всяких битбакетов-гитхабов-гитлабов. То есть вот я сделал локально git init, git branch, потом решил перенести изменения из бранча в мастер и... Тут как-то делается пулл-реквест? В SVN, насколько я помню, тоже надо руками делать svn add *.x И вообще про Мercurial забыли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.01.2022, 17:35 |
|
||
|
|
start [/forum/topic.php?fid=16&tid=1339595]: |
0ms |
get settings: |
22ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
448ms |
get tp. blocked users: |
2ms |
| others: | 397ms |
| total: | 938ms |
| 0 / 0 |
