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

Ну а про оперативную память я всё же не совсем зря говорил. У нас не возникает проблемы с тем, что кто-то забыл что он делал и ему требуется подсказка в виде подсветки тех строк, которые он менял. Может кто-то так делает, но всё же приоритет здесь в понимании проблемы, а не в тупом вырезании сделанного.
WebSharperя посмотрел на исторю нашего обсуждения и вижу что данный диалог начался с моей постановки задачи "времмено переключиться на срочную работу (делаешь длинную фичу, пришел баг, зафиксил, вернулся на место)" т.е. переключение на другую работу в самой постановке задачи.
Если "постановка" была несколько сообщений назад, то за это время тема могла сместиться довольно далеко. Для форумов (да и для личного общения) это обычная практика. Где конкретно и какой контекст использовать - зависит от участников. Я предпочитаю использовать последний контекст, то есть из моего и вашего последних постов. Вы же отвечаете то с использованием последнего контекста, то произвольно откатываетесь куда вам захочется (ну или вспоминаете, что хотели обсудить давно, но не получили ответа). Если вам хочется поднять именно старое сообщение (несколько сообщений назад), то было бы логично об этом упомянуть явно. Вы же этого не делаете. А потому я считаю себя свободным в продолжении следования именно последнему контексту. Но вас такое следование почему-то удивляет. А меня вот удивляет ваш непредсказуемый выбор контекста. Если бы вы явно указывали на смену направления, то проблемы бы не было. Но вы вспоминаете (точнее я вам напоминаю) о необходимости что-то дополнительно указывать, когда уже возник некий конфликт в понимании. Так оно вам, конечно, проще, но я-то отнюдь не готов к такой вашей лёгкости.
WebSharperПоищите с чего началось: ...
Вот что было в предыдущем сообщении:
WebSharperalex55555Ну так и в свн - выкачал прожект и пошёл гулять.
Откуда выкачал? Мы говорим про фича бранчи - то вместо чего у вас локальная история в эклипсе. Вы пока не закоммитили никаких изменений и выкачать их не сможете.
Здесь вы ввели условие "вы пока не закоммитили никаких изменений и выкачать их не сможете". Мы же говорили про копирование проект "вообще", то есть без указания на детали возможных ситуаций, когда у одного разработчика чешется нога и он пнул ею свой писюк, а тот взял и перестал работать. Но вы решили такую деталь ввести. С этой деталью можно легко справиться, но зачем в принципе нужно обсуждать какие-то очевидные мелочи? Зачем из общей ситуации делать убогую частность? Зачем погружаться в личные проблемы чешущего ногу разработчика? Надеюсь вы не будете настаивать на том, что ваше дополнение не является частностью? Иначе придётся указать вам на непонимание отличия частного от общего.
WebSharperили оно автоматически копируется но если файл занят, то может не скопироваться.
Ну да, я и говорил - может ещё атомная война случиться, тоже надо застраховаться.

Вы сочиняете крайне редко случающиеся события и просите их все предусмотреть. Если вам нравится в таких дебрях разбираться - разбирайтесь. Но у нас народ предпочитает просто с удобством делать дело. Разбираясь в способах защиты от метеоритов они бы до сих пор дела не сделали.

Всё копируется и проблемы практически не возникают. А если винда падает с синим экраном, то её перезагружают и продолжают копирование. Да, возможно это старомодно, нет космических костюмов с надписью "защищает от метеоритов", но это работает эффективно.
WebSharperКстати, как локальная история переезжает на другой комп? По быстрому я нашел только, что они хранятся в воркспейсе, т.е. не являются частью проекта так?
Локальная история переезжает вместе с воркспэйсом. Сменил разраб писюк - скопировал воркспэйс.
WebSharperГит это инструмент, он ничего не требует. Практика показывает что никакой проблемы нет. Возможно, для кого-то кто обрабатывает видео и почему-то хранит его в гите надо как-то следить за этим. Про разработчиков такого не слышал.
Я не работал с гитом достаточно для того, что бы указать вам на важные косяки, поэтому я привёл вам пример помойки. Вас пример не устроил из-за отсутствия глобальности. Типа если бы я указал на пример, схожий по важности с атомной войной, вы бы возможно и согласились, но раз тема менее серьёзна - вы смело её игнорируете, ссылаясь на "я с таким не встречался". Ну что-ж, таким образом вы можете обосновать абсолютно всё, что вам угодно. Только ценность такого обоснования равна нулю, ибо вы уходите от главного - от беспристрастного взгляда на возможные проблемы. На что я вам тут уже который раз открываю глаза. Но глаза так и остаются сонными...
WebSharperВот наш диалог

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

Ну во первых вы неполностью процитировали меня. А во вторых даже из указанного текста ясно, что ваш процесс скопирован с процесса наброса кода. Но проигнорировав подобное утверждение вы снова принялись вспоминать про code review. А между тем code review есть часть процесса. И от процесса зависит практически всё, а не только какой-то там code review. И этот момент вы полностью проигнорировали. В результате сконцентрировавшись на плохо поворачивающемся зеркале вы забыли об отсутствии двигателя в вашем авто. А я не забыл. И продолжал аргументировать именно упирая на отсутствие двигателя. Но вам важнее зеркало. Да, в таком случае у меня аргументов нет.
WebSharperНе могли бы вы по шагам описать как проводится codreview. Вот у вас есть кто-то кто сделал коммит в trunk, как дальше идет codereview (какими инструментами) и что делают, если участник не проходит его
Ещё раз напомню про зеркало. Ну и если оно так важно - участнику сообщается о проблеме и он её устраняет, разруливая при этом возможные конфликты в свн.
WebSharperДавайте разберемся. Вот у нас есть два коммита c1 и c2. с2 сделан после с1 и завивит от него. Оба коммита в trunk. Мы пытаемся откатить коммит c1, у нас возникает конфликт, так как c2 уже использовал что-то из c1 или модифицировал как-то те же строчки кода. Откатываем и C2 так же? (И так далее по цепочке)?
Коммиты бывают и в ветки, с которыми работают разработчики. Ну да это опять не укладывается в теорию "важного зеркала".

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

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

- Доктор, у меня провалы.
- Какие провалы?
- Провалы памяти.
- В чем они выражаются?
- Что выражается?
- Провалы.
- Какие провалы?


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

А вы как предпочитаете? Сказать что-то вроде - поциент, ты дурак? Вы вроде более спокойный. Так и оставайтесь в своём амплуа, и не переводите разговор в обвинения. Разве вам не нравится такой подход? Как минимум - вам что-то сильно мешает его применять. Ну да не буду продолжать с вами эту психотерапию.
WebSharperКогда я отвечаю я использую всю глубину контектов.
Забывая предупредить об этом собеседника.
WebSharperЭто условие вы ввели - предложением выкачивать из SVN; так как нельзя выкачать не закоммиченное
Я привёл пример простого решения, без множества деталей реализации. Без указания на последовательность нажатия кнопок, на процедуру вставки и удаления флэшки и на много чего ещё. И теперь из-за этого вы будете настаивать, что постое решение не работает? Вам самому сейчас над собой будет смешно.

Если кто-то копирует себе прожект, то он имеет свои изменения на локальной машине (так или не так?), далее он (как я и говорил, опуская последовательность нажатия кнопок) выкачивает прожект из свн, как есть, с тем, что есть. И копирует это всё на флэшку. Надо ещё подробнее объяснять, что ваше возражение совершенно не уместно? Или нужно разжевать тот факт, что не закоммиченное разработчиком находится на его машине, куда он и выкачивает весь прожект?
WebSharperДопустим, я сегодня работаю из дома а завтра в офисе - удобно ли переносить воркспейс целиком? Как поступают разрабочики в этом случае?
Обычно они на работе работают. Хотя может кто-то и таскает чего-то домой, но я не знаю. Только затраты на копирование воркспэйса мне не представляются ужасными.
WebSharperМеня пример не устроил тем, что это не является проблемой.
Ну а меня не устраивают ваши примеры, которые для меня не являются проблемами. И как быть? Вы за защиту от метеоритов, а я против.
WebSharperТак цитата по определению это не текст а только выдержка, мне непонятно, что значит "полностью процитировать".
Значит упустить важное.

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

Ну и наконец, ситуация с абсолютно точными определениями отсутствует даже в математике (аксиомы подводят, да и значение употребляемых слов спорно). И вы, понимая ситуацию, настаиваете на повышении степени строгости определений до уровня выше математического? А может проще вам попробовать подумать о возможном смысле? А то-ж я не справлюсь с безупречно строгим изложением.
WebSharperНе могли бы вы указать инструмент, которым вы проводите code review - т.е. вы коммитите код, что дальше происходит с коммитом. Кто его проверяет и какими средствами?
В общем случае - проверяют более опытные разработчики. Глазами. Без особых инструментов.
WebSharperЧто такое "ветки, с которыми работают разработчики" trunk? фичабранчи? релизбранчи? все они?
Не владею вашей терминологией, но скорее всего "релизбранчи".
WebSharperЕсли вы все равно делаете code review, почему бы не делать это перед коммитом? Чтобы никакого отката не было?
Потому что мы с людьми работаем. Человек у нас в основном всё правильно коммитит. А дурачков, за которыми нужно каждый раз подтирать, мы не держим. Отсюда мораль - нет у нас причины закрывать людей в клетку. Хотя может для вас это и привычно, но у нас как-то к людям получше относятся.
WebSharperПомойка, это когда все плодят ветки. У нас в свн только полезный код.

Вы же перед этим сами сказали, что откатываете коммиты после код ревью если выяснилось что код не подходит. Следовательно, у вас там в любой момент времени может быть не только полезный код, но и то, что еще не успели откатить правильно? Также есть какие-то ветки "с которыми работают разработчики"
Да, в свн могут быть небольшие косяки. И что? Мир от этого не падает. Где здесь проблема? И где здесь помойка? Вы улавливаете разницу между помойкой и небольшой проблемой?

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

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

Может вам и не интересно, во что выродилась тема, но я всё же обращу на этот печальный факт ваше внимание. И предложу в плане умственной гимнастики попробовать найти в себе силы не переспрашивать с требованием доказательств, но как-то в заметно меньшем объёме выделить суть разногласий, ну и изложить лишь её. Подозреваю, что это для вас непросто, но вы всё же постарайтесь, ведь иначе действительно (вашими же словами) - "разговор будет бессмысленный".
WebSharperЭто пример простого решения другой проблемы и она не относиться никак к разнице между svn и git - получить закоммиченные проект из СКВ можно на любой системы.
Здесь вы опять забыли, что сами утверждали. Вы заявили, что нельзя выкачать незакоммиченное. А теперь вы соскочили с темы и уже оказывается, что "это из другой оперы". То есть сначала вас устраивала ваша собственная тривиально опровергаемая аргументация, но когда вы получили это тривиальное опровержение - вам не понравилось, что оно оказывается "для другой проблемы". В итоге имеем - вы делаете заявление, я его опровергаю, вы заявляете, что опровержение на самом деле из неправильной "глубины контектов" (с орфографической ошибкой, ибо цитата), а потому предлагаете мне как-то извернуться и найти "правильную глубину", для чего я должен искать ваши слова и тыкать вас в них носом. Ну что-ж, считайте, что я повёлся и пошёл по бесперспективному пути тыкания вас носом. И как только я взялся за дело - сразу стал очевиден уровень демагогичности используемых вами уловок. Упрощённо - вы заявляете глупость, я вам на это указываю, вы оправдываетесь (не взирая на ваши собственные слова) какими-нибудь третьестепенной важности моментами вроде ухода от темы или отсутствия цитаты. Вопрос - можно ли хоть что-то доказать человеку, который забывает про свои собственные слова и оправдывается не относящимися к текущему обсуждению фразами, ссылаясь при этом на "всю глубину контекстов"?

В целом - ваш подход "на всю глубину контекстов" подменяет дискуссию демагогией. Если вы не остановитесь на этом пути - будете беседовать сами с собой.

WebSharperВы предложили переносить проект путем создания сетевой папки и через флешку. Потом вы подтвердили, что локальная история не является частью проекта, а частью воркспейса т.е. как я понимаю она не перенесется вместе с проектом.
И что из этого следует? Вы скачете "на всю глубину контекстов", но элементарный вывод не можете сделать. А я вам уже разжевал, как всё что надо, перенесётся куда надо. Всего лишь в предыдущем сообщении. Но вы забыли. Или не читали. Или не поняли. И как вам ещё объяснять? Попытка предложить перечитать привела к ступору в виде требований доказать кучу посторонних моментов цитатами. Что же ещё вам можно предложить?
WebSharperЭто вместо того, чтобы просто нажать на кнопочку "Синхронизировать" и получить ветку со всей историей разработки фичи.
Ещё раз отправляю вас на повторное чтение. Во время чтения вы должны понять следующее - речь идёт о копировании каталога (в случае без гит) против копирования репозитория гит (суть тоже каталога). И вот на это (отсутствующей) разнице вы строите какие-то теории, позволяющие ухмыляясь заявлять про "это вместо". То есть сами не понимаете, вместо чего, но ухмыляться не забываете, ага, это же важнее?
WebSharperРазница в том, что вы выдумали ваш пример (т.е. у вас нет опыта работы с git и фичабранчами) а я привожу те вещи которыми реально пользуюсь.
Пользуюсь, но не хочу замечать косяки.
WebSharperВы можете предположить, что есть другие люди с другими потребностями?
Предположить-то могу, но какие-то потребности из вашего текста вытекают... мягко выражаясь, неоднозначные.
WebSharperПозже я предположил что "они" это opensource но вы сказали, что я не понял.
И сколько ещё раз вы так будете передёргивать? Я говорил о непонимании того момента, про который писал. Вы же, пользуясь "всей глубиной контекстов", заявляете, что якобы я обвинил вас в непонимании чего-то другого. С точки зрения демагогии - нормальный уход от аргументов, противопоставить которым просто нечего. Но с точки зрения нормального обсуждения - вам давно пора признать, что вы спор проиграли. Ну это если вам знакомо такое понятие, как честность.
WebSharperПрич чем ту клетка?
Это про марс. А вы видимо с венеры?
WebSharperВы делаете codereview, вы комитите. Если первое делать перед вторым то не надо будет потом откатывать даже в редких случаях. Зачем делать первое после второго если все равно делаете и то и то?
Поищите в толковом словаре определение слова "редкость".
WebSharperЭто косяк не в svn а в том, что кто-то поленился набрать в гугле "svn code review tools" и выяснить, как это делать перед коммитами в своем любимом инструменте
Что бы означала столь многозначительная фраза? Перейму-ка я ваш подход.
WebSharperМожно таскать изменения на флешках и хранить в сетевых папках - как вы предлагаете с незавершенными фичами. Только неудобно.
Вот, наверное, единственно за весь огромный текст ваше вменяемое заявление по теме.

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

WebSharpergit лучше тем, что: 1. Он несколько больше распространен, следовательно проще найти людей и инструменты (т.е. я согласен для для команды, которая уже сидит на svn, возможно, это не играет роли, но для среднестатистической команды некоторое преимущество по данному авпекту имеет git. Ссылка на статистику приведена). Вы сказали что в мире java SVN поддерживается из коробки всеми основными IDE. Про людей ответили исходя из вашей ситуации (уже используете SVN и именно в Java, соответственно конкретно для вас это не релевантно) 1. поддерживает локальную работу (полностью) для вас, насколько я помню, этот аспект не важен 2. Эффективно поддерживает бранчи можно быстро переключаться

• переключение бранчей удобно для переключения задач (например, если во время работы над длинной фичей надо исправить ошибку, можно переключиться быстро на другую ветку исправить там ошибку смерджить в trunk, переключиться обратно и продолжить работу над исходной фичей).
• Тут мне хотелось бы уточнить, как вы поступаете в этой ситуации, потому, что в одном ответе было что-то про выделение каких-то файлов, а при дальнейшем обсуждении началось что-то про удаление. В git при использовании фичабранчей ничего этого делать не надо - просто при комитите все последние изменения (так как ветка отдельная, созданная на фичу, она ни на кого не влияет), переключаетесь на исправление ошибки, а потом обратно
это удобно для сравнения
• Для вас не нужна сравнительная отладка, вы все держите в голове или это нужно редко, а то, что нужно редко нельзя расценивать как плюс
Фича бранчи удобны для
• Резервного копирования
• Вы не преобразовываете код скриптами или не ошибаетесь, для истории в процессе разработки у вас есть локальная история Eclipse, да, она работает только с этой IDE и не совсем так, как SVN, но так как вы сидите только внутри Eclipse для вас это не релевантно.
Переноса кода на другую машину (полезно при работе из дома или при тестировании в другом окружении например)
Насколько я понял, вы сами из дома не работаете, но для переноса предлагаете использовать сетевые папки или флешки и переносить проект.
WebSharperОн несколько больше распространен Наверное, но здесь грань между плюсами/минусами вообще ничтожна. Давайте не будем цепляться за соломинку. А то-ж аргументы в таком духе вызовут в ответ что-нибудь типа "а свн старше! опыта больше! адское преимущество!" WebSharper 1. поддерживает локальную работу (полностью) Да, для выбирающих и не использующих привычные IDE это плюс. Хотя если немного напрячься, то к локальной работе можно подключить и свн, но просто это нам не надо. Только в результате имеем не "гит это может, а свн нет", но что-то вроде "с свн-ом обычно так не извращаются, но он это тоже может". WebSharper 2. Эффективно поддерживает бранчи Да, судя по вашим рассказам, всё выглядит менее затратно, нежели ветки в свн. Но опять же - ветки делать можно. Только обычно их столько никто не плодит. И мне кажется это вызвано процессом, а не инструментом. А раз у процесса к инструменту нет претензий - вот инструмент и не оптимизируют под минимум кнопок для веток. WebSharperФича бранчи удобны для... Это уже пример применения веток в некоем конкретном контексте (контекстах). Сначала же нужно решить - хотим ли мы вообще массово использовать ветки. Вы хотите. Мы не очень. Для вас это некие плюсы, для нас они не очевидны. Ваш список плюсов в итоге ссылается на ваш процесс, в котором то код по домам разносят, то внезапно теряют и при этом никогда не бэкапят на флэшки или диски. Организационно домашнюю работу можно организовать и с свн - делаем впн, цепляемся к свн из дома, ну и работаем. и тогда опять разница между гит и свн сведётся лишь к удобству тех или иных кнопочек, но отвечающих за абсолютно идентичную функциональность. Отсюда мораль - неужели мы будем обсуждать удобство или неудобство конкретных интерфейсов? А если кто-то новый плагин состряпает с другим интерфейсом, что тогда? WebSharperДальше мы обсудили codereview - я указал на функционал гитхаба. Вы сказали, что это для "набрасывания кода", это понятие вы не определили, а мои догадки признали неверными. Я непонимаю вашу точку зрения на этот счет. Удивлён столь упорному непониманию, но поясню. Набрасывание кода, это когда тысячи пользователей коммитят нечто внеплановое. То есть кто-то скачал к себе код и как-то этот код ему не подошёл, в результате этот некто взял и исправил код. А потом (дабы в следующем релизе иметь свои исправления) закомитил их в гит. И вот тысячи разнообразных правок, нередко ещё и конфликтующих друг с другом, валяются в гите и требуют вливания в общий релиз. Если бы это всё валилось в сразу в общак, то все, кто скачивает код, получили бы неработающее месиво (хотя бы из-за конфликтов). И потому поддерживающие гит админы вынужденно отсекают этот мутный поток сознания миллионов от поступления его продуктов прямо в головной мозг расшаренной системы. Без отсечения мозг умрёт. Сразу. Без вариантов. И есть вариант, когда нет тысяч мутно-осознанных желаний, но есть единый план развития системы. И тогда жизнь начинает играть новыми красками. И тогда отпадает необходимость в отсечении мути. И тогда получается наш процесс. И тогда становятся ненужными тысячи веток с мутно-внеплановыми изменениями. Вот в этом отличие двух процессов. И если вы так долго не могли это понять - мне очень жаль. WebSharperМеня заинтересовало, зачем вы коммитите перед ревью а не после, вы сказали что доверяете своим разработчиком поэтому откатываете редко. Ну и про процесс я тоже говорил. WebSharperДля вас неготовые изменения в репозитории, хотя бы даже логически отделенные от готовых являются помойкой, а не помойкой только если они физически на другой машиной. Для меня они в обоих случаях не являются помойкой, но при этом если есть code review я бы хотел, чтобы в trunk были изменения его прошедшие. Да, вы действительно не понимаете разницы между двумя процессами. Я не думал, что это серьёзно, но именно в такой момент вы и упёрлись. Тысячи случайных изменений - это помойка? Юному Васе из кружка "умелые руки" захотелось творить. И он натворил. Ну и естественно, решил увековечить. Ну и занёс. Все продукты своего по детски беспечного и мало что понимающего разума влил в коллективный общак. И как вы думаете, тысячи таки Вась могут создать помойку? WebSharperМне влом подтверждать все цитатами, поэтому подправьте, если я что-то упустил. Вы не переживайте, мне тоже в лом и я вас понимаю :) Но если не было бы в лом - ну во что выродилась бы тема? WebSharperЕсли вы не используете фича бранчи, вам придется другим способом переносить состояние своей работы. Но это же замечание по процессу, а не по инструменту. Выше я указал, что свн может вести много веток. А вот про удобство - не знаю, тысячи веток не плодил. Но допускаю, что нужно будет нажать больше кнопок. Только точно так же допускаю, что просто созданием новой версии плагина такая проблема будет решена кардинально - количество кнопок уменьшат ровно до аналогичного количества в гите. Потому что основа-то принципиально мало чем отличается. WebSharperДля меня тут меньше усилий, автоматизирована тупая работа и меньше возможности совершить ошибку. При условии работы у вас специфического процесса разработки с требованиями вести code review перед коммитом в общую ветку и т.д. Но если такое требование "расслабить"? WebSharperВ чем собственно косяк, я так и не понял. Много информации в репозитории. Часто она излишняя. Но вы сказали - для меня это не проблема. А когда я говорю так же, вы настаиваете на продолжении рассмотрения момента именно как проблемы. Выше я попробовал показать кашу в случае опен-сорсной разработки широко используемого проекта. У вас, конечно, меньше количество, но "поделив на коэффициент пи" вы сможете обнаружить нечто похожее и у вас. WebSharperА вот в случае с флешкой и сетевой папкой этого не происходит - инструмент не знает, зачем вы создали папку и когда она теряет смысл и не предлагает ее удалить. ну то есть фича гита состоит в том, что он предлагает удалить ветку, если по каким-то критериям она стала ненужной? Ну ладно, согласен с тем, что иногда это полезно. Но только почему вообще такая полезность возникла? Да именно из-за большого количества веток. Не было бы столько веток - не нужна была бы полезность. WebSharperЕсли подход A лучше подхода B, путь даже в редких случаях, а стоят они все равно одинаково Переход на процесс, более подходящий для подхода В, нарушает посыл "стоят одинаково". При этом процесс А (на мой взгляд) менее затратен, а потому переход на В вообще не имеет смысла - зачем удорожать работу лишними действиями из В? WebSharperreview перед а, не после коммита это не потому что svn не позволяет это так делать, а потому, что кто-то так организовал работу или так выбрал инструменты. Да, примерно так. То есть в нашей вселенной нет нужды в искусственно придуманном ограничении на просмотр кода перед коммитом. WebSharperЕще ощущения удобства зависит от привычки и от того, что человек успел попробовать. Да. Зависит. Но в лиспе действительно есть полезная фича (произвольный синтаксис), а вот в гите её нет. На стройке полезнее белаз, на скоростной трассе - порша или феррари. Правда в нашем случае мы сравниваем строительство с помощью белаза и маза. И при этом пока что практически не учитывали, что процесс строительства у нас разный. В этом сообщении я вроде уже много текста выделили именно не процесс. Ну и мне очевидно - корень разницы именно в процессе. А кокой там конкретно грузовик - да не имеет значения по большому счёту. Хотя лично у водителей могут быть предпочтения (по кнопочкам, по педалям). Но кнопочки с педалями лучше всё же отделять от стройки. Так что мы обсуждаем, кнопочки или стройку? Если стройку, то у камаза перед белазом каких-то резко снижающих себестоимость преимуществ нет. Вот разве что кнопочки.

WebSharperСначала же нужно решить - хотим ли мы вообще массово использовать ветки.
А как это решить, не рассматривая для чего их применять, в каких случаях они принесут пользу, а в каких нет?
Да, для решения нужно рассматривать процесс.
WebSharperНапример, если кто-то напишет плагин для переноса текущего состояния разработки в eclipse включая локальную историю с удобно синхронизацией и разрешением конфликтов это может быть даже удобнее чем git в этом аспекте. А вы считаете что достоинства и недостатки должны быть определены раз и навсегда и не меняться?
Нет, изменения должны быть. Но они должны следовать за процессом, а вы же предлагаете взять ваш процесс и на нём доказать, что гит лучше. Я же указываю - в других процессах преимущества гит теряются.
WebSharperДля вас opensource это "набрасывание кода". Кстати, судя по недавней статье, в yandex пользуются тем же github .
Ну раз какой-то перец из яндекса сказал - значит не может быть плохо!
WebSharperС моей точки зрения в любом случае хотелось бы контролировать входящий код на соответствие стандартам качества.
И у нас он контролируется. И проблем не возникает. Так если проблем нет, может и не стоит огород городить?
WebSharperЖелательно автоматизировано
Это что за автомат у вас код проверяет? ИИ изобрели? У нас пока такого нет, мы по дедовски - глазами.
WebSharperЛюди выше говорят, что с бранчами работа менее удобная.
Да я и сам с бранчами часто стараюсь не работать. Но суть-то в том, что это и не надо!
WebSharperУ вас то же самое на компе и в сетевых папках. В чем проблема того, что эта информация есть в репозитории или вне репозитория, если она логически отделена? Какую именно работу становится сложнее делать?
Представьте себе свою квартиру. Там много всяких вещей. Но зачем хранить вещи в квартире? Ведь можно их хранить на централизованном складе! И склад обеспечит быструю доставку по первому требованию. Как удобно! Какая разница, где лежат вещи? Если они логически отделены от чужих, да пусть хоть на другом конце планеты! Ведь правда?

Да, здесь есть небольшая натяжка, но принцип соответствует сути обсуждения на 100%.
WebSharperВыше вы обозначили в качестве проблемы опенсурса внеплановость изменений. Почему вы считаете, что у нас изменения внеплановые?
Я сказал, что вы заимствовали процесс, а остальное - ваше домысливание. Вы так и не рассказали про свой процесс, поэтому я предполагаю его похожим на хабовский. Ну и значит у вас валят всё, что попало на ревью, а кто-то потом сидит и разгребает. У нас же валят не всё, что попало. В этом разница.
WebSharperЕсли внеплановость это помойка, то соответсвно наличие и отсутсвие плана а не наличие или отсутствие брнчей должно быть критерием помойности?
Ну да, только к чему это?
WebSharperДа, наверное, была проблема с тем что личное пространство разрботчика содержит много веток и ему трудно переключаться, если работает с несколькими, но она решена. То есть сейчас ее нет и я не видел чтобы она когда-то была.
ну вот, вы хотя бы с тем, что проблема была согласились. Уже прогресс :)
WebSharperТ.е. по вашему экономия от устранения ревертов коммитов не окупит даже начальные затраты на внедрение подхода?
Не "даже начальные затраты", а перестройку всего процесса.

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

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

WebSharperТо есть svn удобнее git только тем, что он у вас привычен и уже используется? Мне кажется, вы недостаточно хорошо прочитали https://svnvsgit.com/ - там есть недостатки git, на которые не ответили не здесь ни на ответной статье на хабре.
Да, привычность есть важная штука. Плюс нет у нас позывов на обмен мест этапов за счёт привлечения нового инструмента.

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

А по техническим деталям действительно есть более глубокие сравнения.