Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Управление процессом разработки ИС Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
 Re: SVN клиент  [new]
Дмитрий Мух
Member

Откуда: Зеленоград
Сообщений: 2530
WebSharper
Дмитрий Мух
Вы ещё не устали? Кроме Вас никто тут уже ничего не читает.


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

Нет, не мешает, просто полюбопытствовал. Если развлекает, то не буду мешать.
6 сен 18, 22:20    [21667531]     Ответить | Цитировать Сообщить модератору
 Re: SVN клиент  [new]
alex55555
Member

Откуда:
Сообщений: 2128
WebSharper
Как вы перекомендовали разбираться без сравнений?

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

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

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

Вот что было в предыдущем сообщении:
WebSharper
alex55555
Ну так и в свн - выкачал прожект и пошёл гулять.

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

Здесь вы ввели условие "вы пока не закоммитили никаких изменений и выкачать их не сможете". Мы же говорили про копирование проект "вообще", то есть без указания на детали возможных ситуаций, когда у одного разработчика чешется нога и он пнул ею свой писюк, а тот взял и перестал работать. Но вы решили такую деталь ввести. С этой деталью можно легко справиться, но зачем в принципе нужно обсуждать какие-то очевидные мелочи? Зачем из общей ситуации делать убогую частность? Зачем погружаться в личные проблемы чешущего ногу разработчика? Надеюсь вы не будете настаивать на том, что ваше дополнение не является частностью? Иначе придётся указать вам на непонимание отличия частного от общего.
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
Итого, помойка - это когда кто-то создает личный бранч с своем пространстве имен. Непомойка, это когда в общий код закатывается непроверенный коммит, а потом проверяется и откатывается, если что-то не так.

Помойка, это когда все плодят ветки. У нас в свн только полезный код. У вас - миллион веток, в которых никто разбираться не будет. Да, диски большие, чего их жалеть. Но помойка-то налицо.
7 сен 18, 12:35    [21668036]     Ответить | Цитировать Сообщить модератору
 Re: SVN клиент  [new]
WebSharper
Member

Откуда:
Сообщений: 484
alex55555
WebSharper
Как вы перекомендовали разбираться без сравнений?

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


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

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



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


Откуда вы вообще взяли эти удаления.

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

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


Я использую весь контекст на всю глубину вложенности. Иначе будут получаться диалоги типа

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


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


Когда я отвечаю я использую всю глубину контектов. Т.е. мы сейчас сравниваем svn и git, вы попросили объяснить преимущества гит, я вас написал, что удобно использовать фича бранчи, написал почему. К одному из этих почему возникло разногласие. Но это в контексте фича бранчей.

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

Вот что было в предыдущем сообщении:
WebSharper
пропущено...



Следуя вашей же логике вы не должны не удалять сообщения а оставить весь контекст.

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

Здесь вы ввели условие "вы пока не закоммитили никаких изменений и выкачать их не сможете".


Это условие вы ввели - предложением выкачивать из SVN; так как нельзя выкачать не закоммиченное, этим предложением нельзя воспользоваться. (В случае фичабранчей соответственно мы можем им воcпользоваться так как можем коммитить работу в процессе а не только завершенную)

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


Рассматривались две ситуации. В этой ветке обсуждения про перенос работы на другое устройство, например работы дома.
Бекап был но я тоже описывал не пинание ногой. Похоже уверенность в совершентстве оперативной памяти может быть в двух случаях 1) она совершенна 2) отсутствует контроль четности ;)

С этой деталью можно легко справиться, но зачем в принципе нужно обсуждать какие-то очевидные мелочи?


Мы сравниваем две системы контроля версий. На каком-то уровне общности они вообще совершенно одинаковые. Но если речь идет об удобстве, то надо рассматривать и частности.

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


Так это и способ не париться с этими частностями - тем что софт берет разруливание на себя :)

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

Локальная история переезжает вместе с воркспэйсом. Сменил разраб писюк - скопировал воркспэйс.


Допустим, я сегодня работаю из дома а завтра в офисе - удобно ли переносить воркспейс целиком? Как поступают разрабочики в этом случае?

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


Меня пример не устроил тем, что это не является проблемой.


WebSharper
Вот наш диалог

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

Ну во первых вы неполностью процитировали меня.


Цитата ЦИТА́ТА Женский род Точная, буквальная выдержка из какого-н. текста.

Так цитата по определению это не текст а только выдержка, мне непонятно, что значит "полностью процитировать".

А во вторых даже из указанного текста ясно, что ваш процесс скопирован с процесса наброса кода.


Не могли бы вы определить что такое "наброс кода"? Я пытаюсь угадать что вы имели ввиду и, похоже, у меня не получается.

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

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


Не могли бы вы указать инструмент, которым вы проводите code review - т.е. вы коммитите код, что дальше происходит с коммитом. Кто его проверяет и какими средствами?

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

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


Что такое "ветки, с которыми работают разработчики" trunk? фичабранчи? релизбранчи? все они?

Далее я лишь могу повторить то, что говорил ранее - механический откат есть глупая работа.


Если вы все равно делаете code review, почему бы не делать это перед коммитом? Чтобы никакого отката не было?

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

Помойка, это когда все плодят ветки. У нас в свн только полезный код.


Вы же перед этим сами сказали, что откатываете коммиты после код ревью если выяснилось что код не подходит. Следовательно, у вас там в любой момент времени может быть не только полезный код, но и то, что еще не успели откатить правильно? Также есть какие-то ветки "с которыми работают разработчики"
7 сен 18, 15:32    [21668292]     Ответить | Цитировать Сообщить модератору
 Re: SVN клиент  [new]
alex55555
Member

Откуда:
Сообщений: 2128
WebSharper
При чем тут удаление вообще?

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

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

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

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


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

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

Забывая предупредить об этом собеседника.
WebSharper
Это условие вы ввели - предложением выкачивать из SVN; так как нельзя выкачать не закоммиченное

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

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

Обычно они на работе работают. Хотя может кто-то и таскает чего-то домой, но я не знаю. Только затраты на копирование воркспэйса мне не представляются ужасными.
WebSharper
Меня пример не устроил тем, что это не является проблемой.

Ну а меня не устраивают ваши примеры, которые для меня не являются проблемами. И как быть? Вы за защиту от метеоритов, а я против.
WebSharper
Так цитата по определению это не текст а только выдержка, мне непонятно, что значит "полностью процитировать".

Значит упустить важное.

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

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

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

В общем случае - проверяют более опытные разработчики. Глазами. Без особых инструментов.
WebSharper
Что такое "ветки, с которыми работают разработчики" trunk? фичабранчи? релизбранчи? все они?

Не владею вашей терминологией, но скорее всего "релизбранчи".
WebSharper
Если вы все равно делаете code review, почему бы не делать это перед коммитом? Чтобы никакого отката не было?

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


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

Да, в свн могут быть небольшие косяки. И что? Мир от этого не падает. Где здесь проблема? И где здесь помойка? Вы улавливаете разницу между помойкой и небольшой проблемой?
7 сен 18, 18:08    [21668494]     Ответить | Цитировать Сообщить модератору
 Re: SVN клиент  [new]
Siemargl
Member

Откуда: 010100
Сообщений: 6319
Тема выродилась в спор сапожников, каким молотком правильнее забывать гвозди.
7 сен 18, 22:30    [21668688]     Ответить | Цитировать Сообщить модератору
 Re: SVN клиент  [new]
WebSharper
Member

Откуда:
Сообщений: 484
alex55555
WebSharper
При чем тут удаление вообще?

Вы очень много говорили про откаты. Разве нет?


Да, но не в этом диалоге. Вы требуете от меня дублировать в каждом сообщении контекст, а сами не соблюдаете своих же рекомендаций.

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


Ну да, про них и речь. И в этих случаях это очень полезно.

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


Каждый конкретный случай - редкость. Но таких разновидностей случаев очень много.

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


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

А вы как предпочитаете? Сказать что-то вроде - поциент, ты дурак?


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

Вы вроде более спокойный.


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

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


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


WebSharper
Когда я отвечаю я использую всю глубину контектов.

Забывая предупредить об этом собеседника.


Считайте что вы предупреждены. :)

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


Это пример простого решения другой проблемы и она не относиться никак к разнице между svn и git - получить закоммиченные проект из СКВ можно на любой системы.

Вот я вам напомнил что и в какой последовательности обсуждали, а вы проигнорировали.
Мы говорим о разнице git и subversion, о том, что git лучше и быстрее работает с ветками, поэтому там приняты фича бранчи, которые удобно использовать в частности и для переноса изменений. Вы согласились с тем что такой фича бранч все равно что состояние вашей рабочей копии И локальная история эклипса. Таким образом перенос фича бранча на другую машину должен быть эквивалентен переносу локальной рабочей копии и локальной истории. Вы предложили переносить проект путем создания сетевой папки и через флешку. Потом вы подтвердили, что локальная история не является частью проекта, а частью воркспейса т.е. как я понимаю она не перенесется вместе с проектом.

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


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

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


Т.е. вы так не делали и сравнить удобство не можете.

WebSharper
Меня пример не устроил тем, что это не является проблемой.

Ну а меня не устраивают ваши примеры, которые для меня не являются проблемами. И как быть?


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

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

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


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

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


Мне хотя б чтобы понятно было. Про "абсолютно точно" я даже не мечтаю.

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


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

WebSharper
Если вы все равно делаете code review, почему бы не делать это перед коммитом? Чтобы никакого отката не было?

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


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

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

Да, в свн могут быть небольшие косяки.


Это косяк не в svn а в том, что кто-то поленился набрать в гугле "svn code review tools" и выяснить, как это делать перед коммитами в своем любимом инструменте :).

И что? Мир от этого не падает. Где здесь проблема? И где здесь помойка? Вы улавливаете разницу между помойкой и небольшой проблемой?


Так мы обсуждаем инструменты - тут разница только в удобстве. Мир не рухнет, если вообще не пользоваться системой контроля версий. Можно таскать изменения на флешках и хранить в сетевых папках - как вы предлагаете с незавершенными фичами. Только неудобно.
7 сен 18, 23:29    [21668705]     Ответить | Цитировать Сообщить модератору
 Re: SVN клиент  [new]
alex55555
Member

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

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

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

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

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

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

WebSharper
Вы предложили переносить проект путем создания сетевой папки и через флешку. Потом вы подтвердили, что локальная история не является частью проекта, а частью воркспейса т.е. как я понимаю она не перенесется вместе с проектом.

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

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

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

Предположить-то могу, но какие-то потребности из вашего текста вытекают... мягко выражаясь, неоднозначные.
WebSharper
Позже я предположил что "они" это opensource но вы сказали, что я не понял.

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

Это про марс. А вы видимо с венеры?
WebSharper
Вы делаете codereview, вы комитите. Если первое делать перед вторым то не надо будет потом откатывать даже в редких случаях. Зачем делать первое после второго если все равно делаете и то и то?

Поищите в толковом словаре определение слова "редкость".
WebSharper
Это косяк не в svn а в том, что кто-то поленился набрать в гугле "svn code review tools" и выяснить, как это делать перед коммитами в своем любимом инструменте

Что бы означала столь многозначительная фраза? Перейму-ка я ваш подход.
WebSharper
Можно таскать изменения на флешках и хранить в сетевых папках - как вы предлагаете с незавершенными фичами. Только неудобно.

Вот, наверное, единственно за весь огромный текст ваше вменяемое заявление по теме.

И суть его такая - вам кажется, что нам неудобно. Ну ладно, я допускаю, что ваши привычки действительно заставят вас почувствовать неудобства, когда в одном случае из тысячи придётся нажать две кнопки вместо одной. Но наши привычки заставляют нас чувствовать неудобства, когда каждый раз мы вынуждены нажимать несколько лишних кнопок. Вот такая неуловимая разница между нашими в целом похожими восприятиями действительности.
8 сен 18, 14:51    [21668889]     Ответить | Цитировать Сообщить модератору
 Re: SVN клиент  [new]
WebSharper
Member

Откуда:
Сообщений: 484
alex55555
Может вам и не интересно, во что выродилась тема, но я всё же обращу на этот печальный факт ваше внимание. И предложу в плане умственной гимнастики попробовать найти в себе силы не переспрашивать с требованием доказательств, но как-то в заметно меньшем объёме выделить суть разногласий, ну и изложить лишь её.


Мне кажется, я уже приводит несколько раз. Хорошо. Давайте вы поправите свою точку зрения ниже, если я недостаточно

git лучше тем, что:

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

1. поддерживает локальную работу (полностью)
для вас, насколько я помню, этот аспект не важен

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

    • это удобно для сравнения
      • Для вас не нужна сравнительная отладка, вы все держите в голове или это нужно редко, а то, что нужно редко нельзя расценивать как плюс


  • Фича бранчи удобны для
    • Резервного копирования
      • Вы не преобразовываете код скриптами или не ошибаетесь, для истории в процессе разработки у вас есть локальная история Eclipse, да, она работает только с этой IDE и не совсем так, как SVN, но так как вы сидите только внутри Eclipse для вас это не релевантно.


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


    Дальше мы обсудили codereview - я указал на функционал гитхаба. Вы сказали, что это для "набрасывания кода", это понятие вы не определили, а мои догадки признали неверными. Я непонимаю вашу точку зрения на этот счет.

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

    Так же у нас возникло непонимание относительно помойки. Для вас неготовые изменения в репозитории, хотя бы даже логически отделенные от готовых являются помойкой, а не помойкой только если они физически на другой машиной. Для меня они в обоих случаях не являются помойкой, но при этом если есть code review я бы хотел, чтобы в trunk были изменения его прошедшие.

    Мне влом подтверждать все цитатами, поэтому подправьте, если я что-то упустил.

    WebSharper
    Это пример простого решения другой проблемы и она не относиться никак к разнице между svn и git - получить закоммиченные проект из СКВ можно на любой системы.

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


    Разница не в том, что где-то нельзя выкачать незакомиченное, а где-то можно, а в том, что в одном случае комитят то, что в другом не комитят.

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

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


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


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


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

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


    Мы говорим не о копировании репозитория а о синхронизации ветки в репозитории. В типичном случае для того, чтобы перенести состояние работы надо в гит + feature branches:
    1. Закомитить последние изменения
    2. Нажать на кнопку "синхронизировать" в IDE
    3. Дома нажать на кнопку "синхронизировать"

    В результате мы получаем совершенно такое же состояние ветки как и на работе. Включая историю (то, что в вашем случае будет локальной историей eclipse). Если вы забыли нажать и накодили, контроль версий сольет изменения - он знает какая версия отправная. Потому, что история копируется тоже.

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

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

    Для меня тут меньше усилий, автоматизирована тупая работа и меньше возможности совершить ошибку.

    Для всяких личных файлов, я флешки и сетевые папки тоже почти не использую, кстати. Вместо них - облачные хранилища типа OneDrive и DropBox. Это гораздо удобнее. Только это не контроль версий, и когда случается конфликт, то сохраняет две копии файлов.

    Пользуюсь, но не хочу замечать косяки.


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

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

    WebSharper
    Позже я предположил что "они" это opensource но вы сказали, что я не понял.

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


    Так мы про то же самое и говорим. Я не понял что такое "набрасывания кода". Вы можете продолжить фразу "набрасывание кода это..."

    WebSharper
    Вы делаете codereview, вы комитите. Если первое делать перед вторым то не надо будет потом откатывать даже в редких случаях. Зачем делать первое после второго если все равно делаете и то и то?

    Поищите в толковом словаре определение слова "редкость".


    Если подход A лучше подхода B, путь даже в редких случаях, а стоят они все равно одинаково (вы все равно комитите и все равно делаете codereview - т.е. время тоже) почему бы не выбрать подход A?

    WebSharper
    Это косяк не в svn а в том, что кто-то поленился набрать в гугле "svn code review tools" и выяснить, как это делать перед коммитами в своем любимом инструменте

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


    Отлично, что я оказался полезен. Смысл комментария в следующем: review перед а, не после коммита это не потому что svn не позволяет это так делать, а потому, что кто-то так организовал работу или так выбрал инструменты. Поиском легко найти инструментарий который не требует закомиченного кода, чтобы начать ревью.

    [quot]
    WebSharper
    Мир не рухнет, если вообще не пользоваться системой контроля версий. Можно таскать изменения на флешках и хранить в сетевых папках - как вы предлагаете с незавершенными фичами. Только неудобно.

    Вот, наверное, единственно за весь огромный текст ваше вменяемое заявление по теме.

    И суть его такая - вам кажется, что нам неудобно.
    [quot]

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

    Еще ощущения удобства зависит от привычки и от того, что человек успел попробовать.

    см также "Парадокс Блаба"

    Когда наш гипотетический Блаб-программист смотрит вниз на континуум мощности языков, он знает, что смотрит вниз. Менее мощные, чем Блаб, языки явно менее мощны, так как в них нет некой особенности, к которой привык программист. Но когда он смотрит в другом направлении, вверх, он не осознает, что смотрит вверх. То, что он видит, — это просто "странные" языки. Возможно, он считает их одинаковыми с Блабом по мощности, но со всяческими сложными штучками. Блаба для нашего программиста вполне достаточно, так как он думает на Блабе.
  • 9 сен 18, 02:43    [21669132]     Ответить | Цитировать Сообщить модератору
     Re: SVN клиент  [new]
    alex55555
    Member

    Откуда:
    Сообщений: 2128
    WebSharper
    git лучше тем, что:

    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, путь даже в редких случаях, а стоят они все равно одинаково

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

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

    Да. Зависит.

    Но в лиспе действительно есть полезная фича (произвольный синтаксис), а вот в гите её нет. На стройке полезнее белаз, на скоростной трассе - порша или феррари. Правда в нашем случае мы сравниваем строительство с помощью белаза и маза. И при этом пока что практически не учитывали, что процесс строительства у нас разный. В этом сообщении я вроде уже много текста выделили именно не процесс. Ну и мне очевидно - корень разницы именно в процессе. А кокой там конкретно грузовик - да не имеет значения по большому счёту. Хотя лично у водителей могут быть предпочтения (по кнопочкам, по педалям). Но кнопочки с педалями лучше всё же отделять от стройки. Так что мы обсуждаем, кнопочки или стройку? Если стройку, то у камаза перед белазом каких-то резко снижающих себестоимость преимуществ нет. Вот разве что кнопочки.
    9 сен 18, 15:32    [21669279]     Ответить | Цитировать Сообщить модератору
     Re: SVN клиент  [new]
    WebSharper
    Member

    Откуда:
    Сообщений: 484
    alex55555
    WebSharper
    Фича бранчи удобны для...

    Это уже пример применения веток в некоем конкретном контексте (контекстах). Сначала же нужно решить - хотим ли мы вообще массово использовать ветки.


    А как это решить, не рассматривая для чего их применять, в каких случаях они принесут пользу, а в каких нет?

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


    Ну да, речь про удобство.


    Отсюда мораль - неужели мы будем обсуждать удобство или неудобство конкретных интерфейсов? А если кто-то новый плагин состряпает с другим интерфейсом, что тогда?


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

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


    Теперь понятно. Для вас opensource это "набрасывание кода". Кстати, судя по недавней статье, в yandex пользуются тем же github. см также https://github.com/business .

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


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

    WebSharper
    Если вы не используете фича бранчи, вам придется другим способом переносить состояние своей работы.

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


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

    WebSharper
    В чем собственно косяк, я так и не понял.

    Много информации в репозитории. Часто она излишняя.


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

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


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

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


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

    WebSharper
    Если подход A лучше подхода B, путь даже в редких случаях, а стоят они все равно одинаково

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


    Т.е. по вашему экономия от устранения ревертов коммитов не окупит даже начальные затраты на внедрение подхода?
    А само по себе codereview, хоть и после комита, обязательно или по желанию?
    9 сен 18, 22:47    [21669448]     Ответить | Цитировать Сообщить модератору
     Re: SVN клиент  [new]
    alex55555
    Member

    Откуда:
    Сообщений: 2128
    WebSharper
    Сначала же нужно решить - хотим ли мы вообще массово использовать ветки.

    А как это решить, не рассматривая для чего их применять, в каких случаях они принесут пользу, а в каких нет?

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

    Нет, изменения должны быть. Но они должны следовать за процессом, а вы же предлагаете взять ваш процесс и на нём доказать, что гит лучше. Я же указываю - в других процессах преимущества гит теряются.
    WebSharper
    Для вас opensource это "набрасывание кода". Кстати, судя по недавней статье, в yandex пользуются тем же github.

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

    И у нас он контролируется. И проблем не возникает. Так если проблем нет, может и не стоит огород городить?
    WebSharper
    Желательно автоматизировано

    Это что за автомат у вас код проверяет? ИИ изобрели? У нас пока такого нет, мы по дедовски - глазами.
    WebSharper
    Люди выше говорят, что с бранчами работа менее удобная.

    Да я и сам с бранчами часто стараюсь не работать. Но суть-то в том, что это и не надо!
    WebSharper
    У вас то же самое на компе и в сетевых папках. В чем проблема того, что эта информация есть в репозитории или вне репозитория, если она логически отделена? Какую именно работу становится сложнее делать?

    Представьте себе свою квартиру. Там много всяких вещей. Но зачем хранить вещи в квартире? Ведь можно их хранить на централизованном складе! И склад обеспечит быструю доставку по первому требованию. Как удобно! Какая разница, где лежат вещи? Если они логически отделены от чужих, да пусть хоть на другом конце планеты! Ведь правда?

    Да, здесь есть небольшая натяжка, но принцип соответствует сути обсуждения на 100%.
    WebSharper
    Выше вы обозначили в качестве проблемы опенсурса внеплановость изменений. Почему вы считаете, что у нас изменения внеплановые?

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

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

    ну вот, вы хотя бы с тем, что проблема была согласились. Уже прогресс :)
    WebSharper
    Т.е. по вашему экономия от устранения ревертов коммитов не окупит даже начальные затраты на внедрение подхода?

    Не "даже начальные затраты", а перестройку всего процесса.

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

    В целом я даже соглашусь - гит удобнее для вашего (хабовского) процесса. А свн удобен для нашего (достаточно стандартного на самом деле) процесса. Использование гит у нас без изменения процесса не даст никаких преимуществ, но заставит нас изучать новый инструмент. Использование свн у вас усложнит ваш процесс, потребует создания новых привычек и т.д. Поэтому вам свн не нужен. Но причина здесь именно в процессе. И преимущества гит проявляются именно при работе на основе процесса типа "хаб", а при работе по стандартному процессу гит оказывается просто не нужен (нет преимуществ). Хотя с другой стороны, возможен вариант, когда все знают гит, и тогда нам бы тоже было без разницы, свн использовать или гит, а потому раз всем на свете без разницы - гит бы доминировал. Наверное в этом и есть его преимущество - он позволяет удобнее поддерживать альтернативные процессы (типа хаба, например).
    10 сен 18, 14:11    [21669856]     Ответить | Цитировать Сообщить модератору
     Re: SVN клиент  [new]
    WebSharper
    Member

    Откуда:
    Сообщений: 484
    alex55555
    Ну раз какой-то перец из яндекса сказал - значит не может быть плохо!


    Интересно, как же это происходит в google?

    WebSharper
    Желательно автоматизировано

    Это что за автомат у вас код проверяет? ИИ изобрели?
    [/quot]

    Изобрели компилятор, статический анализ кода, тесты, анализ покрытия, иструменты для code review и словарь, в котором можно посмотреть чем отличается "автоматически" и "автоматизировано" ;)

    Представьте себе свою квартиру. Там много всяких вещей. Но зачем хранить вещи в квартире? Ведь можно их хранить на централизованном складе! И склад обеспечит быструю доставку по первому требованию. Как удобно! Какая разница, где лежат вещи? Если они логически отделены от чужих, да пусть хоть на другом конце планеты! Ведь правда?


    Да, здесь есть небольшая натяжка, но принцип соответствует сути обсуждения на 100%.


    Отлично, дайте мне адрес такого склада! Если там будет так же дешево и быстро как в git, я бы с удовольствием аредновал там место. А то я приценивался к аренде пространства для личных вещей (зимние шины и лыжи летом в квартире не нужны), оказалось дороговато и самому надо отвозить.

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


    У нас планово "накидывают код" он проверяется всеми возможными инструментами, проходит код ревью, а потом вливается в общую ветку.

    WebSharper
    Если внеплановость это помойка, то соответсвно наличие и отсутсвие плана а не наличие или отсутствие брнчей должно быть критерием помойности?

    Ну да, только к чему это?


    Следовательно плановое создание бранчей в репо на сервере не является помойкой, так как критерий помойности это внеплановость а не то, что они на на сервере в репо.

    WebSharper
    Т.е. по вашему экономия от устранения ревертов коммитов не окупит даже начальные затраты на внедрение подхода?

    Не "даже начальные затраты", а перестройку всего процесса.


    А зачем перестраивать весь процесс? Было - сначала комитим, а потом смотрим, стало - сначала смотрим, а потом коммитим. Другие части не меняются.

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


    А нафига это нужно, чтобы в общей ветке был непроверенный и грязный код? Выгода-то от этого какая?

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


    То есть svn удобнее git только тем, что он у вас привычен и уже используется? Мне кажется, вы недостаточно хорошо прочитали https://svnvsgit.com/ - там есть недостатки git, на которые не ответили не здесь ни на ответной статье на хабре.
    10 сен 18, 19:06    [21670198]     Ответить | Цитировать Сообщить модератору
     Re: SVN клиент  [new]
    alex55555
    Member

    Откуда:
    Сообщений: 2128
    WebSharper
    То есть svn удобнее git только тем, что он у вас привычен и уже используется? Мне кажется, вы недостаточно хорошо прочитали https://svnvsgit.com/ - там есть недостатки git, на которые не ответили не здесь ни на ответной статье на хабре.

    Да, привычность есть важная штука. Плюс нет у нас позывов на обмен мест этапов за счёт привлечения нового инструмента.

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

    А по техническим деталям действительно есть более глубокие сравнения.
    11 сен 18, 15:25    [21671086]     Ответить | Цитировать Сообщить модератору
     Re: SVN клиент  [new]
    Swv
    Member

    Откуда:
    Сообщений: 136
    Народ увлекся сам на сам)

    Все ж чего я недопонимаю.

    Есть на одном компе копия. Изменяю файл. Делаю commit. Видно , что файл на сервер ушел изменнный.

    На втором компе делаю update. Рапортует номер ревизии и ничего не обновляет с сервера.
    Иду смотрю репозиторий. Файл лежит измененный. Все ок. Делаю еще раз update. Ничего не обновляется. Удалю этот файл в локальной копии, делаю update. Воо теперь в локальной копии файл актуальный
    24 сен 18, 17:18    [21684397]     Ответить | Цитировать Сообщить модератору
    Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 [4]      все
    Все форумы / Управление процессом разработки ИС Ответить