1. Куча / Говнокод #13271

    +107

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    Jenkins Auto-Updater added a comment - Today 00:35
    
    UNSTABLE: Integrated in contoso #223
    
    Create unit test for CN-858; Currently fails

    Запостил: someone, 30 Июня 2013

    Комментарии (127) RSS

    • показать все, что скрытоЕсли присмотреться видно что автор - гандон.
      Ответить
    • вот так, даже без комментариев?
      Ответить
    • В следующем коммите тест пройдёт, в третьем будет рефакторинг
      Ответить
    • Я живу с надеждой написать (в свободное от работы время...) CI сервер использующий elnode (хотя бы просто ради изучения). Дженкинс при всей его популярности... иногда хочется просто обидеться и не разговаривать больше.
      Просто идея использовать Яву для чего-то, где однозначно нужны скрипты - и зачем они это сделали?..

      ЗЫ. Компания пользуется билдбоксом. Дженкинс мой персональный, подпольный, т.как пока ИТ что-то сделает...
      Ответить
      • > использовать Яву для чего-то, где однозначно нужны скрипты
        В яве из коробки есть ЯваСкрипт... Почему бы и нет?
        Ответить
        • > В яве из коробки есть ЯваСкрипт..
          да ладно? где?
          Ответить
          • ScriptEngine, не?
            Ответить
            • черт, не знал. спасибо.
              Ответить
            • Неспроста ЯваСкрипт так называется.
              Ответить
              • мне тут в соседнем посте намекнули что сей язык должен называться джаваСкрипт и ни как иначе.
                Ответить
                • Ява и ЯваСкрипт. Джава и ДжаваСкрипт. Названия меняются, связь остается ;)
                  Ответить
                  • Скажите, а долго переучиваться писать на Яве, если я уже Джаву знаю?
                    А правда, что вы имеете ввиду под "Ява", острова индонезии, сигареты или мотоцикл?
                    Ответить
        • Потому что по законум Мерфи сломается обязательно не в жабоскрипте. Ну и тут дело такое: в жабоскрипте не предусмотренно ничего для работы с файловой системой, вообще с десктопом. И опять же использовать Яву только для того, чтобы писать на жабоскрипте? - ну так почему бы тогда просто на жабоскрипте не писать. А так и джа-тон есть и даже ПХП есть на Яве написаны.
          Ответить
          • писать надо на том, чем лучше владеешь.
            Ответить
            • Писать надо на том, что удобно в контексте задачи.
              Ответить
              • глупо писать на Си, если я забыл Си. лучше я напишу на java\jni
                Ответить
                • Сильно зависит от задачи. Если нужно что-то системно-зависимое и/или шибко низкоуровневое, часто проще обратно выучить C/C++. Заодно избавишь пользователей от необходимости устанавливать жабомашину.
                  А если коллег много и они не знают жабы, то вообще писать на жабе смысла мало.

                  Но в целом, конечно, многие задачи неплохо решаются жабой.
                  Ответить
                  • иногда можно и тянуть обрезанную жаба-машину с целевым софтом
                    Ответить
                    • На контроллер с 2кб оперативы ;)
                      Ответить
                      • о, это же совсем другое дело
                        Ответить
                      • MT6225, там ажно "48K Bytes on-chip SRAM".
                        Ещё должны быть смарт-карты с поддержкой оной, но по памяти ничего не гуглится. Должно быть что-то типа Java Card.
                        Ответить
            • Нужно кому? Если мы о пользователях... то им как раз нужно, чтобы программист писал на том языке, который лучше подходит к задаче, и, желательно, конечно, выучил бы его. Иначе, например, получится Линукс кернел на Питоне. Текстовый редактор на SQL и еще много можно придумать похожих интересных програм.
              Ответить
              • Драйвер на пышечке.
                А что вы скажете на счет приложений под вынь 8 на js ? просто интересно.
                Ответить
          • > использовать Яву только для того, чтобы писать на жабоскрипте?

            Нет, писать ядро на простой и богатой библиотеками жабе, заточенной на многопоточность, и дать юзерам возможность по-быстрому говнявкать скрипты на жабоскрипте.
            К примеру, ElasticSearch использует для обновлений индекса ScriptEngine (причём можно выбирать язык, по дефолту MVEL). Redis умеет евалить Lua-скрипты, хоть сам написан на сишке.

            > в жабоскрипте не предусмотренно ничего для работы с файловой системой

            Биндим в жабе пару объектов в контекст перед вызовом скрипта, профит. Только API нужно будет документировать.
            Ответить
            • В Женкинсе ядро? там, если по-честному так мало этого ядра нужно. Женкинс - типичная Ява программа (читай слон в посудной лавке) в мире Юникса: вместо того, чтобы пользоваться системными утилитами (cron, tar, gzip и т.д.) она использует Явовские недоделки, и не дает их заменить на что-то более полезное. И таким образом имеем, что при наличие в системе хороших средств для архивации, билды можно архивировать только в zip. При наличие в окружении нужных переменных, мы не можем их использовать в именах файлов, т.как Женкинс не умеет в раскрытие путей. При наличие установленного httpd нужно пользоваться сервером Женкинса и т.д.
              Скрипт делающий то же самое был бы и компактнее, и возможностей больше, и позволил бы пользователю работать со знакомыми программами (которые он может под себя заточил).
              Написать часть Женкинса на другом языке (скриптовом)? - до этого была одна проблема с Явой, теперь их стало две.
              Ответить
              • А теперь задумайтесь, почему в жабопрограммы всё ещё включают всякий шлак в виде ротации логов, шедулера тасок и гзипов. Быть может потому, что дохрена людей работают не под юниксом? А те, что работают под юниксом, не хотят обижать коллег?
                Ответить
                • Так ранзица-то в подходе, а не в наличие. Если бы программа себя вела так: вам нравится gzip? - пользуйтесь, нравится, но не установил? - ну так установи. Нету / не знаешь как установить? - ну так возьми наш замечательный zip.
                  Но ведь программа, вместо того, чтобы сделать по-человечески (дополнить) делает по-уродски (заменят).
                  Это типичный стиль корпоративного мЫшления - а т.как подавляющее большинство Явистов мЫшлют по-корпоративному, то и пишут такие уродские программы. Им просто даже в голову не приходит, через какую жопу они это делают.
                  Ответить
                  • Можно было бы баттхёртить, будь по дефолту RAR. Люди ради вас же стараются, включают всё необходимое в стандартную поставку, чтобы не приходилось настраивать 100500 переменных на пустом месте.

                    Если у вас проблемы, попробуйте на досуге поиграться с buildbot.
                    Ответить
                    • > по дефолту RAR
                      RAR не нужен *.

                      * не вброс, он действительно не нужен. Век дискет уже давным-давно прошел.
                      Ответить
                      • Я знаю, что он не нужен. Поэтому и считаю его достаточным условием баттхёрта.
                        Ответить
                      • а почему RAR? он лицензий требует. обычно ZIP хватает. см. тот же gzip *.tar.gz
                        Ответить
                        • Консольный RAR и без лицензии работает (только функция подписи будет выключена). Хотя его время вышло, когда появился открытый 7-zip.
                          Ответить
                          • однако его везде используют...
                            и да, 7z научился встраиваться в систему, в частности, в контекстное меню?
                            Ответить
                            • вроде, еще много лет тому назад это было
                              Ответить
                              • как-то WinRAR удобнее в смыгле гуя
                                Ответить
                                • 7zip уже практически догнал, при этом он бесплатный и апинсорс, т.е. не будет бугуртящих преподов, рассказывающих, что я не смог открыть Ваш архив под своим недоюнипсом.
                                  Ответить
                            • В контекстное меню чего?
                              Ответить
                              • https://dl.dropboxusercontent.com/u/73797209/Screenshot-1.png
                                Ответить
                                • Так, как на скриншоте, 7z добавляется в меню инсталлятором уже давно автоматически.

                                  Вы так говорите, как будто если бы инсталлятор этого не делал, добавить в реестр пару строчек для распаковки архива было бы трудно:
                                  REGEDIT
                                  HKEY_CLASSES_ROOT\.tar = tarfile
                                  HKEY_CLASSES_ROOT\tarfile\shell\extract = "Распаковать"
                                  HKEY_CLASSES_ROOT\tarfile\shell\extract\command = tar.exe xf "%1"

                                  Кстати, а для каких архиваторов есть хелперы типа zipfldr.dll, чтобы не открывать лишних окон при просмотре?
                                  Ответить
                            • > и да, 7z научился встраиваться в систему, в частности, в контекстное меню?

                              Он это всегда умел... o_O
                              Ответить
                          • >RAR
                            >открытый 7-zip.
                            Метью Махони смотрит на эти слова с легким недоумением.
                            PS А еще есть хацкильный free arc.
                            Ответить
              • > билды можно архивировать только в zip
                Читаются на всех осях* из коробки. Сжатие шустрое и вполне приличное. Зачем что-то еще?

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

                Если что-то и было бы полезно - так это совсем не архиваторы, а плагины для генерации deb/rpm/msi и прочих инсталляшек.

                * Шиндовз ниже XP осью не считаем.
                Ответить
                • а что не так в шиндошс хр? даже там зип тоже из коробки
                  Ответить
                • Чем хорош tar + gzip в отличие от zip? - Ну так тем, что это архиватор, который сначала создает один большой файл из множества маленьких, а потом этот один большой и архивирует. zip - сжимает каждый файл по-отдельности, и потом всех склеивает. Если у меня билды производят текстовые файлы (исходники программы) то используя zip я теряю кучу дискового пространства (а билды бы хотелось архивировать, да побольше...).
                  И в конце концов, я пользуюсь Эмаксом, в нем tar+gzip поддерживается замечательно, а zip - на уровне редактора - не особо. Почему я должен забивать на любимый редактор изза какой-то недоделки в CI сервере?

                  > Если что-то и было бы полезно - так это совсем не архиваторы, а плагины для генерации deb/rpm/msi и прочих инсталляшек.
                  CI сервер для этого не предназначен. Просто сбилдить и оповестить всех заинтересованых о результатах. rmp / msi - это уже заботы инструментов сборки, типа SCons / rake и иже с ними.
                  Ответить
                  • > я пользуюсь Эмаксом, в нем tar+gzip поддерживается замечательно, а zip - на уровне редактора - не особо
                    И вы это считаете проблемами дженкинса? :)

                    > кучу дискового пространства
                    В век дискет, 40 гиговых винтов, cd-rw и GPRS'а по 9 рублей за метр я бы полностью с вами согласился... Тогда я жал все в непрерывные RAR архивы, и считал это нормальным... Но у tar.gz, как и у любого непрерывного архива есть недостаток - довольно медленный seek и перечисление файлов. А ведь если вы хотите править файлы внутри архива прямо из редактора это немаловажно?

                    P.S. Исходники libc в tar.gz весят 23 метра, в zip - 30 (в обоих случаях дефолтовый уровень сжатия). Оно точно того стоит?
                    Ответить
                    • Да, естесственно, это проблемы Женкинса - какого хрена он не использует мой архиватор?
                      Почему я должен платить хоть один американский цент больше за идиотизм другого программиста? Мало ж. диски стоят? - почему автор Женкинса мне их в подарок не пришлет - то ж фигня копеечная?
                      Кроме непосредственно хранения, это еще время на отсылку их по сети. У нашей компании три больших оффиса и еще несколько по-меньше, в Израиле, Канаде и на Украине. Почему изза идиотизма разработчика Женкинса человек должен ждать в два раза больше, пока билд скачается?
                      Просто почему делать через жопу то, что уже было сделано нормально?
                      Ответить
                      • Люди сделали вполне юзабельный продукт и позволяют пользоваться им бесплатно. Ругать их за то, что он вас не устраивает - как минимум некрасиво. Тем более что сами вы сделали для сообщества примерно нихуя. Если у вас что-то не устраивает в опенсорсе - исправляйте, контрибьютеры всегда приветствуются.
                        Ответить
                        • Замечательная логика: если бесплатно, значит хорошо, и ругать не нужно. И в чем связь?
                          Не вам судить о том, что я сделал и для кого, уж поверьте, вы ничего об этом не знаете. Опять же, пусть бы даже не было никакого моего личного вклада в развитие чего бы то ни было - какая связь между качеством программы и моим вкладом?
                          В мире есть очень много примеров посредственных / низкопробных продуктов, которыми пользуются не потому, что они такие хорошие, а потому что привыкли / нет хороших альтернатив. Женкинс - один из них.
                          Если вы посмотрите сюда:
                          http://en.wikipedia.org/wiki/Comparison_of_continuous_integration_software
                          то увидите, что по-сути кроме Трависа, Женкинса и Билдбота ничего и нет. Но Травис заточен специально под Гитхаб...
                          Ответить
                          • > если бесплатно, значит хорошо, и ругать не нужно

                            Собственно, от вас кроме ругани всего кроме Emacs и CL сложно что-то услышать.

                            CI я сам настраивал не раз, и bulidbot, и Jenkins, и CruiseControl. У всех систем свои недостатки, порой весьма неприятные. Но называть их разработчиков дебилами у меня как-то язык не поворачивается. Тем более, бьюсь об заклад, у вас нет в закромах собственной CI-системы, которую бы все похвалили. Люди делали продукты не для вас, а для себя. И поделились ими с сообществом на добровольных началах. Если вас что-то в них не устраивает - исправляйте, в этом суть опенсорса и его сила. Угодить на всех в гетерогенных средах - очень непростое занятие, поэтому и приходится выбирать метод наименьшего знаменателя.

                            А уж брызжать слюнями, доказывая иллюзорный идиотизм - совершенно бесполезное и безрезультатное занятие.
                            Ответить
                            • И в чем смысл противоречия? Почему не может быть так, что есть много разновидностей одного и того же, и все - плохие? Вы когда-нибудь ходили на выборы в какой-нибудь орган власти? Ничего не напоминает?
                              Нет, я не знаю ни одного хорошего CI сервера - и это не делает Женкинс лучше, а ынтырпрайз мышление более приемлимым.
                              Почему я не могу сожалеть о такой плохой ситуации? Сожаление о плохой ситуации - это единственная мотивация для ее изменения.
                              Идиоты ли авторы Женкинса? - во всем - нет. В реализации конкретной возможности - да.
                              С чего вы взяли, что я не исправлю и не пошлю патч разработчикам? Наоборот, с какого перепугу я бы стал патчить, если бы меня все устраивало?
                              Ответить
                              • > С чего вы взяли, что я не исправлю и не пошлю патч разработчикам?

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

                                Кстати, неплохо было бы увидеть ссылку на патч.
                                Ответить
                                • > царского
                                  Не упоминай Царя всуе.
                                  Ответить
                                • На самом деле есть другие, более насущные проблемы, над которыми я сейчас работаю.
                                  Я очень обломался изза плохой поддержки Сигвина, и пытаюсь с этим что-то сделать.
                                  Но в процессе работы уже много раз возникало желание просто сделать по-новой. Особенно от того, что от Явы тошнит. Я уже выше говорил о том, что хочу попробовать приспособить elnode для этого - судя по всему, этим все и закончится.
                                  Ответить
                                  • > хочу попробовать приспособить elnode

                                    Ваш преемник будет Вас ненавидеть. Ну и в конечном счёте Вы убъёте кучу времени и врядли получите что-то хотя бы отдалённо похожее на нормальный CI-сервер.
                                    Ответить
                  • tar+gzip - это жалкое подобие непрерывных архивов rar? Не нужен.
                    Ответить
                    • Ну толсто же. А gzip + tar это, по вашему, жалкое подобие обычных архивов rar?
                      Ответить
                      • tar не умеет упаковывать, а gzip не умеет работать с несколькими файлами. тогда как rar умеет и то, и другое в одиночку
                        Ответить

                        • tar не умеет упаковывать и нарезать на тома
                          gzip не умеет работать с несколькими файлами и нарезать на тома
                          split не умеет упаковывать и работать с несколькими файлами

                          Тогда как rar умеет это все.

                          Вывод: unix говно.
                          Ответить
                          • более того, rar понимает tar.gz, а tar+gzip не понимают rar
                            Ответить
                            • Кстати, надо будет потроллить людей, упаковывая архивы в .rar.gz (отключив сжатие у rar'а) и .tar.rar.

                              P.S. Хотя можно и .rar.rar, где первый rar с отключенным сжатием, а второй сжимает один файл.
                              Ответить
                              • я думаю, их и так троллят достаточно таким сценарием:

                                скачиваем кучу архивов *.part??.zip
                                распаковываем каждый отдельно, получаем кучу томов *.r??
                                распаковываем, получаем один *.zip архив
                                радуемся, что в нем находится нужное.
                                Ответить
                        • Анскиллед питузок детектед.
                          Ответить
                      • Да это вообще нихуя не троллинг был. Что, подгорает? Аж 3 минуса навесили.

                        Более того, непрерывные архивы имеют смысл только при нормальном размере словаря. У gzip он 64 кбайт, у рара - до 16 мбайт вроде бы, по дефолту 4. У 7z аналогично. Так что прыщебляди соснули, но им не привыкать.
                        Ответить
                        • А у bzip2 какой размер словаря?
                          Ответить
                          • Хуй его знает, но по сравнению с раром у него скорость ощутимо меньше, если выставить сравнимую степень сжатия.
                            Ответить
                        • В догонку: чтобы распаковать файл из непрерывного архива, нужно распаковать все файлы до него, или даже все обьединенные файлы в его потоке (рар вроде бы не всегда заводит один поток на весь непрерывный архив). Чтобы распаковать один файл, даже первый, из tar.*, нужно полностью распаковать весь тар.
                          Ответить
                          • > нужно полностью распаковать весь тар
                            Зачем полностью? Только предыдущие. Последующие файлы на упаковку предыдущих никак не влияют.

                            P.S. Но в .tar.gz еще и заголовки размазаны по всему архиву и пожаты, поэтому чтобы посмотреть список файлов, придется распаковать весь поток.
                            Ответить
                            • >Зачем полностью? Только предыдущие.
                              А так кто-то умеет? Winrar полностью распаковывает tar только для показа оглавления. В любом случае, из всех знакомых мне архиваторов только rar может располагать файлы в нужном порядке в непрерывных архивах, чтобы readme.txt было в самом начале, причем как минимум с бородатой версии 2.0 под дос. Опенсорсные воры (7zip) это еще не успели прыщеукрасть (15 лет, совсем некуда спешить, как обычно).

                              Кстати, в непрерывных архивах rar вроде бы может иметь несколько потоков, а gz - только один, т.е. для распаковки одного файла по любому надо будет распаковать все файлы перед ним.

                              Собсно, 7z - самое лучшее, что было у щвабодных мозолеедов. На их счастье, архиваторы достигли пика развития, и фичи 10-летней давности потихоньку были прыщеукрадены и перекочевали в швабодный продукт. Не пора ли вылезти из подвала?
                              Ответить
                              • > только rar может располагать файлы в нужном порядке в непрерывных архива
                                Если тебе эта фича очень-очень-очень нужна, то добавь сначала очень-очень важные файлы, а затем добавь все остальные. Тар это умел с самого создания. И никаких гуитыкалок или специализированных опций для этого не нужно. Или ты пакуешь каждую версию своей софтины в рар через гуитыкалку, любовно кликая мышкой по README и прочим важным файлам, чтобы они легли первыми?

                                > Опенсорсные воры (7zip) это еще не успели прыщеукрасть
                                > прыщеукрадены и перекочевали в швабодный продукт.
                                Откуда такая ненависть к швабодке и опенсурсу?
                                Ответить
                                • >Если тебе эта фича очень-очень-очень нужна, то добавь сначала очень-очень важные файлы, а затем добавь все остальные. Тар это умел с самого создания. И никаких гуитыкалок или специализированных опций для этого не нужно. Или ты пакуешь каждую версию своей софтины в рар через гуитыкалку, любовно кликая мышкой по README и прочим важным файлам, чтобы они легли первыми?
                                  Оло ло, а ну ка луркай RarFiles.lst

                                  >Откуда такая ненависть к швабодке и опенсурсу?
                                  Ну посмотри сам - в 2010-х 7zip только-только, наконец-то, подобрался по функционалу к винрару начала 2000х, все остальное у него без шансов сосало. Зип, вон, до сих пор в юникод не умеет. WinHTTTrack - глючная копия Teleport Pro родом из 90х. Про опен офис и мс офис известно. И т.д.
                                  Ответить
                            • Может и не размазаны, хз. Если размазаны, фейл, конечно, получается капитальный.
                              Ответить
                • Причины баттхёртов раскрыты - емакс толком не может в зип.
                  Ответить
                  • что, впрочем, удивительно
                    я добавлял в один проект требуемую поддержку .zip архивов - там достаточно взять из поставки полтора файла и написать нужные врапперы, передающиеся в zlib_filefunc_def
                    Ответить
                    • Вы не поняли, что значит "не может", и естесственно, не заметили самый главный аргумент: zip занимает в два раза больше дискового пространства.
                      Эмакс поддерживает навигацию, поиск, итеративное добавление / удаление из tar+gzip, а к zip он может только применить то, что есть в системе, т.е. в общем случае сжатие / раzжатие.

                      К примеру, Вижуал Студия не может и того, что может Эмакс при работе с zip файлами.
                      Ответить
                      • zip архивы тоже умеют расти и удалять файлы поштучно внутри себя, а мой far manager легко позволяет не распаковывая весь архив по нему пошариться, причем в последнем случае это касается не только .zip, но и .tar.gz, .7z, .rar и прочей мудотени - т.е. всё то же самое, что должен делать хваленый emacs
                        и да, сэкономить пару метров места на рабочем харде при редактировании кода текущего проекта - да это же киллер-фича, сейчас же деинсталлирую вижуал студию!
                        Ответить
                        • > и да, сэкономить [del]пару метров[/del][ins]пару сотен гигабайт на билд сервере[/ins] места на рабочем харде.
                          Ответить
                          • > пару сотен гигабайт
                            Это в сумме или каждый билд?
                            Ответить
                            • В суме, нет, с такими большими билдами не сталкивался.
                              Ответить
                          • сотен гигабайт? текстовых исходников в архиве?
                            зачем вы скачиваете интернет?
                            Ответить
                            • Не, wvxvw говорит о хранении, допустим, тысячи архивов.

                              Если весь набор исходников в tgz весит в районе 300мег, и к-т сжатия будет примерно как я замерял выше для либц (zip на 30% больше, чем tgz), то получим где-то 100 метров разницы на каждом архиве, на 1000 таких архивов как раз получатся те самые 100 гигов.
                              Ответить
                              • он говорит про билд сервер
                                билд сервер собирает версии
                                а затем собранным версиям и так положено быть упакованными и они лежат не на билд сервере - а на специальном архивном сервере

                                но к примеру, 100 гигов версий (даже не дельту в 100 гигов) в архивах наша контора не накопила и за 15 лет - но наверное мы и не крайзис не пишем, текстуры не храним
                                причем, если уж хранить результат - ну так я бы призадумался о lzma (7z), а не взял старый tar.gz (только потому, что мой редактор умеет работать только с ним)
                                Ответить
                                • > билд сервер собирает версии
                                  Да, я знаю об этом...

                                  Но wvxvw выше писал: "Если у меня билды производят текстовые файлы (исходники программы)". Т.е. все-таки там текст.

                                  Но мне не совсем понятно зачем копаться в этом выхлопе и править его эмаксом. Он ведь сгенерен :)
                                  Ответить
                              • P.S. Но 100-200 гиг это как бы мелочи даже для нашей провинциальной конторы. А если фирма ворочает проектом с исходниками на 300 метров, то она явно не нищебродская, и может себе позволить нормальное хранилище...
                                Ответить
                              • У жабы на выходе никакой не текст, а (ненужные) класс-файлы и jar/war/ear-архивы, которые уже зипфайлы. Сложно сказать какая там избыточность, и сколько можно сыкономить, сжимая зип-архивы таром, а не зипом.
                                Ответить
                                • > У жабы на выходе никакой не текст
                                  "Если у меня билды производят текстовые файлы (исходники программы)"
                                  Ответить
                                  • > у меня билды производят текстовые файлы (исходники программы)

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

                                      Ждем жизненного примера, в котором wvxvw понадобилось поправить выхлоп билдсервера ;)
                                      Ответить
                                • Билды производят аж ты емелю, жабьи скрипты и циклические таблицы стиеля. При чем компиляется именно Ява, а конткретно GWT.
                                  Ответить
                      • > Эмакс поддерживает навигацию, поиск, итеративное добавление / удаление из tar+gzip, а к zip он может только применить то, что есть в системе, т.е. в общем случае сжатие / раzжатие.
                        Ну и какие такие проблемы возникли при реализации этих фишек? Ну кроме лени и ненужности zip'а для авторов эмакса, конечно.

                        > при работе с zip файлами
                        Зачем вообще вам понадобилось копаться внутри архивов при помощи IDE? Гвозди тоже отверткой закручиваете?

                        > zip занимает в два раза больше дискового пространства.
                        Выше был пример с libc, на котором zip больше на 30%, а не в два раза. Или исходники libc недостаточно текстовые и недостаточно однообразные, чтобы преимущества непрерывного архива начали проявляться?
                        Ответить
                        • Ну вы не знаете Эмакс, поэтму мне вам будет тяжело объяснить.
                          Например, в эмаксе есть специальный интерактвный поиск-замена по файлам реализованая через интерфейс Диреда, у нее есть специальный режим редактирования, с удобно подобранными коммандами, настроенной подсветкой, интеграцией с другими макросами / пользовательскими функциями добавленными к редактору.
                          Система множественных выделений, выделений по шаблону, комбинации выделений, теги, закладки и т.д.
                          Увы, пользователю редактора типа Вижуал Студии это просто не объяснить...

                          > Зачем вообще вам понадобилось копаться внутри архивов при помощи IDE? Гвозди тоже отверткой закручиваете?
                          Потому что я так же выполняю административную работу, где копирование, архивация и т.д. - это то, что я делаю, каждый день? Если ваш редактор этого делать вообще не умеет, то не нужно это знание экстраполировать на остальных.
                          Ответить
                          • А зачем вообще вручную править содержимое архивов? И даже если вдруг нужно (хотя я таким никогда не страдал), почему не написать скрипт перепаковки на том же python?
                            Ответить
                            • Потому что все думаю, что это не нужно, а в итоге - нужно каждый раз...
                              Ответить
                              • Если каждый раз, то пора этот шаг автоматизировать и триггерить на билде.

                                Кстати, основной общий недостаток CI-серверов, который превращает воспроизводимость билдов не более чем в миф - конфиги CI-сервера, как правило, лежат отдельно от проекта (только travis вроде правильнее сделан и цепляет конфиг из дерева исходников).
                                Это означает, что при смене шагов билда легко можно поломать сборку старых версий.
                                Ответить
                                • Ну как это обычно происходит:
                                  - на билд сервере есть папка, куда складываются патчи на время когда билд еще не у QA, но уже нельзя коммитить.
                                  - всегда найдется кто-то, кто забудет туда патч положить, или вспомнит об этом слишком поздно, или перепутает папки. Когда людей много, то такие ошибки становятся постоянными.
                                  - билд уходит QA на тестирование, и в первый день, а вернее несколько часов сразу после выясняется, что а) не билдится, б) что-то забыли.
                                  - начинается поиск того, что забыли, в итоге находится, но билдить в это время уже нельзя (т.е. нельзя поднимать версию). И приходится вручную что-то добавлять / изменять.
                                  Каждый раз кто-то получает (не-)строгий выговор, и история в точности повторяется.
                                  Ответить
                                  • Пендец какой-то...

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

                                    Столько бесполезного секса, и все ради удовлетворения бюрократического "нельзя поднимать версию билда"...
                                    Ответить
                                    • Ведь даже ручные патчи лучше, чем гит, так ведь? Ну не ветку же с хотфиксом создавать!
                                      Ответить
                                      • Причем забавно, но я не вижу никакого смысла в требовании "нельзя поднимать версию билда". А в требованиях "крайне нежелательно модифицировать билд (не его номер, а контент!) во время прохождения QA" и "два отличающихся билда не могут иметь один номер" я его по какой-то необъяснимой причине вижу.

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

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

                                            Эм... Время коммита в гите не имеет никакого значения и не может иметь в принципе в распределённой среде, где каждый мог настроить какое угодно время. Последовательность коммитов определяется так, как и должна: отношением родитель - потомок в графе версий.
                                            Закоммитить в "мастер" в принципе невозможно (без --force, разумеется, но за это сажают на кол), пока не смёржишься с ним в локальном репозитории.

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

                                                По sha-1 дайджесту родителя, разумеется. Время бессмысленно, только граф имеет значение.
                                                Ответить
                                                • Ну и родитель у двух коммитов один и тот же, и что дальше?
                                                  Ответить
                                                  • Тот, кто коммитит в ветку первым, сдвигает её HEAD. Следующий уже не сможет запушить свой коммит, т.к. парент этого коммита не совпадает с HEAD ветки. Ему придётся сделать pull, смёржить коммиты и сделать повторный push.

                                                    Почитайте уже, как гит работает. Крайне занимательно.
                                                    Ответить
                                              • > между системным временем и тем, временем, которое использует стевой адаптер

                                                tell me moar
                                                Ответить
                                                • http://stackoverflow.com/questions/16884170

                                                  Я даже пытался разузнать, может быть ситуация не такая уникальная - но похоже что я наблюдаю очередную лажу с датами какого-то народного умельца, только в этот раз пожелавшего остаться неизвестным.
                                                  Ответить
                                            • ЗЫ. Мерж автоматический, все сделал сам, ничего не заподозрив.

                                              a47acba *   
                                                      |\  Merge: b89b409 4dc3e12
                                                      | | Author: Я
                                                      | | Date:   Sun Jun 2 15:51:33 2013 +0100
                                                      | | 
                                                      | |     Merge branch 'preliminary' of ssh://**** into preliminary
                                              4dc3e12 | *   
                                                      | |\  Merge: 3cdc9ec e9c9934
                                                      | | | Author: Не я
                                                      | | | Date:   Sun Jun 2 17:37:17 2013 +0300
                                                      | | | 
                                                      | | |     Merge branch 'preliminary' of ssh://**** into preliminary
                                              3cdc9ec | * | 
                                                      | | | Author: Не я
                                                      | | | Date:   Sun Jun 2 17:36:02 2013 +0300
                                                      | | | 
                                              b89b409 * | | 
                                                      | |/  Author: Я
                                                      |/|   Date:   Sun Jun 2 15:42:14 2013 +0100
                                                      | |   
                                              e9c9934 * | 
                                                      | | Author: Я
                                                      | | Date:   Sun Jun 2 15:33:14 2013 +0100
                                                      | | 
                                              b71cd4a * | 
                                                      |/  Author: Я
                                                      |   Date:   Sun Jun 2 15:13:11 2013 +0100


                                              Коммит a47acba был сделан на самом деле за два часа до 4dc3e12
                                              Ответить
                                              • > Мерж автоматический, все сделал сам, ничего не заподозрив

                                                Что в очередной раз доказывает, что гит клал на даты коммитов.
                                                Ответить
                                                • Ну да, конечно, и поэтому коммит + пуш, которые были сделаны на два часа раньше в итоге были записаны после другого коммит + пуш сделанных на два часа позже?
                                                  А заставило его принять такое решение тоф факт, что время при общении с моим компьютером было расчитано не правильно.
                                                  Подозрение пока на то, что ради прихотей wmwire хоста были сделаны какие-то странные настройки в сети изза которых что-то сломалось. Как результат, все программы написанные на Си почему-то при вызове системных функций связанных со временем получают строго гринвичевское время (wmwire host не может, или не мог когда-то работать ни в какой другой тайм-зоне). Почему-то .NET программы и даже C++ получают нормальное время... Кроме того, тим-фортерес и перфорс (судя по рассказам ИТ) отказывались синхронизироваться, если время на компьютерах в локальной сети отличалось больше чам на сколько-то минут. Оставшиеся ИТ теперь плохо понимают, что тогда было сделано, но факт отстается таким, что у меня на компутере программы на разных языках показывают разное время.
                                                  ЗЫ. +1 в логе коммита - это ДСТ.
                                                  Ответить
                                              • > Коммит a47acba был сделан на самом деле за два часа до 4dc3e12

                                                a47acba - это результат мёржа b89b409 и 4dc3e12, он не мог быть сделан на 2 часа раньше предка, это буллшит.

                                                В 15.42 был ваш коммит, в 15.37 (поправка на косяк со временем) - не ваш. Вы сделали pull, произошёл автомёрж транка с вашим коммитом в 15.51 (по локальному времени, разумеется).

                                                Нет никакой магии, всё как и должно быть: забили на время, используются отношения между версиями.
                                                Ответить
                                                • 1. Все это происходило между 5 и 6 часами вечера по локальному времени. В три часа по локальному времени с репозиторием никто не работал.
                                                  2. Не ту циферку скопировал, b89b409 - мой коммит, ну как бы можно сказать, что a47acba - тоже мой коммит, т.как получился врезультате мержа того самого моего коммита. Он был на самом деле самым первым в этой серии коммитов. Два следующих за ним коммита должны были его "исправить", в итоге, он "исправил" два последующих коммита. Т.е. врезультате мержа были использованы мои сорцы а не из 3cdc9ec.

                                                  А... о... я понял еще в чем проблема. Время то отображается у меня, и оно очевидно вычисляется неправильно на моей системе. Лог на сервере выглядит по-другому :О
                                                  Ответить
                                                  • Сам граф и всё содержимое репозитория и алгоритмы мёржа и etc. от локального времени никак не зависит. От времени зависит только то, как git log нарисует вам этот граф. Больше ничего.
                                                    Ответить
                                                    • Ну блин, вот здесь Merge: b89b409 4dc3e12 изменения из 4dc3e12 должны били переписать изменения из b89b409 - а получилось наоборот.
                                                      Я теперь уже и сам не понимаю почему так. Но это то, что получилось.
                                                      Ответить
                                                      • > изменения из 4dc3e12 должны били переписать изменения из b89b409 - а получилось наоборот

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

                                                        То, какой коммит отображается выше в рисунке git log действительно определяется временем коммита. Но на работу самого гита это абсолютно не сказывается. На любом сервере git log будет отображать изоморфный граф ревизий.
                                                        Ответить

    Добавить комментарий