Здравствуйте, Vain, Вы писали:
S>>Только для тех, кто не понимает разницы между сохранением изменений и публикацией изменений. V>Так начни понимать.
И какое различие между сохранением и публикацией может предложить svn?
V>>>FIFA1x от электроник артс S>>Вы разработчик этой игры? Уверенны, что там ни одной сторонней библиотеки использующий гит нет? V>Думать это полезно.
Вполне поверю, что продукту который старше гита на 10 лет и состоящему на 99% из видеороликов и картинок система контроля версий исходников особо и не нужна, подойдёт хоть shared folder. Поэтому смысла переезжать на git особо нет.
V>>>Причём здесь сложность? Блокчейн замораживает изменения там, где это не требуется. S>> S>>Изменился код — изменился хэш. Это основная идея системы контроля версий. V>Ну так пусть меняется, зачем здесь блокчейн?
Для целостности истории.
V>>>Как это отменяет сложность гит? Зачем платить за то, что не используешь? S>>Мне серьезно интересно как вы работаете. Расскажите или стесняетесь описать? V>Без гит? Нормально себя чувствую.
Причём тут самочувствие? Он спросил о вашем workflow.
V>>>Более требовательное к системе разделения доступа как минимум. S>>Это ложное утверждение в общем случае и это не ответ на вопрос. V>Опять закрывание глаз на проблему.
Ты проблему так и не обозначил. Гит не мешает резделять доступ.
V>>Внести ваши правки в код ядра линукса примерно так же сложно, как в код ядра винды (которая в тоже использует гит, сюрприз). V>Это каким-то образом авторитет здесь?
Эээ. Это тебя спросить надо.
V>Они могут всё что угодно в мире опенсорса использовать, хоть дохлую крысу.
Могут, конечно, но не дураки. Поэтому используют git.
V>>>Это открытый софт. Внутри они не дураки, используют свой TFS. S>>Вот именно: они не дураки и поэтом используют гит. V>Ну я тоже могу на основе FAT12 сделать систему контроля версий, и смотрите, я уже перешёл на FAT12!!!!1111 пыщь пыщь Ты серьёзно или просто троллишь? Ты вообще знаешь что такое TFS?
Team Foundation Server (commonly abbreviated to TFS) is a Microsoft product that provides source code management (either with Team Foundation Version Control or Git), reporting, requirements management, project management (for both agile software development and waterfall teams), automated builds, lab management, testing and release management capabilities
Замечу, что TFVC уже никто в MS не использует, дохлый он по факту.
V>>>Где там отельный доступ в подветки репы без перефигачивания репы? Либо ко всему доступ, либо никому. S>>Начать надо с того, что если необходим разный уровень доступа, то код должен быть в разных репозиториях. V>Фейл. Банальная файловая система с разными привелегиям на каждый файл доказазала здесь обратное.
Фейл. И причём тут ложные аналогии?
S>>Огромные репозитории в которых намешан разный код это тяжелое наследие SVN, в git же сабмодули прекрасно работают. V>Хрена они там нормально работают. Сами гитовцы наплодили надстроек вроде сабтри и им подобных, от хорошей жизни конечно: https://stackoverflow.com/questions/6500524/git-subtree-or-gitslave-as-alternatives-to-git-submodules
В svn они ещё более хреново работают. Но там альтеранив особо нет.
S>>Ну и при нормальной разработке код проверяется, прежде чем попасть в основной репозиторий. V>Причём здесь гит? Это исключительно его заслуга?
Заслугой других vcs можно считать то, что они показали как делать не надо.
V>>>Какой ещё контроль, если распределённость перекрывает контроль? S>>Организовать проверку кода и подпись в гите куда проще, чем в SVN. V>Доказательства будут?
Покажи мне аналог pull requests и "git tag -s" в svn. Подпись коммитов в svn принципиально сделать невозможно, как раз из-за отсутствия того, что ты называешь блокчейном.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Skorodum, Вы писали:
S>>>2. Вот так и помогает. Ничего лучше пока не придумали V>>Если это было бы так, то на гит бы все перешли, что далеко не так. S>Назови широко используемый софт который не использует гит в разработке С учетом зависимостей ты такого скорее всего вообще не найдешь.
LLVM и clang. Сидят на Subversion.
Mozilla. Сидит на Mercurial.
OpenBSD до сих пор использует CVS.
Здравствуйте, so5team, Вы писали:
S>>Назови широко используемый софт который не использует гит в разработке С учетом зависимостей ты такого скорее всего вообще не найдешь. S>LLVM и clang. Сидят на Subversion.
Зачет. Хотя у них уже есть гит-зеркало.
S>Mozilla. Сидит на Mercurial.
Ну так это то же distributed version control system.
S>OpenBSD до сих пор использует CVS.
Собственно о много говорит. Скорее метрвый пациент использует мертвый инструмент.
Здравствуйте, ·, Вы писали:
S>>>Только для тех, кто не понимает разницы между сохранением изменений и публикацией изменений. V>>Так начни понимать. ·>И какое различие между сохранением и публикацией может предложить svn?
Зачем?
·>Вполне поверю, что продукту который старше гита на 10 лет и состоящему на 99% из видеороликов и картинок система контроля версий исходников особо и не нужна, подойдёт хоть shared folder. Поэтому смысла переезжать на git особо нет.
С продуктом сотни разрабов по всему миру работают. Мимо.
V>>Ну так пусть меняется, зачем здесь блокчейн? ·>Для целостности истории.
В свн история настолько целостная, что даже удаление её не удаляет. Работает 100 лет без всяких блокчейнов.
V>>Без гит? Нормально себя чувствую. ·>Причём тут самочувствие? Он спросил о вашем workflow.
Как и у всех. Беру исходник, правлю, заливаю.
V>>>>Более требовательное к системе разделения доступа как минимум. S>>>Это ложное утверждение в общем случае и это не ответ на вопрос. V>>Опять закрывание глаз на проблему. ·>Ты проблему так и не обозначил. Гит не мешает резделять доступ.
Ну если только через большую Ж.
V>>>Внести ваши правки в код ядра линукса примерно так же сложно, как в код ядра винды (которая в тоже использует гит, сюрприз). V>>Это каким-то образом авторитет здесь? ·>Эээ. Это тебя спросить надо.
Авторитетную винду не я приводил.
V>>Они могут всё что угодно в мире опенсорса использовать, хоть дохлую крысу. ·>Могут, конечно, но не дураки. Поэтому используют git.
Рекламная лапша.
·>Замечу, что TFVC уже никто в MS не использует, дохлый он по факту.
Это обёртка. Внутри может быть всё что угодно. Принцип чекаутов-чекинов они поменяли?
V>>Фейл. Банальная файловая система с разными привелегиям на каждый файл доказазала здесь обратное. ·>Фейл. И причём тут ложные аналогии?
то код должен быть в разных репозиториях
Ложные аналогии выделил.
·>В svn они ещё более хреново работают. Но там альтеранив особо нет.
в СВН нет никаких надстроек. Всё из каропки. И работает просто замечательно.
S>>>Ну и при нормальной разработке код проверяется, прежде чем попасть в основной репозиторий. V>>Причём здесь гит? Это исключительно его заслуга? ·>Заслугой других vcs можно считать то, что они показали как делать не надо.
Ну если Вам не надо делать просто и удобно, то я даже не знаю что ответить.
S>>>Организовать проверку кода и подпись в гите куда проще, чем в SVN. V>>Доказательства будут? ·>Покажи мне аналог pull requests и "git tag -s" в svn.
Зачем мне какой-то пулреквест, где я могу просто залить изменения?
·>Подпись коммитов в svn принципиально сделать невозможно, как раз из-за отсутствия того, что ты называешь блокчейном.
Зачем подписывать то, что не требует подписи? Ваш коммит могут вскрыть злые хакеры и продать в интернет? Или может залить свой между вашим и чьим то? Не делайте мне смешно.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>>>Так начни понимать. V>·>И какое различие между сохранением и публикацией может предложить svn? V>Зачем?
Потому что незаконченные изменения не надо публиковать, но хочется сохранять.
V>·>Вполне поверю, что продукту который старше гита на 10 лет и состоящему на 99% из видеороликов и картинок система контроля версий исходников особо и не нужна, подойдёт хоть shared folder. Поэтому смысла переезжать на git особо нет. V>С продуктом сотни разрабов по всему миру работают. Мимо.
Ну так и с shared folder можно хоть тысячи.
V>>>Ну так пусть меняется, зачем здесь блокчейн? V>·>Для целостности истории. V>В свн история настолько целостная, что даже удаление её не удаляет. Работает 100 лет без всяких блокчейнов.
Это не целостность истории, а целостность файлов репозитория на сервере svn. К svn никакого отношения не имеющая.
V>>>Без гит? Нормально себя чувствую. V>·>Причём тут самочувствие? Он спросил о вашем workflow. V>Как и у всех. Беру исходник, правлю, заливаю.
Т.е. ревью, CI и т.п. нет?
V>>>Опять закрывание глаз на проблему. V>·>Ты проблему так и не обозначил. Гит не мешает резделять доступ. V>Ну если только через большую Ж.
Т.е. проблема у вас в том, что всё делается через большую Ж?
V>>>Это каким-то образом авторитет здесь? V>·>Эээ. Это тебя спросить надо. V>Авторитетную винду не я приводил.
Я всё равно не понял причём тут авторитетность.
V>>>Они могут всё что угодно в мире опенсорса использовать, хоть дохлую крысу. V>·>Могут, конечно, но не дураки. Поэтому используют git. V>Рекламная лапша.
Реклама чего? И кому выгодна эта реклама?
V>·>Замечу, что TFVC уже никто в MS не использует, дохлый он по факту. V>Это обёртка. Внутри может быть всё что угодно. Принцип чекаутов-чекинов они поменяли?
Естественно. Это только примитивные проекты можно чекаутами-чекинами разрабатывать. Вообще никак не масштабируется.
V>>>Фейл. Банальная файловая система с разными привелегиям на каждый файл доказазала здесь обратное. V>·>Фейл. И причём тут ложные аналогии? V>
то код должен быть в разных репозиториях
V>Ложные аналогии выделил.
Я не понял твой тезис.
V>·>В svn они ещё более хреново работают. Но там альтеранив особо нет. V>в СВН нет никаких надстроек. Всё из каропки. И работает просто замечательно.
Я имею в виду что субмодули (точнее externals) в svn работают очень хреново. Могут давать non-repeateable билды и полный песец с ветками. И альтернатив нет.
V>>>Причём здесь гит? Это исключительно его заслуга? V>·>Заслугой других vcs можно считать то, что они показали как делать не надо. V>Ну если Вам не надо делать просто и удобно, то я даже не знаю что ответить.
И так всё просто насколько возможно, но не проще.
V>>>Доказательства будут? V>·>Покажи мне аналог pull requests и "git tag -s" в svn. V>Зачем мне какой-то пулреквест, где я могу просто залить изменения?
В какую-нибудь игрульку типа FIFA, конечно, можешь. А какой-нибудь серьёзный проект — без ревью и прочего — да кто ж тебе позволит что-то заливать? Или тебя Торвальд зовут?
V>·>Подпись коммитов в svn принципиально сделать невозможно, как раз из-за отсутствия того, что ты называешь блокчейном. V>Зачем подписывать то, что не требует подписи?
Ну раз не требует, не подписывай. А то что требует — приходится подписывать.
V>Ваш коммит могут вскрыть злые хакеры и продать в интернет? Или может залить свой между вашим и чьим то? Не делайте мне смешно.
Ты правда не понимаешь цель подписи или просто троллишь?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
V>>Как и у всех. Беру исходник, правлю, заливаю. ·>Т.е. ревью, CI и т.п. нет?
Ага, вот и момент истины: хотя обе системы производят в конечном счёте одинаковый результат, гитомеркуриал незаменим в юных коллективах:
1. Круто-молодёжно.
2. При написании кода методом тыка недокоммит необходим.
3. Тётя Гита следит за тем, чтобы дети синхронизировались перед покакушками в репозиторий.
Здравствуйте, mgu, Вы писали:
V>>>Как и у всех. Беру исходник, правлю, заливаю. mgu>·>Т.е. ревью, CI и т.п. нет? mgu>Ага, вот и момент истины: хотя обе системы производят в конечном счёте одинаковый результат, гитомеркуриал незаменим в юных коллективах:
В каком смысле "одинаковый"?
mgu>1. Круто-молодёжно.
А иногда и совсем наоборот — скучно и бюрократично. Например, наличие peer review может быть требованием контролирующих организаций. И тут выбор — либо выкручивайся как можешь с патчами/ветками/х.з.чем, либо какой-нибудь тривиальный механизм типа pull requests.
mgu>2. При написании кода методом тыка недокоммит необходим.
Во-первых, не только лишь все умеют ваять нетленку сразу в прод.
А во-вторых, он необходим и в других ситуациях.
mgu>3. Тётя Гита следит за тем, чтобы дети синхронизировались перед покакушками в репозиторий.
Угу. А кто должен? Самый главный самый ведущий самый старший программист, который вечно занят?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>>>Как и у всех. Беру исходник, правлю, заливаю. mgu>>·>Т.е. ревью, CI и т.п. нет? mgu>>Ага, вот и момент истины: хотя обе системы производят в конечном счёте одинаковый результат, гитомеркуриал незаменим в юных коллективах: ·>В каком смысле "одинаковый"?
Можете взглянуть на коллективно разработанный файл и сказать, какой системой он сливался?
mgu>>1. Круто-молодёжно. ·>А иногда и совсем наоборот — скучно и бюрократично. Например, наличие peer review может быть требованием контролирующих организаций. И тут выбор — либо выкручивайся как можешь с патчами/ветками/х.з.чем, либо какой-нибудь тривиальный механизм типа pull requests.
В серьёзных конторах подобным не заморачиваются -- лепят версии из того, что есть, а потом пользователи пишут письма.
mgu>>2. При написании кода методом тыка недокоммит необходим. ·>Во-первых, не только лишь все умеют ваять нетленку сразу в прод.
При Сталине такого не было!
·>А во-вторых, он необходим и в других ситуациях.
В случаях разрывов?
mgu>>3. Тётя Гита следит за тем, чтобы дети синхронизировались перед покакушками в репозиторий. ·>Угу. А кто должен? Самый главный самый ведущий самый старший программист, который вечно занят?
Здравствуйте, ·, Вы писали:
V>>·>В svn они ещё более хреново работают. Но там альтеранив особо нет. V>>в СВН нет никаких надстроек. Всё из каропки. И работает просто замечательно. ·>Я имею в виду что субмодули (точнее externals) в svn работают очень хреново. Могут давать non-repeateable билды и полный песец с ветками. И альтернатив нет.
Можно описать сценарий, при котором svn:externals приводят к non-repeateable билдам?
Речь про случаи, когда в svn:externals фиксируются только URL, без номеров ревизий?
Здравствуйте, so5team, Вы писали:
V>>>·>В svn они ещё более хреново работают. Но там альтеранив особо нет. V>>>в СВН нет никаких надстроек. Всё из каропки. И работает просто замечательно. S>·>Я имею в виду что субмодули (точнее externals) в svn работают очень хреново. Могут давать non-repeateable билды и полный песец с ветками. И альтернатив нет. S>Можно описать сценарий, при котором svn:externals приводят к non-repeateable билдам? S>Речь про случаи, когда в svn:externals фиксируются только URL, без номеров ревизий?
Да. А если фиксировать на конкретные ревизии, то получается похоже на git submodules. И в этом сценарии с submodules проблем меньше, т.к. с ветками проще работать.
Ещё, кстати, интересное чтиво: https://stackoverflow.com/questions/338824/are-subversion-externals-an-antipattern
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, mgu, Вы писали:
mgu>>>·>Т.е. ревью, CI и т.п. нет? mgu>>>Ага, вот и момент истины: хотя обе системы производят в конечном счёте одинаковый результат, гитомеркуриал незаменим в юных коллективах: mgu>·>В каком смысле "одинаковый"? mgu>Можете взглянуть на коллективно разработанный файл и сказать, какой системой он сливался?
Во-первых, не знаю какая у вас сложность проектов, но vcs для одного файла как-то странно. Разрабатывается обычно целый проект, со множеством файлов.
Во-вторых, по файлу нельзя сказать и каким редактором он редактировался. Означает ли это, что notepad.exe — лучший редактор?
mgu>>>1. Круто-молодёжно. mgu>·>А иногда и совсем наоборот — скучно и бюрократично. Например, наличие peer review может быть требованием контролирующих организаций. И тут выбор — либо выкручивайся как можешь с патчами/ветками/х.з.чем, либо какой-нибудь тривиальный механизм типа pull requests. mgu>В серьёзных конторах подобным не заморачиваются -- лепят версии из того, что есть, а потом пользователи пишут письма.
Не знаю что ты называешь серьёзными конторами.
mgu>>>2. При написании кода методом тыка недокоммит необходим. mgu>·>Во-первых, не только лишь все умеют ваять нетленку сразу в прод. mgu>При Сталине такого не было!
Ты так говоришь, как будто это что-то плохое.
mgu>·>А во-вторых, он необходим и в других ситуациях. mgu>В случаях разрывов?
Угу. Видишь ли, я хочу иметь возможность, например, пойти на обед или домой когда мне удобно, а не безразрывно ваять нетленки.
mgu>>>3. Тётя Гита следит за тем, чтобы дети синхронизировались перед покакушками в репозиторий. mgu>·>Угу. А кто должен? Самый главный самый ведущий самый старший программист, который вечно занят? mgu>Сами должны подтирать попки.
Вот ещё, тебе нравится — ты и подтирай, а я — человек ленивый. People should think, machines can do the work.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
S>>·>Я имею в виду что субмодули (точнее externals) в svn работают очень хреново. Могут давать non-repeateable билды и полный песец с ветками. И альтернатив нет. S>>Можно описать сценарий, при котором svn:externals приводят к non-repeateable билдам? S>>Речь про случаи, когда в svn:externals фиксируются только URL, без номеров ревизий? ·>Да.
Остается непонятным, почему "работают очень хреново" именно svn:externals, если они работают именно так, как сказал пользователь. Задавать externals с точной ревизией или нет -- это выбор и решение пользователя. Инструмент позволяет делать и то, и другое (в каких-то сценариях нужно одно, в каких-то другое), поведение инструмента в обоих случаях предсказуемо и логично. Если пользователь по недомыслию или недоразумению не задал ревизию (или задал ее неправильно), то "работает очень хреново" именно svn? Ну OK.
·>А если фиксировать на конкретные ревизии, то получается похоже на git submodules.
С учетом того, что svn:externals появились раньше самого git-а, "похоже" должно быть в обратном направлении.
·>И в этом сценарии с submodules проблем меньше, т.к. с ветками проще работать.
Здравствуйте, ·, Вы писали:
·>Потому что незаконченные изменения не надо публиковать, но хочется сохранять.
Они уже сохранены у тебя на диске. Во-вторых, сташ будет и в свн в новой версии. В третьих, есть плагин. В чётвертых, можно сохранить в патч. В пятых, можно просто скопировать папочку куда надо.
V>>·>Вполне поверю, что продукту который старше гита на 10 лет и состоящему на 99% из видеороликов и картинок система контроля версий исходников особо и не нужна, подойдёт хоть shared folder. Поэтому смысла переезжать на git особо нет. V>>С продуктом сотни разрабов по всему миру работают. Мимо. ·>Ну так и с shared folder можно хоть тысячи.
У shared folder появилось версионирование?
V>>В свн история настолько целостная, что даже удаление её не удаляет. Работает 100 лет без всяких блокчейнов. ·>Это не целостность истории, а целостность файлов репозитория на сервере svn. К svn никакого отношения не имеющая.
Как не имеющая, если свн тоже хеши использует?
V>>Как и у всех. Беру исходник, правлю, заливаю. ·>Т.е. ревью, CI и т.п. нет?
Можно прикрутить, про хуки слышал?
V>>Ну если только через большую Ж. ·>Т.е. проблема у вас в том, что всё делается через большую Ж?
Да, в гите.
V>>Авторитетную винду не я приводил. ·>Я всё равно не понял причём тут авторитетность.
А причём здесь винда/линукс?
V>>·>Могут, конечно, но не дураки. Поэтому используют git. V>>Рекламная лапша. ·>Реклама чего? И кому выгодна эта реклама?
Опенсоурсу и сервисам вокруг него. Типа бесплатным, конечно.
V>>Это обёртка. Внутри может быть всё что угодно. Принцип чекаутов-чекинов они поменяли? ·>Естественно. Это только примитивные проекты можно чекаутами-чекинами разрабатывать. Вообще никак не масштабируется.
Причём же тогда здесь "они не дураки и поэтом используют гит."?
V>>
то код должен быть в разных репозиториях
V>>Ложные аналогии выделил. ·>Я не понял твой тезис.
не понимаешь что у одного репозитория должна быть возможность назначать разные права без перегенерации всего репозитория?
V>>в СВН нет никаких надстроек. Всё из каропки. И работает просто замечательно. ·>Я имею в виду что субмодули (точнее externals) в svn работают очень хреново. Могут давать non-repeateable билды и полный песец с ветками. И альтернатив нет.
Это потому-что назначаются вместо конкретных версии HEAD. Это фича. Чтобы билд был репитабл нужно сохранить весь список ревизий, т.е. всех подветок, а не только корня. Это же очевидно. И это абсолютно нормально и логично. Зато гит не умеет сам брать HEAD подветки одной командой. Обязательно надо вручную вызывать subtree/submodule fetch отдельно, потому что тип подветки неоднозначен. Охренеть как это "удобно".
V>>Ну если Вам не надо делать просто и удобно, то я даже не знаю что ответить. ·>И так всё просто насколько возможно, но не проще.
Чем докажешь простоту? Я могу. Количеством команд и ключей в гите и в свн. Первый явно проигрывает.
V>>Зачем мне какой-то пулреквест, где я могу просто залить изменения? ·>В какую-нибудь игрульку типа FIFA, конечно, можешь. А какой-нибудь серьёзный проект — без ревью и прочего — да кто ж тебе позволит что-то заливать? Или тебя Торвальд зовут?
Какое это имеет отношение к гиту, это давно можно делать во всех системах контроля версий. У гита здесь нет преимущества.
·>Ну раз не требует, не подписывай. А то что требует — приходится подписывать.
Для чего требует?
V>>Ваш коммит могут вскрыть злые хакеры и продать в интернет? Или может залить свой между вашим и чьим то? Не делайте мне смешно. ·>Ты правда не понимаешь цель подписи или просто троллишь?
Объясни сначало как подпись что-то изменит? Всю репу в гите можно перегенерить со своими коммитами, в чем же тогда преимущество сей подписи? Более того, попробуй что-либо зазеркалировать с одного места в две гитовых пустых репы c кучей сабтрии, одна ошибка и бац — в двух абсолютно одинаковых репах разные подписи, просто потому-что порядок мержа где-то незначительно сдвинулся и всё, хеши поплыли в далёкое плавание.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, so5team, Вы писали:
S>>>Можно описать сценарий, при котором svn:externals приводят к non-repeateable билдам? S>>>Речь про случаи, когда в svn:externals фиксируются только URL, без номеров ревизий? S>·>Да. S>Остается непонятным, почему "работают очень хреново" именно svn:externals, если они работают именно так, как сказал пользователь. Задавать externals с точной ревизией или нет -- это выбор и решение пользователя. Инструмент позволяет делать и то, и другое (в каких-то сценариях нужно одно, в каких-то другое), поведение инструмента в обоих случаях предсказуемо и логично. Если пользователь по недомыслию или недоразумению не задал ревизию (или задал ее неправильно), то "работает очень хреново" именно svn? Ну OK.
Потому что это антипаттерн. Например, в CVS есть возможность делать тег на каждый отдельный файл. В svn так нельзя — можно ли сказать, что cvs работает лучше svn?
S>·>А если фиксировать на конкретные ревизии, то получается похоже на git submodules. S>С учетом того, что svn:externals появились раньше самого git-а, "похоже" должно быть в обратном направлении.
Верно. Поняли, что так делать не надо и в git сделали чуть лучше. А так externals это далеко не изобретение svn. В том же clearcase есть links и ещё всякие страхи уж не помню как зовутся...
S>·>И в этом сценарии с submodules проблем меньше, т.к. с ветками проще работать. S>И как же соотносится одно с другим? И почему, если с submodules все так хорошо, то в Интернете полно статьей типа вот этой: Git subtree: the alternative to Git submodule?
Нет, не всё хорошо, я бы даже сказал, что всё плохо. Но при этом не хуже, чем externals.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Vain, Вы писали:
V>·>Потому что незаконченные изменения не надо публиковать, но хочется сохранять. V>Они уже сохранены у тебя на диске.
Без бекапов? Не доверяю я дискам.
V>Во-вторых, сташ будет и в свн в новой версии.
Поздно пить боржоми.
V>В третьих, есть плагин. В чётвертых, можно сохранить в патч.
Мде...
V>В пятых, можно просто скопировать папочку куда надо.
И накой тогда этот твой svn сдался? папочки я и без svn копировать умею.
Понятно, что можно извернуться, но обычный коммит-то проще. Ты вроде тут о простоте рассуждал...
V>>>С продуктом сотни разрабов по всему миру работают. Мимо. V>·>Ну так и с shared folder можно хоть тысячи. V>У shared folder появилось версионирование?
Конечно, сделай простой hourly incremental backup и вуаля!
V>>>В свн история настолько целостная, что даже удаление её не удаляет. Работает 100 лет без всяких блокчейнов. V>·>Это не целостность истории, а целостность файлов репозитория на сервере svn. К svn никакого отношения не имеющая. V>Как не имеющая, если свн тоже хеши использует?
Для чего он их использует? И с какой версии? Насколько я помню, никаких там хешей не было... Ты с чексуммами не попутал?
V>>>Как и у всех. Беру исходник, правлю, заливаю. V>·>Т.е. ревью, CI и т.п. нет? V>Можно прикрутить, про хуки слышал?
Можно, но проще перейти на гит.
Типичный сценарий. Взял задачу. Для её решения нужен небольшой рефакторинг. Делаю один-два коммита для рефакторинга, один-два коммита для самого изменения. Эти коммиты отправляю на CI, чтобы он проверил качество всяческими авто-тестами, потом на ревью, ревьювер может быть сейчас занят и посмотрит только завтра, а послезавтра у меня найдётся время ответить на замечания ревьювера и пойти на второй круг CI->review. А я пока могу взяться за следующую задачу. Давай, опиши что и как ты сделаешь хуками.
V>>>Ну если только через большую Ж. V>·>Т.е. проблема у вас в том, что всё делается через большую Ж? V>Да, в гите.
Просто не делайте так.
V>>>Авторитетную винду не я приводил. V>·>Я всё равно не понял причём тут авторитетность. V>А причём здесь винда/линукс?
Как пример популярных больших проектов с ценным (в смысле sensitive) кодом.
V>>>·>Могут, конечно, но не дураки. Поэтому используют git. V>>>Рекламная лапша. V>·>Реклама чего? И кому выгодна эта реклама? V>Опенсоурсу и сервисам вокруг него. Типа бесплатным, конечно.
Ничего не понял. Это тут причём? svn не опенсорс что-ле?
V>>>Это обёртка. Внутри может быть всё что угодно. Принцип чекаутов-чекинов они поменяли? V>·>Естественно. Это только примитивные проекты можно чекаутами-чекинами разрабатывать. Вообще никак не масштабируется. V>Причём же тогда здесь "они не дураки и поэтом используют гит."?
Это тебя надо спросить. Ты сказал, что " Внутри они не дураки, используют свой TFS." Тебя просто поправили, т.к. в данном контексте TFS это и есть git.
V>>>
то код должен быть в разных репозиториях
V>>>Ложные аналогии выделил. V>·>Я не понял твой тезис. V>не понимаешь что у одного репозитория должна быть возможность назначать разные права без перегенерации всего репозитория?
Это не задача, а способ (притом не самый лучший) её решения. Ты так и не обозначил задачу.
V>·>Я имею в виду что субмодули (точнее externals) в svn работают очень хреново. Могут давать non-repeateable билды и полный песец с ветками. И альтернатив нет. V>Это потому-что назначаются вместо конкретных версии HEAD. Это фича. Чтобы билд был репитабл нужно сохранить весь список ревизий, т.е. всех подветок, а не только корня. Это же очевидно. И это абсолютно нормально и логично.
Приведи мне одну команду в svn "сохранить весь список ревизий", и ещё одну команду чтобы потом этот список восстановить для того чтобы build был repeatable.
V>Зато гит не умеет сам брать HEAD подветки одной командой. Обязательно надо вручную вызывать subtree/submodule fetch отдельно, потому что тип подветки неоднозначен. Охренеть как это "удобно".
Умеет, конечно: "git submodule update --recursive --remote".
V>>>Ну если Вам не надо делать просто и удобно, то я даже не знаю что ответить. V>·>И так всё просто насколько возможно, но не проще. V>Чем докажешь простоту?
Ну, например, популярностью. Даже смузи-стартапёры осиливают github.
V>Я могу. Количеством команд и ключей в гите и в свн. Первый явно проигрывает.
Мдеее, отличная идея! Ну что-ж, давай сравним сколько сколько команд ключей понадобится для простой задачи, например, поискать ревизию с помощью bisect в svn vs git.
V>>>Зачем мне какой-то пулреквест, где я могу просто залить изменения? V>·>В какую-нибудь игрульку типа FIFA, конечно, можешь. А какой-нибудь серьёзный проект — без ревью и прочего — да кто ж тебе позволит что-то заливать? Или тебя Торвальд зовут? V>Какое это имеет отношение к гиту, это давно можно делать во всех системах контроля версий. У гита здесь нет преимущества.
Так это можно делать и без систем контроля версий, хоть в твиттере! И что?
V>·>Ну раз не требует, не подписывай. А то что требует — приходится подписывать. V>Для чего требует?
Для sensitive кода.
V>>>Ваш коммит могут вскрыть злые хакеры и продать в интернет? Или может залить свой между вашим и чьим то? Не делайте мне смешно. V>·>Ты правда не понимаешь цель подписи или просто троллишь? V>Объясни сначало как подпись что-то изменит? Всю репу в гите можно перегенерить со своими коммитами, в чем же тогда преимущество сей подписи?
Ты правда не знаешь как подпись работает? Если ты перегенеришь репу, то подпись станет невалидной, очевидно. Придётся только переподписать, но для этого у тбея должен быть приватный ключ.
V>Более того, попробуй что-либо зазеркалировать с одного места в две гитовых пустых репы c кучей сабтрии, одна ошибка и бац — в двух абсолютно одинаковых репах разные подписи, просто потому-что порядок мержа где-то незначительно сдвинулся и всё, хеши поплыли в далёкое плавание.
Чё? Если репы одинаковы (т.е. sha1 снапшотов идентичен), то неподписанную ревизию можно просто выкинуть и использовать подписанную.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
V>>·>Потому что незаконченные изменения не надо публиковать, но хочется сохранять. V>>Они уже сохранены у тебя на диске. ·>Без бекапов? Не доверяю я дискам.
И причём здесь опять гит или свн?
V>>В пятых, можно просто скопировать папочку куда надо. ·>И накой тогда этот твой svn сдался? папочки я и без svn копировать умею.
Бекап не дело системы контроля версий. Хочешь бекап сохраняй всю папку. В гите — тоже самое между прочим.
·>Понятно, что можно извернуться, но обычный коммит-то проще. Ты вроде тут о простоте рассуждал...
Коммит сам по себе не создаёт бекапов.
V>>У shared folder появилось версионирование? ·>Конечно, сделай простой hourly incremental backup и вуаля!
Тем более зачем тогда гит?
V>>Как не имеющая, если свн тоже хеши использует? ·>Для чего он их использует? И с какой версии? Насколько я помню, никаких там хешей не было... Ты с чексуммами не попутал?
Хеши для сравнения файлов без закачки.
·>Можно, но проще перейти на гит. ·>Типичный сценарий. Взял задачу. Для её решения нужен небольшой рефакторинг. Делаю один-два коммита для рефакторинга, один-два коммита для самого изменения. Эти коммиты отправляю на CI, чтобы он проверил качество всяческими авто-тестами, потом на ревью, ревьювер может быть сейчас занят и посмотрит только завтра, а послезавтра у меня найдётся время ответить на замечания ревьювера и пойти на второй круг CI->review. А я пока могу взяться за следующую задачу. Давай, опиши что и как ты сделаешь хуками.
Создаешь бранч, заливаешь туда, хуки оповешают кого угодно что что-то произошло, к примеру, поменялся коммит мессадж. А можно и вообще без хуком просто повесить коммит монитор и следить вручную. Это даже проще. https://stackoverflow.com/questions/8905931/prevent-commit-before-peer-review-in-svn
V>>Да, в гите. ·>Просто не делайте так.
Гит предлагает, но я не делаю.
V>>А причём здесь винда/линукс? ·>Как пример популярных больших проектов с ценным (в смысле sensitive) кодом.
А что бывает абсценный код? Любой код ценен раз уж его заливают в систему контроля версий in first place. Выбор системы контроля версий не делает код ценнее и ценный код не делает систему контроля версий лучше.
V>>Опенсоурсу и сервисам вокруг него. Типа бесплатным, конечно. ·>Ничего не понял. Это тут причём? svn не опенсорс что-ле?
github, bitbucket, gitlab, и т.д. Вполне себе платные сервисы и бесплатные для опенсоурса.
V>>Причём же тогда здесь "они не дураки и поэтом используют гит."? ·>Это тебя надо спросить. Ты сказал, что " Внутри они не дураки, используют свой TFS." Тебя просто поправили, т.к. в данном контексте TFS это и есть git.
Нет, не сеть, конечно. Они используют свою обёртку вокруг гита. Внутри мог лежать легко не гит, а дохлая крыса.
V>>не понимаешь что у одного репозитория должна быть возможность назначать разные права без перегенерации всего репозитория? ·>Это не задача, а способ (притом не самый лучший) её решения. Ты так и не обозначил задачу.
Это именно что задача, потому-что репа разрастается со временем и потом не будет возможности её переделывать.
V>>·>Я имею в виду что субмодули (точнее externals) в svn работают очень хреново. Могут давать non-repeateable билды и полный песец с ветками. И альтернатив нет. V>>Это потому-что назначаются вместо конкретных версии HEAD. Это фича. Чтобы билд был репитабл нужно сохранить весь список ревизий, т.е. всех подветок, а не только корня. Это же очевидно. И это абсолютно нормально и логично. ·>Приведи мне одну команду в svn "сохранить весь список ревизий", и ещё одну команду чтобы потом этот список восстановить для того чтобы build был repeatable.
А что, такая же команда есть в гите?
V>>Зато гит не умеет сам брать HEAD подветки одной командой. Обязательно надо вручную вызывать subtree/submodule fetch отдельно, потому что тип подветки неоднозначен. Охренеть как это "удобно". ·>Умеет, конечно: "git submodule update --recursive --remote".
Почему сабмодуль, а не subtree, как ты угадал команду?
V>>Чем докажешь простоту? ·>Ну, например, популярностью. Даже смузи-стартапёры осиливают github.
Простота != Популярность. Осиливают через гуй, ага.
V>>Я могу. Количеством команд и ключей в гите и в свн. Первый явно проигрывает. ·>Мдеее, отличная идея! Ну что-ж, давай сравним сколько сколько команд ключей понадобится для простой задачи, например, поискать ревизию с помощью bisect в svn vs git.
Ревизию на основе чего?
V>>>>Зачем мне какой-то пулреквест, где я могу просто залить изменения? V>>·>В какую-нибудь игрульку типа FIFA, конечно, можешь. А какой-нибудь серьёзный проект — без ревью и прочего — да кто ж тебе позволит что-то заливать? Или тебя Торвальд зовут? V>>Какое это имеет отношение к гиту, это давно можно делать во всех системах контроля версий. У гита здесь нет преимущества. ·>Так это можно делать и без систем контроля версий, хоть в твиттере! И что?
Тем более, получается твиттер заменил гит.
V>>·>Ну раз не требует, не подписывай. А то что требует — приходится подписывать. V>>Для чего требует? ·>Для sensitive кода.
Что такое not sensitive код?
V>>Объясни сначало как подпись что-то изменит? Всю репу в гите можно перегенерить со своими коммитами, в чем же тогда преимущество сей подписи? ·>Ты правда не знаешь как подпись работает? Если ты перегенеришь репу, то подпись станет невалидной, очевидно. Придётся только переподписать, но для этого у тбея должен быть приватный ключ.
Зачем с существующими правами доступа что-то подписывать?
V>>Более того, попробуй что-либо зазеркалировать с одного места в две гитовых пустых репы c кучей сабтрии, одна ошибка и бац — в двух абсолютно одинаковых репах разные подписи, просто потому-что порядок мержа где-то незначительно сдвинулся и всё, хеши поплыли в далёкое плавание. ·>Чё? Если репы одинаковы (т.е. sha1 снапшотов идентичен), то неподписанную ревизию можно просто выкинуть и использовать подписанную.
Это работает только в пределах одной репы, а не между репами. Между репами ты сам назначаешь связи и типы подветок.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, ·, Вы писали:
·>Потому что это антипаттерн.
svn:externals -- это инструмент. Он работает так, как было задумано. Инструмент не может быть антипаттерном.
Если вы говорите об антипаттерне, значит вас не устраивает то, как svn:externals используется. Ну тогда расскажите, что именно вас не устраивает и почему. Пока же непонятно, что именно вы вложили в слова "работает очень хреново". Ссылку на stackoverflow повторять не нужно, там какая-то ерунда написана, о чем там же и сказали во втором ответе.
S>>·>И в этом сценарии с submodules проблем меньше, т.к. с ветками проще работать. S>>И как же соотносится одно с другим? И почему, если с submodules все так хорошо, то в Интернете полно статьей типа вот этой: Git subtree: the alternative to Git submodule? ·>Нет, не всё хорошо, я бы даже сказал, что всё плохо. Но при этом не хуже, чем externals.
Хотелось бы все-таки услышать более подробное объяснение вот этого: "И в этом сценарии с submodules проблем меньше, т.к. с ветками проще работать."
Как именно соотносится удобство работы с ветками и использование submodules?
Здравствуйте, Vain, Вы писали:
V>>>·>Потому что незаконченные изменения не надо публиковать, но хочется сохранять. V>>>Они уже сохранены у тебя на диске. V>·>Без бекапов? Не доверяю я дискам. V>И причём здесь опять гит или свн?
В гите я обычно делаю push в приватный личный репо для сохранения временных наработок, которые хоть сколько-нибудь жалко потерять. Или можно создать pull request.
V>>>В пятых, можно просто скопировать папочку куда надо. V>·>И накой тогда этот твой svn сдался? папочки я и без svn копировать умею. V>Бекап не дело системы контроля версий. Хочешь бекап сохраняй всю папку. В гите — тоже самое между прочим.
Не то же самое, ибо он децентрализованный.
V>·>Понятно, что можно извернуться, но обычный коммит-то проще. Ты вроде тут о простоте рассуждал... V>Коммит сам по себе не создаёт бекапов.
Как минимум он создаёт бэкап рабочей копии.
V>>>У shared folder появилось версионирование? V>·>Конечно, сделай простой hourly incremental backup и вуаля! V>Тем более зачем тогда гит?
Удобнее и проще.
V>>>Как не имеющая, если свн тоже хеши использует? V>·>Для чего он их использует? И с какой версии? Насколько я помню, никаких там хешей не было... Ты с чексуммами не попутал? V>Хеши для сравнения файлов без закачки.
Ну, чексуммы. А я говорил про целостность истории.
V>·>Типичный сценарий. Взял задачу. Для её решения нужен небольшой рефакторинг. Делаю один-два коммита для рефакторинга, один-два коммита для самого изменения. Эти коммиты отправляю на CI, чтобы он проверил качество всяческими авто-тестами, потом на ревью, ревьювер может быть сейчас занят и посмотрит только завтра, а послезавтра у меня найдётся время ответить на замечания ревьювера и пойти на второй круг CI->review. А я пока могу взяться за следующую задачу. Давай, опиши что и как ты сделаешь хуками. V>Создаешь бранч, заливаешь туда, хуки оповешают кого угодно что что-то произошло, к примеру, поменялся коммит мессадж. А можно и вообще без хуком просто повесить коммит монитор и следить вручную. Это даже проще. V>https://stackoverflow.com/questions/8905931/prevent-commit-before-peer-review-in-svn
Погоди, ты предлагал использовать хуки и ВНЕЗАПНО даёшь ответы в котором "have no need for pre-commit hooks", "используй бранчи", "need is a code review tool". Да, бранчами это решается, но бранчи и мерж в svn работают плохо (читай recursive merge).
V>>>Да, в гите. V>·>Просто не делайте так. V>Гит предлагает, но я не делаю.
Но почему-то другим он ничего такого не предлагает.
V>>>А причём здесь винда/линукс? V>·>Как пример популярных больших проектов с ценным (в смысле sensitive) кодом. V>А что бывает абсценный код? Любой код ценен раз уж его заливают в систему контроля версий in first place. Выбор системы контроля версий не делает код ценнее и ценный код не делает систему контроля версий лучше.
Я же говорю — sensitive. Т.е. является целью аттак.
V>>>Опенсоурсу и сервисам вокруг него. Типа бесплатным, конечно. V>·>Ничего не понял. Это тут причём? svn не опенсорс что-ле? V>github, bitbucket, gitlab, и т.д. Вполне себе платные сервисы и бесплатные для опенсоурса.
Так это хостинг. gitlab и некоторые другие бесплатны, если сам хостишь. github, кстати, замечательно поддерживает svn.
А sourceforge и прочие svn-хостеры бесплатны для всех?
V>>>Причём же тогда здесь "они не дураки и поэтом используют гит."? V>·>Это тебя надо спросить. Ты сказал, что " Внутри они не дураки, используют свой TFS." Тебя просто поправили, т.к. в данном контексте TFS это и есть git. V>Нет, не сеть, конечно. Они используют свою обёртку вокруг гита. Внутри мог лежать легко не гит, а дохлая крыса.
Бред какой-то. libgit2 там афаир.
V>>>не понимаешь что у одного репозитория должна быть возможность назначать разные права без перегенерации всего репозитория? V>·>Это не задача, а способ (притом не самый лучший) её решения. Ты так и не обозначил задачу. V>Это именно что задача, потому-что репа разрастается со временем и потом не будет возможности её переделывать.
Если ты имеешь в виду "задача отделить под-проект от ставшего большим проектом" — создаёшь новый репо для под-проекта и импортируешь туда соответствующую часть из проекта. Не вижу проблему. В каком месте тебе понадобится перегенерация всего репозитория?
V>>>Это потому-что назначаются вместо конкретных версии HEAD. Это фича. Чтобы билд был репитабл нужно сохранить весь список ревизий, т.е. всех подветок, а не только корня. Это же очевидно. И это абсолютно нормально и логично. V>·>Приведи мне одну команду в svn "сохранить весь список ревизий", и ещё одну команду чтобы потом этот список восстановить для того чтобы build был repeatable. V>А что, такая же команда есть в гите?
git commit и git checkout соответственно.
V>>>Зато гит не умеет сам брать HEAD подветки одной командой. Обязательно надо вручную вызывать subtree/submodule fetch отдельно, потому что тип подветки неоднозначен. Охренеть как это "удобно". V>·>Умеет, конечно: "git submodule update --recursive --remote". V>Почему сабмодуль, а не subtree, как ты угадал команду?
Не понял. Мы вроде externals vs submodules обсуждаем. И для subtree будет аналог, но я не пользовался, не знаю, погугли сам.
V>>>Чем докажешь простоту? V>·>Ну, например, популярностью. Даже смузи-стартапёры осиливают github. V>Простота != Популярность. Осиливают через гуй, ага.
И что? А svn и через гуй не осиливают.
V>>>Я могу. Количеством команд и ключей в гите и в свн. Первый явно проигрывает. V>·>Мдеее, отличная идея! Ну что-ж, давай сравним сколько сколько команд ключей понадобится для простой задачи, например, поискать ревизию с помощью bisect в svn vs git. V>Ревизию на основе чего?
Обычно — найти ревизию в которой данный баг возник (или проще говоря новый тест поломался). Т.е. пишет тебе кастомер: "я использовал версию 1.23.45, у вас там выдавало 24, а когда обновился на 2.34.56, то стало выдавать 42. Почему?". Между версиями 1.23.45 и 2.34.56 — несколько тысяч ревизий. Что будешь делать?
V>>>·>В какую-нибудь игрульку типа FIFA, конечно, можешь. А какой-нибудь серьёзный проект — без ревью и прочего — да кто ж тебе позволит что-то заливать? Или тебя Торвальд зовут? V>>>Какое это имеет отношение к гиту, это давно можно делать во всех системах контроля версий. У гита здесь нет преимущества. V>·>Так это можно делать и без систем контроля версий, хоть в твиттере! И что? V>Тем более, получается твиттер заменил гит.
Не заменил, ибо с гитом — проще.
V>>>·>Ну раз не требует, не подписывай. А то что требует — приходится подписывать. V>>>Для чего требует? V>·>Для sensitive кода. V>Что такое not sensitive код?
Поломка (случайная или намеренная) не несёт серьёзных финансовых последствий.
V>>>Объясни сначало как подпись что-то изменит? Всю репу в гите можно перегенерить со своими коммитами, в чем же тогда преимущество сей подписи? V>·>Ты правда не знаешь как подпись работает? Если ты перегенеришь репу, то подпись станет невалидной, очевидно. Придётся только переподписать, но для этого у тбея должен быть приватный ключ. V>Зачем с существующими правами доступа что-то подписывать?
Да ё-моё. Почитай что такое Электронная Подпись и если возникнут конкретные вопросы — задавай.
V>>>Более того, попробуй что-либо зазеркалировать с одного места в две гитовых пустых репы c кучей сабтрии, одна ошибка и бац — в двух абсолютно одинаковых репах разные подписи, просто потому-что порядок мержа где-то незначительно сдвинулся и всё, хеши поплыли в далёкое плавание. V>·>Чё? Если репы одинаковы (т.е. sha1 снапшотов идентичен), то неподписанную ревизию можно просто выкинуть и использовать подписанную. V>Это работает только в пределах одной репы, а не между репами. Между репами ты сам назначаешь связи и типы подветок.
Что работает? tree id одинаков глобально, ибо https://en.wikipedia.org/wiki/Content-addressable_storage
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, so5team, Вы писали:
S>·>Потому что это антипаттерн. S>svn:externals -- это инструмент. Он работает так, как было задумано. Инструмент не может быть антипаттерном. S>Если вы говорите об антипаттерне, значит вас не устраивает то, как svn:externals используется. Ну тогда расскажите, что именно вас не устраивает и почему. Пока же непонятно, что именно вы вложили в слова "работает очень хреново". Ссылку на stackoverflow повторять не нужно, там какая-то ерунда написана, о чем там же и сказали во втором ответе.
Антипаттерном является не использовать точные ревизии в externals.
S>>>·>И в этом сценарии с submodules проблем меньше, т.к. с ветками проще работать. S>>>И как же соотносится одно с другим? И почему, если с submodules все так хорошо, то в Интернете полно статьей типа вот этой: Git subtree: the alternative to Git submodule? S>·>Нет, не всё хорошо, я бы даже сказал, что всё плохо. Но при этом не хуже, чем externals. S>Хотелось бы все-таки услышать более подробное объяснение вот этого: "И в этом сценарии с submodules проблем меньше, т.к. с ветками проще работать." S>Как именно соотносится удобство работы с ветками и использование submodules?
Например, создать новую ветку|тег для репо со всеми его submodules — гораздо удобнее в git.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
С учетом зависимостей ты такого скорее всего вообще не найдешь.
