The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск системы управления версиями Apache Subversion 1.14.0

28.05.2020 23:11

Организация Apache Software Foundation опубликовала релиз системы управления версиями Subversion 1.14.0, который отнесён к выпускам с длительным сроком поддержки (LTS), обновления для которого будут выходить до 2024 года. Несмотря на развитие децентрализованных систем, Subversion продолжает пользоваться популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal и OpenSCADA. Отмечается, что в едином SVN-репоизитории проектов Apache хранится около 1.8 миллионов ревизий с информацией об изменениях в проектах.

Ключевые улучшения Subversion 1.14:

  • Добавлена команда "svnadmin build-repcache", при помощи которой можно актуализировать состояние кэша "rep-cache", включающего сведения о дубликатах, используемые в механизме дедупликации Representation Sharing (rep-sharing, позволяет существенно сократить размер репозитория за счёт хранения дублирующихся данных только один раз). Команда может применяться для добавления в кэш недостающих элементов для указанного диапазона ревизий, например, после того как дедупликация временно отключалась и кэш потерял актуальность.
  • В привязках SWIG для языка Python и тестовом наборе реализована поддержка Python 3. Технически написанный на Python код по-прежнему можно использовать с Python 2.7, но тестирование и исправление ошибок, связанных с данной веткой прекращено в связи с окончанием времени жизни Python 2. Python не является обязательным компонентом Subversion и используется при сборке в тестах и в привязках SWIG.
  • Опции "--quiet" и "--diff" в команде "svn log" теперь не являются взаимоисключающими, что, например, упрощает отображение только различий в диапазоне ревизий.
  • В "svn info --show-item" добавлен аргумент "changelist".
  • При запуске заданного пользователем редактора, например, при интерактивном разрешении конфликтов, обеспечено экранирование спецсимволов в путях к редактируемому файлу. Изменение решает проблемы с редактированием файлов, имена которых включают пробелы и спецсимволы.
  • Продолжено тестирование экспериментальных команд "svn x-shelve/x-unshelve/x-shelves", которые позволяют отдельно отложить незавершенные изменения в рабочей копии, чтобы срочно поработать над чем-то другим, а затем вернуть недоделанные изменения в рабочую копию, не прибегая к таким ухищрениям как сохранение патча через "svn diff" с последующим его восстановлением через "svn patch".
  • Продолжено тестирование экспериментальной возможности сохранения слепков состояния коммитов ("commit checkpointing"), позволяющая сохранить снапшот изменений, еще не зафиксированных коммитом, и позднее восстановить в рабочей копии любую из сохранённых версий изменений (например, чтобы откатить состояние рабочей копии в случае ошибочного обновления).
  • Продолжено тестирование экспериментальной команды "svn info --x-viewspec" для вывода спецификации, описывающей текущую рабочую копию. Описание включает информацию об ограничении глубины подветок, исключении подветок, переключении на другой URL или обновлении до нового номера ревизии, по сравнению с родительским каталогом.


  1. Главная ссылка к новости (https://blogs.apache.org/found...)
  2. OpenNews: Выпуск системы управления версиями Apache Subversion 1.12.0
  3. OpenNews: Уязвимость в Git, Subversion и Mercurial, допускающая подстановку команд через URL ssh://
  4. OpenNews: Bitbucket прекращает поддержку Mercurial
  5. OpenNews: Ценой перевода Mercurial на Python 3 может стать шлейф непредвиденных ошибок
  6. OpenNews: Анонсирован публичный хостинг Heptapod для открытых проектов, использующих Mercurial
Лицензия: CC-BY
Тип: Программы
Короткая ссылка: https://opennet.ru/53047-subversion
Ключевые слова: subversion, svn
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (88) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (1), 23:16, 28/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А где-нибудь можно почитать о том, почему пользователи Subversion выбирают именно его? Чем таким оно лучше того же Git'а?
     
     
  • 2.4, Аноним (4), 23:27, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Попробуйте хранить в гите .blend файлы, он моментально раздуется. А svn будет хорошо, конечно на сервере будет раздуваться, но не на каждом клиенте. То же фонд блендера свои мультфильмы в svn хостили
     
     
  • 3.5, Аноним (1), 23:32, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В гите совсем нет возможности подрезать хранимый объём старых комитов? Я честно не знаю. Я дальше пары команд из мануала не практиковал его ещё.
     
     
  • 4.47, пох. (?), 13:18, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    причем тут "старые комиты"? blend файлы вряд ли часто обновляют - хватит ровно одной копии.
    Просто потому что она огромная.

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

    Существуют ли в природе dvcs, умеющие работать только с частью дерева - учоные спорят.

    Но microsoft уже бежит к вам на помочь, со своей lfs.


     
     
  • 5.55, user (??), 13:46, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ещё одна причина не использовать монорепо. Кто сам не редактирует это блобы, тот должен их обновлять через пакетный менеджер или rsync.
     
  • 3.7, erthink (ok), 23:46, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    В git всё давно есть, только больше.
     
  • 3.22, Аноним (22), 06:44, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >Попробуйте хранить в гите .blend файлы

    Двойное нeнужнo. Прекрасно храним .ma, .mb, .hip фанеры и файлы в perforce и он не раздувается. 👍

     
     
  • 4.24, Аноним (24), 08:05, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Он же проприетарный
     
     
  • 5.29, Аноним (29), 10:00, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что плохого?
     
     
  • 6.49, пох. (?), 13:22, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    манагер денег не дает - "вот же, тут 6ешплатно. взять, взять!"

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


    А то куды бежать с hg - я вот не знаю. svn не очень подходит для параллельной работы, увы.

     
     
  • 7.61, anonymous yet another (?), 14:29, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > А то куды бежать с hg - я вот не знаю. svn
    > не очень подходит для параллельной работы, увы.

    Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются).

    Если мартышкам в руки давать --- купите что-то вроде smartgit --- там кнопки
    есть, можно давить. И обложите ограничениями прав на серверной
    стороне (под gitlab или bitbucket, ...), чтобы не порушили чего
    по природной сообразительности.

     
     
  • 8.66, пох. (?), 16:50, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    мне для себя, не для мартышек Есть вещи которые делаются в нескольких параллель... большой текст свёрнут, показать
     
     
  • 9.70, anonymous yet another (?), 17:56, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gt оверквотинг удален Видите ли, если для себя, то сильнее git а ничего нет Н... большой текст свёрнут, показать
     
     
  • 10.71, Няшмяш (?), 18:11, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gt оверквотинг удален Очень хорошо сказано ... текст свёрнут, показать
     
     
  • 11.90, Аноним (-), 23:54, 31/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Удваиваю Гит сделан живым человеком для себя и людей А вон то - корпорасами, н... текст свёрнут, показать
     
  • 10.74, пох. (?), 18:31, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    но мне не нужно уметь извлекать патчи из рассылки И отправлять их обратно, что ... большой текст свёрнут, показать
     
     
  • 11.75, Аноним (75), 19:34, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Имена у branch и tag 8212 человекочитаемы, а персистентность можно обеспечить... текст свёрнут, показать
     
     
  • 12.80, пох. (?), 22:14, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Меня не интересуют ваши любимые привычные костыли и обязательность ношения намор... текст свёрнут, показать
     
     
  • 13.91, Аноним (91), 00:00, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Ну, затарься качественным бухлом и пистолетом Можешь даже в кредит, это уже не ... текст свёрнут, показать
     
  • 11.82, anonymous yet another (?), 00:14, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Это что, легенда какая-то или психологическая травма Есть ситуации когда так уд... большой текст свёрнут, показать
     
     
  • 12.83, anonymous yet another (?), 09:45, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Немножко времени есть, подкину информации по P4 Работать с источниками в ней не... большой текст свёрнут, показать
     
     
  • 13.84, пох. (?), 10:30, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    ну а еще подробнее - какие задачи мож у меня и нет таких и в чем неудобство ... большой текст свёрнут, показать
     
     
  • 14.86, anonymous yet another (?), 11:03, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Я коротко Время для трёпа закончилось Я реферат писать не буду С источниками ... большой текст свёрнут, показать
     
  • 14.92, Аноним (91), 00:06, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Если ты о профакивании изменений в дереве при git pull - то это сделать для нача... текст свёрнут, показать
     
     
  • 15.95, пох. (?), 12:12, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    лолшта Эксперты опеннета Заметно что гит они пользуют исключительно по метод... текст свёрнут, показать
     
  • 7.64, Аноним (64), 16:13, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    hg был хорош, особенно в плане мержей и конфликтов, жаль git победил.
     
     
  • 8.65, пох. (?), 16:36, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    там обратная беда была - иногда таки и впрямь ненужно тащить свою внутреннюю кух... большой текст свёрнут, показать
     
     
  • 9.85, пох. (?), 10:32, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    да, а histedit у нас бесполезное ненужно, потому что работает только в репозитор... текст свёрнут, показать
     
  • 3.93, Роман (??), 04:49, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Используйте меркуриал, он хранит дифы
     
  • 2.6, Аноним (6), 23:34, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А нужен ли гит, если его используемые фичи перекрываются svn с запасом? Смотришь на том же гитхабе - один проект, один автор и одна ветка. Смахивание на попытку вскопать огород вскрышным экскаватором.
     
     
  • 3.11, Аноним (24), 00:00, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Кстати, гитхаб поддерживает работу с svn-клиентами
     
     
  • 4.36, пох. (?), 10:32, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это не github, а git-svn поддерживает.
    Причем делает это так, что лучше бы не поддерживал - может кто нормальное бы что написал (только вряд ли)

    Ты видел, во что оно превращает историю и логи на обоих концах цепочки?

     
     
  • 5.62, anonymous yet another (?), 14:35, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > это не github, а git-svn поддерживает.
    > Причем делает это так, что лучше бы не поддерживал - может кто
    > нормальное бы что написал (только вряд ли)
    > Ты видел, во что оно превращает историю и логи на обоих концах
    > цепочки?

    Это руки из ... . Можно и аккуратно делать. И чинить
    эпичекие концептуальные мегаумствования аторов subversion
    (это каждый раз уникально; я думал, я всё уже видал, но
    они там всё равно находят свежие назамутнённые мыслью приёмы).

     
  • 3.15, имя (ok), 01:15, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А нужен ли гит, если его используемые фичи перекрываются svn с запасом? Смотришь на том же гитхабе - один проект, один автор и одна ветка.

    Смотришь на том же sourceforge на пользователей svn, а там всё то же самое. Тем временем у продвинутой аудитории вместо срачей «merge или rebase» сплошные форумные треды о том, как же правильно пользоваться ветками — это, по-вашему, «перекрытие с запасом»? А васяны, пишущие в стол и никуда не собирающиеся в данный момент публиковать код, чертыхаясь, пытаются поднять svnserve, не осиливают или решают, что для их поделки это слишком дофига телодвижений, и возвращаются к разведению «новых папок (2)».

     
     
  • 4.37, пох. (?), 10:40, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    и, надеюсь, идут в макдак продавцами Потому что что нагуанокодит ниасилятор под... большой текст свёрнут, показать
     
     
  • 5.58, user (??), 13:50, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Гит на сервере - ССЗБ. Неосиляторы rsync должны страдать.
     
     
  • 6.67, пох. (?), 16:53, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Гит на сервере - ССЗБ. Неосиляторы rsync должны страдать.

    а история ненужна, ага.


      

     
     
  • 7.79, user (??), 21:10, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Разрабатывать прямо на проде? Мсье знает толк в адреналине и вазелине.
     
  • 3.20, Аноним (20), 04:24, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Ты юродивый или прикидываешься? На дядю работал когда-нибудь разрабом? Как еще нормально девелопить, когда вас на проекте десяток и всем нужно вливать результат своего труда в "общее дело" без какой-либо боли в голове и жопе на ровном месте? Только механика бранчевания и спасает.
     
     
  • 4.38, Линус (?), 10:43, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > всем нужно вливать результат своего труда в "общее дело"

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

    > без какой-либо боли в голове и жопе

    а у меня ничего и не болит!

     
  • 4.42, Аноним (42), 12:13, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Не шуми, мальчик. Сходи к взрослым дядям, например, сюда https://codereview.qt-project.org и посмотри, на каком суку они крутили твоё брэнчевание. И твои коммиты им тоже нафиг не нужны. Их надо в один преобразовывать. А потом ещё посмотри на тему линейности истории.
     
     
  • 5.45, пох. (?), 12:29, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Сходи к взрослым дядям

    а вот это точно взрослые?

    > И твои коммиты им тоже нафиг не нужны.

    действительно. Им вообще никто не нужен.

    > Их надо в один преобразовывать.

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

    > А потом ещё посмотри на тему линейности истории.

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

     
     
  • 6.60, anonymous yet another (?), 14:19, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > зачем вам вообще какая-то история? Вы все равно не знаете что с ней делать.
    > Версия у вас может быть только самая распоследняя. Остальное немодно и немолодежно.

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

     
     
  • 7.68, пох. (?), 16:54, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Всё верно. А распоследняя версия оказалась заброшенной в полуразобранном
    > состоянии лет пять назад, когда основной и единственный разработчик
    > решил продолжить саморазвитие в другой компании.

    я тут наблюдаю картинку "иногда они возвращаются". Вам казалось, что п-ц уже давно настал? Нет, вам казалось! ;-)

     
     
  • 8.72, anonymous yet another (?), 18:14, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    - А что делать - Плюнь в рожу вождю ... текст свёрнут, показать
     
  • 4.54, Аноним (54), 13:37, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    У нас на работе всего 3 программиста, но без веток вообще ничего сделать невозможно.
     
  • 3.53, Аноним (54), 13:36, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    А если появится 2-3 автора? Сразу будет много веток
     
     
  • 4.69, пох. (?), 17:06, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А если появится 2-3 автора? Сразу будет много веток

    они у вас что - один и тот же файл переписывают? Проект настолько спагетти-кодом, что трогает один, а в тарелке что-то начинает шевелиться у другого?
    Бегите оттуда!

    Постоянное создание веток - это багофича (by design) гита, работающие в транке рано или поздно нечаянно делают pull поверх своего наработанного, и потом прибегают ко мне с воплями "как провернуть фарш назад?" Это при условии что им хотя бы forced push недоступен. А то бегать можно уже кругами только будет.

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

     
     
  • 5.73, anonymous yet another (?), 18:16, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/

    > В svn ветки создаются только когда нужно параллельно поддерживать разные версии проекта.
    > Параллельно работать над разными частями можно без всяких веток, он именно
    > на такой режим и заточен. Сломать всем репо или сломать себе
    > - ты не сможешь.

    Сможешь. Умеючи --- не долго.

     
  • 3.56, Аноним (54), 13:49, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    >А нужен ли гит,

    Мне ветки git понадобились даже когда просто по книжке занималась, git это не экскаватор.

     
     
  • 4.96, пох. (?), 12:15, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Мне ветки git понадобились даже когда просто по книжке занималась

    если копипастить из книжки - то тебе понадобится то, что там напишет автор книжки.

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

     
  • 3.94, Роман (??), 04:51, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Так такие системы как mercurial или git (если не зарываться) гораздо проще того же svn. Вот в чем штука. hg или svn - если тебе нужен совсем простой случай, делашь hg init или git init и все готово, а svn настраивать надо серверы (сервисы).
     
     
  • 4.97, пох. (?), 12:23, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Так такие системы как mercurial или git (если не зарываться) гораздо проще
    > того же svn.

    покажите хоть один пример.

    > если тебе нужен совсем простой случай, делашь hg init или git
    > init и все готово, а svn настраивать надо серверы (сервисы).

    А, понятно. Можете уже не показывать. Эксперт опеннета в треде, ховаемся.

    svnadmin create  - разумеется чем-то супер-глобальным отличается от git init. Ага.
    Неумением прочитать ман из десяти строк. Зато urban legends наслушаться.

     
  • 4.99, anonymous yet another (?), 22:31, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > Так такие системы как mercurial или git (если не зарываться) гораздо проще
    > того же svn. Вот в чем штука.

    Subvsrsion проще. Т.е. тривиальнее. И git и mercurial
    гораздо сильнее. Но hg попытался очеловечиться, tempora mutantur.
    Vulgrais.

     
  • 2.9, Аноним (9), 23:51, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +6 +/
    Права доступа на директорию, получение любого файла без клонирования, обновление части проекта, блокировка файлов, externals
     
  • 2.13, erthink (ok), 00:20, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +2 +/
    1. Гитом достаточно сложно пользоваться не понимая как он работает.
    Поэтому основная причина = нежелание изучать новое и/или менять привычное.
    Адепты svn нередко говорят что в git нет "externals" (на самом деле есть submodules и subtree), нет возможности обновить часть проекта (на самом деле checkout умеет).

    2. Идеологическая разница. В svn есть центральный репозиторий/сервер, а git предлагает каждой копии быть самодостаточной. Поэтому в svn есть набор странных "фиче-костылей":
    - права доступа на директорию, в git это абсурдно (но при желании можете локально выполнить chmod/chown).
    - блокировка файлов "на сервере", в git вы хозяин локальной копии, а "на сервере" может жить множество версий без проблем.
    - и т.д. образно говоря, в git нет кучи проблем, поэтому нет средств для их преодоления.

    И этого следует принципиальное ограничение - svn плохо масштабируется по кол-ву активных участников.

    3. Иногда добавляется еще одна причина - нежелание менять кучу скриптов.

    4. Иногда примешивается "религия" - freebsd не может перейти на git...


     
     
  • 3.16, Gemorroj (ok), 01:44, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –7 +/
    по факту у гита 1 преимущество - мода (распространенность). децнтрализованность нафиг не вперлась.

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

     
  • 3.19, Ivan_83 (ok), 03:57, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Фря таки туда упорно идёт.
    Даже какой то коммитет вроде есть, и живые зеркала на гитхабе.
     
     
  • 4.27, пох. (?), 09:51, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –5 +/
    > Фря таки туда упорно идёт.

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

    Так что фря упорно идет в ту же мусорку что и линукс и по тем же причинам. Причем - опережающими темпами, ибо продукт соракатысяч обезьян вполне достаточен и один.

     
  • 3.23, Ю.Т. (?), 07:58, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл".
    А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?..
     
     
  • 4.25, Аноним (64), 08:46, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Сделал человек патч, а гит не знает

    Странный у тебя гит, мой умеет.

    git apply m.patch

     
  • 4.46, пох. (?), 12:41, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл".

    вы похоже ниасилили гит даже на уровне терминологии?
    pull может сделать только владелец репо. Ты мог бы сделать только push, но чужое репо тебе обычно недоступно на запись.

    В наше время при нынешних размерах того ПО - очень неудобно работать с присылаемыми порезанными помельче патчами. Поэтому вполне разумно как раз делать pull-request (для неосиляторов: это _просьба_ владельцу сделать pull from me), в терминах гитшлака.

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

    Что не мешает доверенным разработчикам - работать в обход, напрямую с репо.

    > А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?..

    и патч скорее всего - тоже г-но, он ведь такой еще много чего не знает. Как программировать уж точно не.

    Так что если уж ниасилено даже нажать кнопочку clone me on github (гит для этого, кстати, знать незачем) - ну его нахрен тратить время разработчиков на такого альтернативно-одаренного.

     
     
  • 5.50, Ю.Т. (?), 13:26, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >> В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл".
    > вы похоже ниасилили гит даже на уровне терминологии?
    > pull может сделать только владелец репо. Ты мог бы сделать только push,

    А мужики-то и не знали. Я передал ЖАРГОН разработчиков, затычка ты в каждую бочку.

    >> А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?..
    > и патч скорее всего - тоже г-но, он ведь такой еще много
    > чего не знает. Как программировать уж точно не.

    Один ты всё на свете знаешь. "Одна только горесть -- никто не читает".

     
     
  • 6.52, пох. (?), 13:33, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А мужики-то и не знали. Я передал ЖАРГОН разработчиков

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

    И себя же описал в "а гит не знает".

    > "Одна только горесть -- никто не читает".

    опять мимо. Никто не читает твои сверхценные патчи, которые ты не умеешь правильно подать - это да.

    Порог вхождения, все такое. Ниасилил? Попробуй обратись в debian - там любят умственно-отсталых.

     
     
  • 7.59, Ю.Т. (?), 14:03, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Компенсируем что-то, да никак не выкомпенсируем.

    > Порог вхождения, все такое. Ниасилил? Попробуй обратись в debian - там любят
    > умственно-отсталых.

    Ну я тебе уклончиво ответил.

     
  • 3.31, пох. (?), 10:14, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    поправил, не благодари Чтобы пользоваться электропилой - не нужно понимать как ... большой текст свёрнут, показать
     
  • 2.48, anonymous yet another (?), 13:19, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Вопрос не корректный. subversion старше, а не лучше.
     
     
  • 3.51, пох. (?), 13:27, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    два года разницы в двадцатилетнем проекте имеют очень больше значение. (нет)

    subversion отпочковался от cvs в 2000м, bitkeeper который кое-как скосплеили в git - всучили линусу в 2002м.

     
     
  • 4.63, anonymous yet another (?), 14:51, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/

    > subversion отпочковался от cvs в 2000м, bitkeeper который кое-как скосплеили в git
    > - всучили линусу в 2002м.

    И первое не верно и второе тоже.

     

  • 1.2, Аноним (4), 23:20, 28/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –4 +/
    Только не говорите что устарело, может в вашем open source git победил, но в работе с мультимедией и тяжелыми исходниками в серьёзных корпорациях ваш гит будет сливать в чистую. Там где надо загрузить одну картинку размером 900 Кб придётся клонировать весь репозиторий терабайт на 5
     
     
  • 2.8, gitover (?), 23:47, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • +4 +/
    git lfs? нет - не стлышал...
     
     
  • 3.10, Аноним (24), 23:57, 28/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Костыль
     
     
  • 4.17, Аноним (17), 02:36, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Да, ну и что?
     
  • 2.12, no country for old men (?), 00:07, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Чукча не читатель, чукча -- писатель.
    https://git-lfs.github.com/
     
  • 2.14, хотел спросить (?), 00:34, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –2 +/
    можно вытащить с веб морды.. например в GitLab
     
     
  • 3.18, DiabloPC (ok), 03:10, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Ага, а потом непонятно каким образом затолкать её в локальное дерево. Ню-ню
     
     
  • 4.44, пох. (?), 12:21, 29/05/2020 Скрыто модератором
  • +/
     
     
  • 5.76, Anonymoustus (ok), 19:43, 29/05/2020 Скрыто модератором
  • +3 +/
     
     
  • 6.77, Няшмяш (?), 19:51, 29/05/2020 Скрыто модератором
  • +1 +/
     
     
  • 7.78, Anonymoustus (ok), 20:18, 29/05/2020 Скрыто модератором
  • –1 +/
     
  • 6.81, пох. (?), 22:40, 29/05/2020 Скрыто модератором
  • +/
     
  • 2.21, Аноним (20), 04:25, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Дядь, почитай про sparse checkout.
     
     
  • 3.57, Аноним (75), 13:50, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    > git-sparse-checkout - Initialize and modify the sparse-checkout configuration, which reduces the checkout to a set of paths given by a list of patterns.

    По моему это про checkout, а не про clone, нет?

    > THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR, AND THE BEHAVIOR OF OTHER COMMANDS IN THE PRESENCE OF SPARSE-CHECKOUTS, WILL LIKELY CHANGE IN THE FUTURE.

    Не внушает доверия.

     

  • 1.26, КО (?), 09:21, 29/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >не прибегая к таким ухищрениям как сохранение патча через "svn diff" с последующим его восстановлением через "svn patch".

    А я то просто еще одну папку с транком делал и в ней уже правил. Но, наверное, это слишком сложно. :)

     
     
  • 2.39, пох. (?), 10:49, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Это сложно, если бы ты правил не одну строчку, потому что ты теперь не можешь результат своих правок вмержить в предыдущую - ты можешь только закомитить их в репо, если тебе это разрешено, или вручную (потому что нет локальных комитов) собирать патчи поштучно. Старайся ничего не забыть и не перепутать.

    А еще есть места где используется svn, но файлики могут лежать только в одном-единственном специальном месте. Потому что в других они не будут работать.

     

  • 1.28, ALex_hha (ok), 09:53, 29/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    > И этого следует принципиальное ограничение - svn плохо масштабируется по кол-ву активных участников.

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

     
     
  • 2.35, пох. (?), 10:27, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • –1 +/
    это вообще не имеет ни малейшего отношения к svn. Только к дисциплине разработки.
    Если у вас кто угодно может что угодно запушить в remote/master - не вижу чем это будет отличаться в лучшую сторону от работы с svn. Кто первым успел, того будут тапки, кто нет - делает новый rebase и снова пытается успеть пока туда не закомитили что-то еще - а то снова rebase и снова успеть-успеть.

    Только вот в svn никто не мешает любому количеству _доверенных_ людей работать в разных частях репо (а система прав доступа - не позволит случайно наломать дров) - и им не придется стоять в очереди на push.

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

     

  • 1.30, ALex_hha (ok), 10:07, 29/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Дядь, почитай про sparse checkout

    Слышал звон ... чтобы его настроить ты сначала должен клонировать всю репу ;)

    "Sparse checkout" allows populating the working directory sparsely. It uses the skip-worktree bit (see git-update-index[1]) to tell Git whether a file in the working directory is worth looking at. If the skip-worktree bit is set, then the file is ignored in the working directory. Git will not populate the contents of those files, which makes a sparse checkout helpful when working in a repository with many files, but only a few are important to the current user.

     
     
  • 2.34, Аноним (64), 10:21, 29/05/2020 [^] [^^] [^^^] [ответить]  
  • +/
    Акелла то промахнулся.
     
  • 2.87, Аноним (20), 11:18, 30/05/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Это вариант раз

    git clone --no-checkout
    git sparse-checkout init --cone
    git sparse-checkout set <your dir>

    Это вариант два

    git clone --filter=blob:none --no-checkout

    Чё как, хорошо владеете гитом? Учиться никогда не поздно, да?

     
     
  • 3.98, пох. (?), 12:30, 01/06/2020 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > git clone --no-checkout

    спасибо за 500 мегабайт неудаляемого мусора в .git
    Мне станет гораздо легче что 100 из них не будут сдублированы checkout'ом.


    > git clone --filter=blob:none --no-checkout

    мне нужен был blob - но только один, а не стопиццот. И не нужна его история изменений, в пятидесяти копиях. Его все равно нельзя сравнить diff'ом.

    > Чё как, хорошо владеете гитом? Учиться никогда не поздно, да?

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

     

  • 1.89, Ilya Indigo (ok), 05:36, 31/05/2020 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Я так и знал, что зайдя в ветку svn буду читать про git! :-)
    P.S. Ради этого и зашёл! :-)
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру