А еще, гитхаб и меркуриал, в отличие от svn, не позволяет выкачать только отдельную папку в репозитории. И когда в этом репозитории, из которого мне нужно получить исходный код, что бы сделать какой-нибудь фикс, лежит 100 гигабайт ненужного мне хлама в виде картинок и прочих файлов — я очень сильно огорчаюсь.
Не хочу обижать тут дизайнеров и прочие профессии, но гитхаб предназначен для хранения исходного кода. Для программистов. Я не могу посоветовать вам сервис, поскольку я программист, а не дизайнер (или как вы там еще называетесь). Не любой текстовый файл является исходным кодом. Если текстовый файл, занимающий более 100МБ может быть открыт в текстовом редакторе, это еще не значит, что он подлежит версионированию в системе контроля исходного кода. Рекомендую ознакомиться, для чего предназначен гитхаб: github.com/about
Предположим у нас 10 ревизий, в каждой ревизии вы добавляеете файл на 10 гигов, и удаляете такой-же файл (но другой) из предыдущей ревизии. Делая клон такого репо с ревизией #10 вы вытянете по сети 100 гигабайт данных (все 10 файлов), не смотря на то, что вы выбрали конкретную десятую ревизию. Экономией в следствии сжатия блобов я принебрег, ибо для примера это не существенно. Вы все еще утверждаете, что система версионирования кода подходит для аналогичных целей в отношении к бинарникам?
Есть большая разница, нагружать сервер передачей файлов, или просчитыванием дельт внутри них. Каждый инструмент должен использоваться для того, для чего он предназначен. Рекомендую ознакомиться с github.com/about (ключевое слово code) прежде, чем хаять гитхаб за закручивания гаек.
Да вы что такое говорите. Механизмы версионирования бинарников абсолютно другие. Текстовые дельты абсолютно не применимы к бинарникам. Хранить бинарники в SCM типо SVN/Git/Mercurial — нагружать сервер лишними обработками, поскольку там не хранятся файлы, там хранятся дельты от самого рождения репозитория. Когда делают клон репозитория, это процесс воссоздания наложения дельт друг на друга с момента рождения репозитория в локальной папке. Бинарники в случае с Nexus/Artifactory (да даже линусковыми apt/yum) храняться как файлы, каждая версия в своем каталоге. Объеденины мета-данными и индексными файлами, где указаны контрольные суммы, версии и так далее. Отдаются как статик ресурсы по http или другому протоколу. Чувствуете разницу?
Простите, но гитхаб все-таки предназначен для кода, исходного кода. Программ. А не фотошоповских макетов. Если руководство вашей компании этого не понимает, это не проблемы гитхаба.
Да, такое много где можно встретить. Это называется legacy, и это то, от чего надо уходить. Потому гитхаб все правильно сделал. Цели тут не разные, тут ошибка архитектуры проекта. С репозитариями бинарников все так-же удобно устанавливать новые версии в продакшн и откатываться когда нужно. Даже еще удобнее.
Все верно, любым бинарникам не место в SCM, только причем тут рапидшара итд? Бинарники должны попадать в проект на этапе сборки (привет, пхпшники). И брать их можно из репозитария бинарников. Для джавы это Nexus, Artifactory и еще несколько других примеров.
В 21 были изменения, связанные с подписыванием. Подписанные через устаревшую JDK апплеты не будут работать, пока их не подпишут JDKu21. Неужели, опять в 25?
Весьма громкое заявление. Не боитесь, что наплыв HRов не будет давать вам спать после такого?
А если серьезно, то с первым абзацем абсолютно согласен. Но во втором вы сами себе противоречите. Спорю, что какой-нибудь большой контракт-монитор-чегототам-крутой-менеджер, который будет расчитан на огромные мировые корпорации и концерны, вы не напишите на Java без J2EE?
В данном конкретном случае на видео, тренарный оператор забрал у меня возможность переключатся между контекстами блоков кода (где у нас и-или-или, а где сам код конкретного кейса). Дело привычки, наверное. Но для меня код стал сложнее. Короче ведь не всегда лучше, а то снова начнем называть переменные a, b и c.
Я с вами полностью согласен. Но мы с вами не составляем большинство. Как уже не раз здесь говорили, для большинства в наше время компьютер сводится к браузеру.
А если серьезно, то с первым абзацем абсолютно согласен. Но во втором вы сами себе противоречите. Спорю, что какой-нибудь большой контракт-монитор-чегототам-крутой-менеджер, который будет расчитан на огромные мировые корпорации и концерны, вы не напишите на Java без J2EE?