| 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.22, Аноним (22), 06:44, 29/05/2020 [^] [^^] [^^^] [ответить]
| +3 +/– | |
>Попробуйте хранить в гите .blend файлы
Двойное нeнужнo. Прекрасно храним .ma, .mb, .hip фанеры и файлы в perforce и он не раздувается. 👍
| | |
| |
| |
| |
| 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 +/– | мне для себя, не для мартышек Есть вещи которые делаются в нескольких параллель... большой текст свёрнут, показать | | |
| |
| |
| 10.74, пох. (?), 18:31, 29/05/2020 [^] [^^] [^^^] [ответить] | –1 +/– | но мне не нужно уметь извлекать патчи из рассылки И отправлять их обратно, что ... большой текст свёрнут, показать | | |
| |
| |
| 12.80, пох. (?), 22:14, 29/05/2020 [^] [^^] [^^^] [ответить] | +/– | Меня не интересуют ваши любимые привычные костыли и обязательность ношения намор... текст свёрнут, показать | | |
|
| |
| |
| 13.84, пох. (?), 10:30, 30/05/2020 [^] [^^] [^^^] [ответить] | +/– | ну а еще подробнее - какие задачи мож у меня и нет таких и в чем неудобство ... большой текст свёрнут, показать | | |
| |
| |
| 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 у нас бесполезное ненужно, потому что работает только в репозитор... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| 2.6, Аноним (6), 23:34, 28/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
А нужен ли гит, если его используемые фичи перекрываются 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 +/– |
> Всё верно. А распоследняя версия оказалась заброшенной в полуразобранном
> состоянии лет пять назад, когда основной и единственный разработчик
> решил продолжить саморазвитие в другой компании.
я тут наблюдаю картинку "иногда они возвращаются". Вам казалось, что п-ц уже давно настал? Нет, вам казалось! ;-)
| | |
|
|
|
| 4.54, Аноним (54), 13:37, 29/05/2020 [^] [^^] [^^^] [ответить]
| +/– |
У нас на работе всего 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 +/– | поправил, не благодари Чтобы пользоваться электропилой - не нужно понимать как ... большой текст свёрнут, показать | | |
|
| |
| 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
| | |
| |
| |
| 3.18, DiabloPC (ok), 03:10, 29/05/2020 [^] [^^] [^^^] [ответить]
| –1 +/– |
 Ага, а потом непонятно каким образом затолкать её в локальное дерево. Ню-ню
| | |
|
| |
| 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.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'ом.
> Чё как, хорошо владеете гитом? Учиться никогда не поздно, да?
учиться выбирать инструмент, не требующий зазубривания миллиона идиотских ключиков, и решающи твои задачи, а не перпендикулярные твоим задачи божка-с-пальцовкой - вам уже поздно.
| | |
|
|
|
