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

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

alex55555Типа само раз в час? Нахрен такое надо.


Вообще, щас уже есть тулы для continuous testing - гоняют тесты прям во время набора кода. Раз в час это редко :)
Для эклипса нашел такое: http://infinitest.github.io/
В вижуал студию есть втроенный (Live Unit testing) и дополнение https://www.ncrunch.net/

Нужно затем же зачем подчеркивание ошибок в IDE - чтобы раньше о них узнавать. И еще обязательный прогон перед коммитов фичи - чтобы не вливать неготовое и видеть покрытие.

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


Мы просто переходим от общих утверждений к частным примерам.

а гит потребует отказа от привычной локальной истории


Почему?

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


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

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


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

alex55555WebSharperМы просто переходим от общих утверждений к частным примерам.
В данном случае - вы переходите. И уводите от первоначального вопроса (git/svn).


Так мы общаемся общими тезисами потом спускаемся на уровень частных примеров - я вроде обиспал в общем почему фичабранчи удобны. С конкретными примерами. Мне в ответ сказали, что это через задницу не объснив почему. Было отвлечение на технику выдирания неправильного коммита, но я там я описал как принято в мире гит (можно просто прокликать от бага/фичи багтрекере до кнопки revert).

Потому что в двух инструментах вести одну и туже историю гораздо затратнее. Вы на двух стульях никогда не пробовали сидеть?


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

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


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

Ну ладно, раз "мы просто пытаемся исследовать", то давайте ваш случай рассмотрим - в чём же плюсы гит конкретно в нём?


Большая распространенность. Из этого следует:
- поддержка инструментов и сервисов из коробки
- github - крупнейшее хранилище open source, чтобы работать с ним надо в какой-то мере изучить git
- больше людей на рынке, которые его знают (так же как для вас привычность вашей команде svn является плюсом, большая привычность для среднего человека на рынке git является плюсом)

Локальная работа:
- можно работть в отключенном состоянии или с плохим соединением
- эффективно используется в качетстве локальной истории версий (причем для всех инструментов сразу - а не только IDE)

Эфективная поддержка бранчей:
- быстро переключаться
- легко создавать
- легко объединять, очень удобно для разработки фича бранчами

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

Вроде если брать достоинства - то все перечислили, что обсудили.

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

Я прямо завидую завидую такой оперативной памяти. У я лично через несколько часов не так детально помню строчку кода, как сразу после написания. А еще если какие-то тесты сломались, то если обнаружить это сразу не надо ничего особо вспоминать - это просто последнее изменение. Т.е. ровно один кандидат на исследование.

А компилируете вы тоже через несколько часов?

alex55555А зачем информация о промежутке между коммитами? Она, конечно, есть, но какой в ней практический смысл?


Описался - В промежутке между коммитами.

В мире Java совсем немного IDE и все они отлично работают с svn, поэтому "поддержка инструментов" никому здесь плюсом не идёт. Просто одинаково.


* если использовать только IDE

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


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

Больше людей - это относительно какой ниши? В Java я думаю опять разница небольшая. Но даже если есть какое-то преимущество у гита, то сам процесс обучения использованию svn занимает микроскопическое время, особенно если основные концепции человек уже где-то сам изучил.


Концепции да, как и в обратную сторону. Но есть еще конкретне практические приемы работы, команды на кончиках пальцев и прочее.

[quot]
[quot WebSharper]
А что мешает работать в отключенном состоянии в той же эклипсине? Да хоть в блокноте. Когда подключился - тогда и обновился.


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

История "для всех инструментов сразу" опять нечто непонятное. История-то по файлам, а не по инструментам. Если проект содержит xml, html, java, js, css и т.д. и т.п., то все эти файлы отлично укладываются в СКВ.


И в случае распределенной СКВ она будет еще и локальной.

Зачем гит взялся решать те задачи, которые давно решены без него и интегрированы в средство разработки? Только потому, что писан он теми же линуксоидами, которые признают только командную строку и какой-нибудь vim. Ну да, от такой безрадостной жизни им пришлось сочинить себе весь тот функционал, который нормальные люди держат в IDE. Но зачем такое извращённое решение по дублированию функционала из-за любви к командной строке пропихивать в среду, где с командной строкой мягко говоря "не всегда" дружат? IDE и командная строка по сути антагонисты. И вот из противоположного мира к нам тянется костлявая рука гита. Зачем? Привнести vim в процесс разработки?


Командная строка и IDE прекрасно дружат между собой. Могут быть задачи которые проще решаются командой строкой, а могут быть GUI. Например, если нужны массовые изменения, то без скриптов и командной строки часто никак.

Увлечение бранчами повышает сложность понимания проекта. Вместо кучи бранчей проще использовать банальные локальные изменения, которые по сути тоже бранч, но это единственная ветка и с ней трудно запутаться.


Просто вы не знаете что работать с бранчами можно так же эффективно. (Приватные бранчи например)

WebSharperА компилируете вы тоже через несколько часов?
В Java компиляция ведётся пофайлово, то есть перекомпилируется только изменившийся файл, а все остальные не трогаются. Нет нужды считать часы между компиляциями.

Если у вас IDE и так тесты гоняет фоном, причем только те, которые относятся к делу, зачем их считать?

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


Ну в-общем приходится все равно к каких-то азах разбираться. С клиентскими либами иногда приходится понимать кто и когда и как поправил и в какую версию это ушло.

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


Хорошо, тогда аргумент "Нашей команде не подходит гит, потому, что его надо еще осваивать" не релевантен, да? ;)


Ну здесь опять про сложность. Пока я не вижу настоятельной необходимости так усложнять работу, что бы постоянно нужно было переключаться между ветками, как-то использовать промежуточные состояния, куда-то постоянно откатываться, ну и как следствие - необходимость вести БД по всем этим действиям (банально что бы не запутаться).


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

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


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

Это очень удобно. В винде например чтобы перезагрузить сервис надо пойти в соответсвтующую оснастку найти там глазами сервис и ткнуть кнопочки, а в powershell это restart-service msssql при этом работает автодополнение и вообще не надо ждать какой-то обратной связи на промежуточных шагах (искать глазами что-то на экране).

Так что никакой дружбы нет. Либо IDE, либо чёрный экран с командной строкой и убожеством ВиАй, почему-то называемым "редактором".


Консоль вполне себе интегрируется в современные IDE .

Ну вот опять сквозит желание всё бранчить. А я повторюсь - нафиг надо. Ибо сами запутаетесь.


Так я уже этим занимаюсь.

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

Я работал с VSS, SVN, TFS и GIT и мне есть с чем сравнить. А вот на чем основывается утверждение "с бранчами запутаетесь"? YНе может быть такого, что в SVN бранчи неудоьбные или вы их не умеете? Не может быть такого, что мы делаем разный софт и поэтому у нас разные потребности?

Кстати, а как у вас проходит code review? У нас примерно как через github т.е. есть фичабранч, на который делается пулл реквест, и в процессе ревью он обновляется. Так как это бранч можно в любой момент посмотреть историю, сравнить, что изменилось между итерациями и так далее. А как вы делаете это с SVN?

alex55555Обучить одного азам и сменить довольно кардинально стиль работы всей команды - это немного разные весовые категории. Удивлён, что для вас они обе кажутся одинаковыми.


Т.е. получается, что для новой команды небольшим преимуществом обладает. Кстати, посмотрел https://softwareengineering.stackexchange.com/questions/136079/are-there-any-statistics-that-show-the-popularity-of-git-versus-svn, по абсолютным величинам сейчас гит только-только обогнал SVN но тенденция вот такая

Да я не спорю, если приложить усилия, можно толковый словарь наизусть выучить. Но зачем? Вот на "зачем" я так и не увидел ответа.


Так вы его и предлагаете выучивать наизусть вместо использования инструмента.

В чём отличие от локальной версии для каждого разработчика? Пока он не закоммитил - у него ветка. И зачем ему ещё ветки?


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

- напрмер, надо сравнить поведение измененной версии и общей (переключился на trunk (он в git называется develop, пересобрал и смотришь))

- времмено переключиться на срочную работу (делаешь длинную фичу, пришел баг, зафиксил, вернулся на место)

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

Зачем другим вообще даже знать, что он там вытворяет в своей ветке? А когда надо - он сам разберётся со своей историей и всё как надо закоммитит.


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

WebSharperКоманда это маленький скрипт.
Суть была такой - программы надо писать в IDE. Вы заявили про скрипты. Это программы. Писать их в ВиАй - это извращение. А доказывать идентичность одной короткой команды целому скрипту - это уход в рассуждения о не относящихся к делу деталях.


Я пользуюсь командами и вообще не пользуюсь VI. В IDE они есть.

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


Я говорил про скрипты и команды по массовому преобразованию кода. Перед некоторыми такие задачи возникают и часто их легче решать командами и скриптами. Если уметь, конечно.


На ненужном повышении сложности. Я уже говорил.


В чем именно повышение сложности?

WebSharperКстати, а как у вас проходит code review?
Делается коммит и он проверяется. Здесь, наверное, стоит заметить, что коммит - это не смертельно. Возможно это и есть ваш тайный страх. Плохой коммит вреден, если он идёт к пользователям. У нас тоже есть выделенные сервера - тестовый, стэджинг, продакшн. Это и есть ваши назойливые фичабранчи, точнее - реализация процесса с отклонениями, которые вылавливаются в промежуточных отстойниках.

В общем понял, вы скопировали чужой процесс, но не поняли, а зачем он вообще существует.

Т.е. code review используется только в опенсурс компаниях, потому, что там помойка - т.е. то место куда не пускают неправильные коммиты. В правильных компаниях "непомойка" - место куда пускаются все коммиты, а потом откатываются, если они неправильные.
(Кстати, интересно, не возникает ли в вашей практике с этим сложности - кто-то, например, использовал уже закоммиченный код или ее раз его изменил и просто так не откатишь?).

А code review это не тестирование, а тестовый сервер это не code review.

alex55555WebSharperнадо сравнить поведение измененной версии и общей (переключился на trunk (он в git называется develop, пересобрал и смотришь))
Изменения одного разработчика обычно не требуют таких сравнений. Просто "до него" всё работало, а "после него" перестало - это вполне очевидный признак.


А разбираться почему не надо?

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


Это ваши теоретические измышления. Ничего не надо синхронихировать в процессе переключения и крыжить. Когда переключаете бранчи у вас рабочая копия автоматически синхронизируется. Надо только закоммитить последние изменения (напрминаю, что у нас распроделенная СКВ и фича бранч т.е. после коммита можно их вообще никому не показывать держать локально).

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


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

Дополнительная информация в СКВ. Банально это может быть давно ненужный хлам, но зачем-то оно здесь лежит, и что, всех заставить разобраться с личными ветками в гите? А когда они на своей машине пакостят - да и фиг с ними, никто не видит.


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

Т.е. никаких проблем с ними нет и я не слышал вообще никогда чтобы от кого-то это требовали.

WebSharperТ.е. code review используется только в опенсурс компаниях, потому, что там помойка - т.е. то место куда не пускают неправильные коммиты. В правильных компаниях "непомойка" - место куда пускаются все коммиты, а потом откатываются, если они неправильные.
Нет, просто продукт разный, но вы упорно гнёте своё (про другой продукт).


Какой продукт? Гитхаб? Разный с чем? Вы считаете что если в гитхабе есть некая фича то она нужна исключительно для опенсурса?

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

На какую локальную версию? У нас теперь есть два изменения. Одно неправильное другое правильное связанные друг с другом - причем чтобы откатить первое надо либо откатывать и второе (и все связанные) либо анализировать и переделывать чтобы оно работало без первого.

А на фига это все, если можно просто не пускать изменения без code review в общую ветку?

И еще - вы в курсе, что такое code review? При чем тут вообще "сломалось"? По-моему просто по переводу слов можно догадаться, что это не тестирование :)

alex55555WebSharperИзменения одного разработчика обычно не требуют таких сравнений. Просто "до него" всё работало, а "после него" перестало - это вполне очевидный признак.

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


Как вы перекомендовали разбираться без сравнений?

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


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

Перечитайте пожалуйста.

Вы опять решили указать дополнительные условия ПОСЛЕ того как я ответил. Это плохая привычка, обычно ею страдаю демагоги.


Поищите с чего началось:
ВЫ: В чём отличие от локальной версии для каждого разработчика? Пока он не закоммитил - у него ветка. И зачем ему ещё ветки?
Я: Так фичабранч это и есть одна ветка - только она управляется системой контроля версией. Я уже говорил, что гораздо легче обновляться на чужие изменения, делать бекап в общий репо. Еще забыл две вещи упомянуть - переключение между бранчами:

- напрмер, надо сравнить поведение измененной версии и общей (переключился на trunk (он в git называется develop, пересобрал и смотришь))

- времмено переключиться на срочную работу (делаешь длинную фичу, пришел баг, зафиксил, вернулся на место)

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


Т.е. мы обсуждаем отличие рабочей копии + локальной истории Eclipse и ветки для разработчика.
Соответственно поиск по форуму выигрывают 2:0 у даже у вашей оперативной памяти :). А у моей то и подавно!

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


Еще можно воспользоваться облачными хранилищами типа OneDrive или DropBox (в корпоративном исполнении конечно). Только при этом возникают всякие проблемы - или надо всегда самому все копировать или оно автоматически копируется но если файл занят, то может не скопироваться. И тогда возникают конфликты, которые надо разрешать. С этим система контроля версия справляется лучше. К тому же все интегрировано в IDE - нажатие кнопки или сочетания клавиш - и все синхронизировано.

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

WebSharperна практике никто никого не заставляет разбираться с личными бранчами
Вы уже в который раз либо не читаете мой текст, либо домысливаете что-то своё. Вам нечего сказать по существу и вы уводите в сторону?

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


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

WebSharperК тому же при мердже пулл реквеста инструменты сразу же приедлагают удалить бранч (либо содержат галку которую можно убрать).
Ну вот, они тоже осознали вред помойного подхода.


В этом нет никакой проблемы.

WebSharperКакой продукт? Гитхаб? Разный с чем? Вы считаете что если в гитхабе есть некая фича то она нужна исключительно для опенсурса?
И здесь вы опять то ли память оперативную переполнили, то ли делаете вид, что ничего не понимаете. Попробуйте всё же перечитать, что я говорил, а то повторять вам по десять раз в каждом ответе, что я говорил совершенно не то, что вам показалось, это как-то неприятно.


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

Я: Кстати, а как у вас проходит code review?
ВЫ: Делается коммит и он проверяется. Здесь, наверное, стоит заметить, что коммит - это не смертельно. Возможно это и есть ваш тайный страх. Плохой коммит вреден, если он идёт к пользователям. У нас тоже есть выделенные сервера - тестовый, стэджинг, продакшн. Это и есть ваши назойливые фичабранчи, точнее - реализация процесса с отклонениями, которые вылавливаются в промежуточных отстойниках.
Я: У нас примерно как через github
ВЫ: Так блин, это же процесс для массового наброса кода на вентилятор. Это не та серьёзно поставленная разработка, которую мы ожидаем видеть в нормальной конторе.


Т.е. во-первых, в ответ на то, как проводится codereview, вы начали описывать стейджинг серевера которые и есть фичабранчи.
Я заподозрил что
1) вы не знаете что такое codereview так как в ответе используете технологии для тестирования.
2) Я проедположил что вы назвали приведенную ссылку "процесс для массового наброса кода на вентилятор" так как оно используется github (сервиса, который, известен тем что хостит большое количество опенсурс проектов).

Я уточняю эти два пункта сейчас. Поэтому я задал вопросы.

Итак. Не могли бы вы по шагам описать как проводится codreview. Вот у вас есть кто-то кто сделал коммит в trunk, как дальше идет codereview (какими инструментами) и что делают, если участник не проходит его (особенно в случае ниже)

Одно неправильное другое правильное связанные друг с другом - причем чтобы откатить первое надо либо откатывать и второе (и все связанные) либо анализировать и переделывать чтобы оно работало без первого.

Я и говорил про вариант из вашего последнего предложения. А вы (уже - как всегда) так и не поняли.


Давайте разберемся. Вот у нас есть два коммита c1 и c2. с2 сделан после с1 и завивит от него. Оба коммита в trunk. Мы пытаемся откатить коммит c1, у нас возникает конфликт, так как c2 уже использовал что-то из c1 или модифицировал как-то те же строчки кода. Откатываем и C2 так же? (И так далее по цепочке)?

WebSharperА на фига это все, если можно просто не пускать изменения без code review в общую ветку?
Бесценностью code review, конечно, можно объяснить всё, что угодно, но мы предпочитаем объяснять всё конечной целью и результатом. Если софт качественный, то в каком порядке идёт code review и всё остальное - вопрос крайне маловажный.


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

WebSharperИ еще - вы в курсе, что такое code review? При чем тут вообще "сломалось"? По-моему просто по переводу слов можно догадаться, что это не тестирование :)
Я в курсе. Но так же я в курсе, что вы постоянно подменяете понятия. Ранее речь шла о "если что не так", на что я и отвечал. А code review может легко (и без заметных потерь) проводиться после коммита в свн, о чём я вам уже раз десять рассказал.

Так вы это писали на вопрос как у вас проводится codereview.

Итого, помойка - это когда кто-то создает личный бранч с своем пространстве имен. Непомойка, это когда в общий код закатывается непроверенный коммит, а потом проверяется и откатывается, если что-то не так.

Дмитрий МухВы ещё не устали? Кроме Вас никто тут уже ничего не читает.

Нет, меня это даже развлекает. Если я вам чем-то мешаю, то можем и прекратить :)