alex55555а в вашем мелко-мягком мире видимо даже просто скопировать такой плагин не сумели, вот ты и плюёшься.

Дык это и есть достоинство гита - то, что он везде есть и всеми поддерживается и полно инфы.

Второе достоинство - работа в отключке. Можно хоть в самолете писать код и коммитить мелкими порциями (мелкими порциями очень удобно даже не в отключке - получается такое локальное undo).

hVosttЗадан был конкретный вопрос, какие есть недостатки у git по сравнению с svn?


Если интересно, то можно почитать тут: https://svnvsgit.com/ я с SVN работал давно давно пожэтому не могу сказать, что актуально а что нет.

У меня сложилось впечатление, что там нужно обязательно рассказывать о том, что ты сделал с файлами (переимнование гит определяет сам, например).

Еще интересно какой форкфлов у тех кто работает на SVN. Применяют ли фичабранчи.

alex55555Вы хотите сказать, что не сумели нагуглить инфу по SVN? Я удивлён такому повороту.


Неа. Я хотел сказать что все более распространенное обладает преимуществом перед менее распространенным.

Eclipse + plugin = всё то же самое. Эклипсина ведёт локальную историю, можно сравнивать, восстанавливать и т.д. Когда надоест "быть в отключке" - коммитишь да и всё.

Т.е. сам по себе svn это не умеет. Надо еще что-то, что является грубо говоря тоже системой контроля версий (интересно, с какими ограничениями).

alex55555Что там за "флов" и другие матерные слова - я не знаю, но это тоже есть в SVN. Он не вызывает желания что-то менять, потому что просто работает и не создаёт гемороя.

Есть разные способы работы с СКВ - вы создаете ветку на каждую фичу?

hVosttНеинтересно, там много привирания фактов.
Просто фанаты svn-а всё пытаются "оправдать" его перед гитом.
Если бы не было нужды оправдываться, таких сайтов бы не было.


Вот, я например, не знаю чем они друг от друга детально отличаются. Интересно бы было почитать сравнение, но по быстрому нашел только это. Жалко что вы не хотите аргументировать свою точку зрения.

hVostt1. https://habr.com/post/320704/
2. http://rezvanov.info/2010/06/21/pochemu-vy-dolzhny-ispolzovat-git-vmesto-subversion.html
3. http://cemick.blogspot.com/2015/08/svn-git-git.html


Спасибо! Я сам пользуюсь гит и svn скорее всего не не буду (давно пользовался)

1. - читал, для меня не релевантно (все эти разницы в скорости в несколько секунд и прочее) не рассматриваются все доводы статьи , на которые пытаются ответить.

2. 2010 год, за 8 лет оба софта могли измениться. Секунды при создании веток слегка релевантны, интересен был бы опыт использования чего-то типа gitflow c subversion - кроме разницы секунд есть ли разница (насколько удобно мерджить ветки).

3. Поновее. Я так понял что основной довод - удобство локального манипулирования с бранчами без влияния на общий репозиторий. С моей точки зрения локальность и отдельность это разные вещи (условно можно селать отдельную папку персональных бранчей на сервере и никого это не будет парить).

alex55555WebSharperвы создаете ветку на каждую фичу?
Нет, зачем так часто?

Если вы их не создаёте в системе контроля версий, то логически они у вас есть, но вы не пользуетесь возможностями СКВ чтобы ими управлять. Вы уже вверху сказали что у вас за локальную историю отвечает эклипс. Так же есть задачи бекапа, мерджа с новыми изменениями и прочее. Когда СКВ знает больше деталей ей проще это сделать. Ещё можно легко переключаться между версиями кода в одном и том же окружении.

alex55555Что конкретно становится неуправляемым? Что конкретно я с этого теряю? На мой взгляд я приобретаю время, сэкономленное на создании ветки из-за дополнительной формочки для клиента.


Когда вы модифицируете рабочую копию у вас уже логически есть ветка в коде (набор измненений который имеет свою отдельную историю). Я уже не помню как в svn, а в git - создание ветки - это одна команда (более того, в некторых инструментах ветка автоматически создается нажатием на кнопочку по баге или фиче). Это очень быстро и не дорого.

И уменьшаю общую сложность, что как раз повышает управляемость. А вы каким макаром повышая сложность чего-то там добиваетесь?
WebSharperВы уже вверху сказали что у вас за локальную историю отвечает эклипс.
Это к чему вообще?


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

Если использовать бранчи для фич, то просто тем же инструментом можно делать те же операции что локально, что в общем репозитории.

WebSharperТак же есть задачи бекапа, мерджа с новыми изменениями и прочее.
Бэкап в SVN уже автоматом есть, что я ещё с ним должен делать? Мержит народ вполне самостоятельно и меня по этому вопросу не беспокоит, что опять я эдакое упустил, что бы было много лучше (примерно как у вас)?


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

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

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


Бывают разные процессы - я работал с vss, cvs, svn и git разными способами, но с svn давно и примитивно. Картинки есть вот тут https://www.atlassian.com/git/tutorials/comparing-workflows если вам интересно про работу фича бранчей, то можно прочитать про gitflow.

Ну и потом укажите, в каких местах этого процесса по вашему мнению можно "пользоваться возможностями СКВ чтобы ими управлять". А потом сравните с тем, что может SVN. Ну и увидите - всё управляемо.

Я вряд ли уже буду работать с SVN но народ выше жалуется, что работать с ветками не так удобно как с git.

alex55555WebSharperсоздание ветки - это одна команда ... Это очень быстро и не дорого.
Мусор тоже можно легко создать. Но зачем?

То есть это не аргумент.


Я отвечал на ваш аргумент, что тратятся ресурся на создание ветки.

WebSharperКаждый инструмент в данном случае адаптирован под свои задачи. Я могу скопировать весь прожект и работать с ним вообще без "контактов с центром", при этом у меня локально ведётся история и я могу по ней много чего делать. То же самое с полностью независимым прожектом (типа личная писанина). То есть вменяемая IDE (Eclipse) даёт одинаковые возможности хоть для индивидуалов, хоть для команды. Переход от одного вида разработки к другому просто элементарен - подключаем SVN и тягаем оттуда прожект - всё, далее просто работаем.


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


В случае с git-ом в обоих случаях (индивидуально/командно) нужно возиться с оной приблудой. В случае эклипсины для инди такого вообще не надо, что сложность как раз понижает.


Это достигнуто путем содания ограниченной версии подобной приблуды в IDE, а зачем, если можно просто встроить приблуду?

WebSharperЕсли использовать бранчи для фич, то просто тем же инструментом можно делать те же операции что локально, что в общем репозитории.
Зачем делать что-то обязательно через общий репозиторий?


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

Еще раз повторю поток действий - разраб пилит сколько хочет в IDE, в ней же он все свои фичи/бранчи как ему нравится ваяет средствами самой IDE.


Чтобы бранчи были в IDE - надо чтобы она была оболочкой над системой контроля версий - не важно встроенной или внешней.

Когда он наконец наигрался - делает мердж. К определённому моменту все, кто успел, мержат и далее прогоняются тесты с раздачей пряников. Если нужно откатить неудачное чьё-то решение - выдираем его по дате из SVN.


Изврат. Почему именно по дате - в svn есть ревизии и метки. Это я еще после этого не знаю современных процессов разработки :) ну вам уже объяснили.

Если нужно создать версию - создаём и группа разрабов уже портит не общий код, но именно версию (ну или бранч, если кому-то это нравится).


Теперь внимание! То же самое может делать и еднинчный разраб.

Ну здесь проблема из серии "раз в несколько лет накрылся диск".


Это не только диск - случайно сам стер файл. Написал скрипт который преобразует как-то исходники а потом понял что ошибся.

Раз в несколько лет переделать труды за один день - никакой проблемы не вижу. А вот добавлять тулзу, которую нужно дополнительно ласкать каждый божий день - ну её такую требовательную подальше.


Ну да добавлять незачем. А если это легко сделать той же самой тулзой, то это приятная возможность.

Ну как бы просто делим народ на группы, а в пределах группы стараемся разделять взаимное влияние (между группами вообще влияние минимально). А если что-то обязательно нужно совместно - коммитим до тестов и балуемся, а потом ещё тестами накрываем.


Извините, без взаимного влияния это просто отдельные не связанные друг с другом продукты. А если мы поделили народ на группы, то разные люди внутри одной группы получается тоже должны сливаться. Если длинная фича то проще периодически подмердживать чужие измнения чем в конце обнаружить что разработка ушла вперед и теперь надо что-то переделывать.

См также сравнение component teams VS feature teams.

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


Так никто и не говорит что именно вашу команду с вашим процессом работы надо куда-то срочно переводить. Вполне возможно, что вам вполне подходит то, что есть. Мы просто изучаем разные возможности.

alex55555Кто сказал "повторять"? Вы хорошо подумали?


IDE занимается хранением версий. Система контроля версий занимается хранением версий. Следовательно первое содержит подмножетсво второго, нет?

WebSharperЭто достигнуто путем содания ограниченной версии подобной приблуды в IDE, а зачем, если можно просто встроить приблуду?
Это решали разработчики IDE. Думаю им было гораздо проще так сделать.


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

WebSharperЧтобы бранчи были в IDE - надо чтобы она была оболочкой над системой контроля версий - не важно встроенной или внешней.
Она - клиент. Вы путаетесь в базовых понятиях.


Напомним, что мы говорим про локальные изменения и локальные бранчи. Так же оболочка есть разновидность клиента. По крайней мере одно из значений этого слова.

WebSharperПочему именно по дате - в svn есть ревизии и метки.
Там ещё и сам юзер есть. Вот ведь как бывает, думаешь показать себя умным, а самое просто решение упускаешь.


Это не однозначно идентифицирует изменение. Обычно есть багтрекер в котором регистрируется фича и есть идентификатор изменения, который идентифицирует заливание фичи в СКВ (в гит это хеш коммита а в SVN - наверное идентификатор ревизии). А в багтрекере ссылка на этот идентификатор. Проще откатывать по идентификатору - потому, что это однозначно идентифицирует изменения. То есть разница такая как между "Прозови Васю к обеду" и "Позови к обеду сына Пети рожденного в 1968 году" - вторая фраза длиннее и менее однозначна.

WebSharperЭто не только диск - случайно сам стер файл. Написал скрипт который преобразует как-то исходники а потом понял что ошибся.
У нас таких шаловливых скриптописателей дальше собственного писюка не допускают. Хотя не знаю как у вас, может вам и гит для того нужен, что бы такие шалости вычищать?


Вот у вас есть UNDO в IDE - вы шаловливый кодописатель значит? Напомню, что мы говорим про локальную историю версий. Считайте что у вас есть UNDO про которую знает не только IDE но и вообще все программы.

WebSharperИзвините, без взаимного влияния это просто отдельные не связанные друг с другом продукты.
Ну ладно, будь по вашему - назовём фронт и бэк "отдельными" продуктами.


У вас фронт и бек никак друг на друга не влияют? Вообще?

WebSharperЕсли длинная фича то проще периодически подмердживать чужие измнения чем в конце обнаружить что разработка ушла вперед и теперь надо что-то переделывать.
Ну если через задний проход что-то делать - да, тогда и разработка и всё остальное уйдёт вперёд.


Вы сами выше говорили. "Если нужно создать версию - создаём и группа разрабов уже портит не общий код, но именно версию (ну или бранч, если кому-то это нравится).". Или у вас после создания бранча остальная разработка останавливается?

WebSharperВполне возможно, что вам вполне подходит то, что есть.
А вот с этого стоило бы начинать ваши речи. При чём - каждый самоуверенный коммент в длинном списке выше.

С моей точки зрения это нечто само собой разумеещееся.