forum.opennet.ru - "Выпуск системы управления версиями Apache Subversion 1.14.0" (92)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
Сообщение от opennews (??), 28-Май-20, 23:16
Организация Apache Software Foundation опубликовала релиз системы управления версиями Subversion 1.14.0, который отнесён к выпускам с длительным сроком поддержки (LTS), обновления для которого будут выходить до 2024 года. Несмотря на развитие децентрализованных систем, Subversion продолжает пользоваться популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. Из использующих Subversion открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal и OpenSCADA. Отмечается, что в едином рSVN-епоизитории проектов Apache хранится около 1.8 миллионов ревизий с информацией об изменениях в проектах... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53047
Ответить \| Правка \| Cообщить модератору

Оглавление

А где-нибудь можно почитать о том, почему пользователи Subversion выбирают именн, Аноним (1), 23:16 , 28-Май-20, (1)

Попробуйте хранить в гите blend файлы, он моментально раздуется А svn будет хо, Аноним (4), 23:27 , 28-Май-20, (4) –4

В гите совсем нет возможности подрезать хранимый объём старых комитов Я честно , Аноним (1), 23:32 , 28-Май-20, (5) –1

причем тут старые комиты blend файлы вряд ли часто обновляют - хватит ровно о, пох. (?), 13:18 , 29-Май-20, (47) –1

Ещё одна причина не использовать монорепо Кто сам не редактирует это блобы, тот, user (??), 13:46 , 29-Май-20, (55)

В git всё давно есть, только больше , erthink (ok), 23:46 , 28-Май-20, (7) +2
Двойное нeнужнo Прекрасно храним ma, mb, hip фанеры и файлы в perforce и он , Аноним (22), 06:44 , 29-Май-20, (22) +3

Он же проприетарный, Аноним (24), 08:05 , 29-Май-20, (24) –3

А что плохого , Аноним (29), 10:00 , 29-Май-20, (29) +1

манагер денег не дает - вот же, тут 6ешплатно взять, взять Лучше б рассказал , пох. (?), 13:22 , 29-Май-20, (49) –1

Вообще-то git сильно мощнее hg будет а концептуально они довольно сильно пересе, anonymous yet another (?), 14:29 , 29-Май-20, (61)

мне для себя, не для мартышек Есть вещи которые делаются в нескольких параллель, пох. (?), 16:50 , 29-Май-20, (66) –2

gt оверквотинг удален Видите ли, если для себя, то сильнее git а ничего нет На, anonymous yet another (?), 17:56 , 29-Май-20, (70) +1

gt оверквотинг удален Очень хорошо сказано , Няшмяш (?), 18:11 , 29-Май-20, (71) +1

Удваиваю Гит сделан живым человеком для себя и людей А вон то - корпорасами, н, Аноним (-), 23:54 , 31-Май-20, (90) +1

но мне не нужно уметь извлекать патчи из рассылки И отправлять их обратно, что , пох. (?), 18:31 , 29-Май-20, (74) –1

Имена у branch и tag 8212 человекочитаемы, а персистентность можно обеспечить, Аноним (75), 19:34 , 29-Май-20, (75) –1

Меня не интересуют ваши любимые привычные костыли и обязательность ношения намор, пох. (?), 22:14 , 29-Май-20, (80)
Ну, затарься качественным бухлом и пистолетом Можешь даже в кредит, это уже не , Аноним (91), 00:00 , 01-Июн-20, (91)

Это что, легенда какая-то или психологическая травма Есть ситуации когда так удо, anonymous yet another (?), 00:14 , 30-Май-20, (82)

Немножко времени есть, подкину информации по P4 Работать с источниками в ней неу, anonymous yet another (?), 09:45 , 30-Май-20, (83)
ну а еще подробнее - какие задачи мож у меня и нет таких и в чем неудобство х, пох. (?), 10:30 , 30-Май-20, (84)
Я коротко Время для трёпа закончилось Я реферат писать не буду С источниками в, anonymous yet another (?), 11:03 , 30-Май-20, (86)
Если ты о профакивании изменений в дереве при git pull - то это сделать для нача, Аноним (91), 00:06 , 01-Июн-20, (92)
лолшта Эксперты опеннета Заметно что гит они пользуют исключительно по методи, пох. (?), 12:12 , 01-Июн-20, (95)

hg был хорош, особенно в плане мержей и конфликтов, жаль git победил , Аноним (64), 16:13 , 29-Май-20, (64) –1

там обратная беда была - иногда таки и впрямь ненужно тащить свою внутреннюю кух, пох. (?), 16:36 , 29-Май-20, (65)

да, а histedit у нас бесполезное ненужно, потому что работает только в репозитор, пох. (?), 10:32 , 30-Май-20, (85)

Используйте меркуриал, он хранит дифы, Роман (??), 04:49 , 01-Июн-20, (93)

А нужен ли гит, если его используемые фичи перекрываются svn с запасом Смотришь, Аноним (6), 23:34 , 28-Май-20, (6) –1

Кстати, гитхаб поддерживает работу с svn-клиентами, Аноним (24), 00:00 , 29-Май-20, (11)

это не github, а git-svn поддерживает Причем делает это так, что лучше бы не под, пох. (?), 10:32 , 29-Май-20, (36) –1

Это руки из Можно и аккуратно делать И чинитьэпичекие концептуальные мега, anonymous yet another (?), 14:35 , 29-Май-20, (62)

Смотришь на том же sourceforge на пользователей svn, а там всё то же самое Тем , имя (ok), 01:15 , 29-Май-20, (15) +1

и, надеюсь, идут в макдак продавцами Потому что что нагуанокодит ниасилятор под, пох. (?), 10:40 , 29-Май-20, (37) –1

Гит на сервере - ССЗБ Неосиляторы rsync должны страдать , user (??), 13:50 , 29-Май-20, (58)

а история ненужна, ага , пох. (?), 16:53 , 29-Май-20, (67) –1

Разрабатывать прямо на проде Мсье знает толк в адреналине и вазелине , user (??), 21:10 , 29-Май-20, (79) –1

Ты юродивый или прикидываешься На дядю работал когда-нибудь разрабом Как еще н, Аноним (20), 04:24 , 29-Май-20, (20) +3

порежьте помельче, у меня в экран не влазиет, каждый патч заверните, пришлите в , Линус (?), 10:43 , 29-Май-20, (38) +2
Не шуми, мальчик Сходи к взрослым дядям, например, сюда https codereview qt-p, Аноним (42), 12:13 , 29-Май-20, (42) –1

а вот это точно взрослые действительно Им вообще никто не нужен чтобы уже точ, пох. (?), 12:29 , 29-Май-20, (45) –1

Всё верно А распоследняя версия оказалась заброшенной в полуразобранномсостояни, anonymous yet another (?), 14:19 , 29-Май-20, (60) +1

я тут наблюдаю картинку иногда они возвращаются Вам казалось, что п-ц уже дав, пох. (?), 16:54 , 29-Май-20, (68) –1

- А что делать - Плюнь в рожу вождю , anonymous yet another (?), 18:14 , 29-Май-20, (72) +1

У нас на работе всего 3 программиста, но без веток вообще ничего сделать невозмо, Аноним (54), 13:37 , 29-Май-20, (54)

А если появится 2-3 автора Сразу будет много веток, Аноним (54), 13:36 , 29-Май-20, (53)

они у вас что - один и тот же файл переписывают Проект настолько спагетти-кодом, пох. (?), 17:06 , 29-Май-20, (69) +1

Сможешь Умеючи --- не долго , anonymous yet another (?), 18:16 , 29-Май-20, (73)

Мне ветки git понадобились даже когда просто по книжке занималась, git это не эк, Аноним (54), 13:49 , 29-Май-20, (56)

если копипастить из книжки - то тебе понадобится то, что там напишет автор книжк, пох. (?), 12:15 , 01-Июн-20, (96)

Так такие системы как mercurial или git если не зарываться гораздо проще того , Роман (??), 04:51 , 01-Июн-20, (94)

покажите хоть один пример А, понятно Можете уже не показывать Эксперт опеннета, пох. (?), 12:23 , 01-Июн-20, (97)
Subvsrsion проще Т е тривиальнее И git и mercurialгораздо сильнее Но hg попы, anonymous yet another (?), 22:31 , 01-Июн-20, (99)

Права доступа на директорию, получение любого файла без клонирования, обновление, Аноним (9), 23:51 , 28-Май-20, (9) +6
1 Гитом достаточно сложно пользоваться не понимая как он работает Поэтому основ, erthink (ok), 00:20 , 29-Май-20, (13) +2

по факту у гита 1 преимущество - мода распространенность децнтрализованность , Gemorroj (ok), 01:44 , 29-Май-20, (16) –7
Фря таки туда упорно идёт Даже какой то коммитет вроде есть, и живые зеркала на , Ivan_83 (ok), 03:57 , 29-Май-20, (19)

ну так туда уже давно набилось полно вчерародившихся, неспособных освоить ничего, пох. (?), 09:51 , 29-Май-20, (27) –5

В наше время свободное-ПО-сообщество вместо присылки патчей навязывает сделай, Ю.Т. (?), 07:58 , 29-Май-20, (23) –1

Странный у тебя гит, мой умеет git apply m patch, Аноним (64), 08:46 , 29-Май-20, (25) +1
вы похоже ниасилили гит даже на уровне терминологии pull может сделать только вл, пох. (?), 12:41 , 29-Май-20, (46) +1

А мужики-то и не знали Я передал ЖАРГОН разработчиков, затычка ты в каждую бочк, Ю.Т. (?), 13:26 , 29-Май-20, (50) –2

Скорее - единственного горе-разработчика - себя Я вот ни от каких разработчиков, пох. (?), 13:33 , 29-Май-20, (52) +1

Компенсируем что-то, да никак не выкомпенсируем Ну я тебе уклончиво ответил , Ю.Т. (?), 14:03 , 29-Май-20, (59) –1

поправил, не благодари Чтобы пользоваться электропилой - не нужно понимать как р, пох. (?), 10:14 , 29-Май-20, (31) –2

Вопрос не корректный subversion старше, а не лучше , anonymous yet another (?), 13:19 , 29-Май-20, (48) –2

два года разницы в двадцатилетнем проекте имеют очень больше значение нет subv, пох. (?), 13:27 , 29-Май-20, (51) –1

И первое не верно и второе тоже , anonymous yet another (?), 14:51 , 29-Май-20, (63)

Только не говорите что устарело, может в вашем open source git победил, но в раб, Аноним (4), 23:20 , 28-Май-20, (2) –4

git lfs нет - не стлышал , gitover (?), 23:47 , 28-Май-20, (8) +4

Костыль, Аноним (24), 23:57 , 28-Май-20, (10) –2

Да, ну и что , Аноним (17), 02:36 , 29-Май-20, (17)

Чукча не читатель, чукча -- писатель https git-lfs github com , no country for old men (?), 00:07 , 29-Май-20, (12)
можно вытащить с веб морды например в GitLab, хотел спросить (?), 00:34 , 29-Май-20, (14) –2

Ага, а потом непонятно каким образом затолкать её в локальное дерево Ню-ню, DiabloPC (ok), 03:10 , 29-Май-20, (18) –1

Скрыто модератором, пох. (?), 12:21 , 29-Май-20, (44)

Скрыто модератором, Anonymoustus (ok), 19:43 , 29-Май-20, (76) +3

Скрыто модератором, Няшмяш (?), 19:51 , 29-Май-20, (77) +1

Скрыто модератором, Anonymoustus (ok), 20:18 , 29-Май-20, (78) –1

Скрыто модератором, пох. (?), 22:40 , 29-Май-20, (81)

Дядь, почитай про sparse checkout , Аноним (20), 04:25 , 29-Май-20, (21)

По моему это про checkout, а не про clone, нет Не внушает доверия , Аноним (75), 13:50 , 29-Май-20, (57)

А я то просто еще одну папку с транком делал и в ней уже правил Но, наверное, э, КО (?), 09:21 , 29-Май-20, (26)

Это сложно, если бы ты правил не одну строчку, потому что ты теперь не можешь ре, пох. (?), 10:49 , 29-Май-20, (39) –1

Это не ограничения, а особенности svn А то с таким же успехом можно сказать, чт, ALex_hha (ok), 09:53 , 29-Май-20, (28) –2

это вообще не имеет ни малейшего отношения к svn Только к дисциплине разработки, пох. (?), 10:27 , 29-Май-20, (35) –1

Слышал звон чтобы его настроить ты сначала должен клонировать всю репу Sp, ALex_hha (ok), 10:07 , 29-Май-20, (30) +1

Акелла то промахнулся , Аноним (64), 10:21 , 29-Май-20, (34)
Это вариант разgit clone --no-checkoutgit sparse-checkout init --conegit sparse-, Аноним (20), 11:18 , 30-Май-20, (87) +1

спасибо за 500 мегабайт неудаляемого мусора в gitМне станет гораздо легче что 1, пох. (?), 12:30 , 01-Июн-20, (98) +1

Я так и знал, что зайдя в ветку svn буду читать про git - P S Ради этого и за, Ilya Indigo (ok), 05:36 , 31-Май-20, (89)

Сообщения [Сортировка по времени | RSS]

1. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (1), 28-Май-20, 23:16

А где-нибудь можно почитать о том, почему пользователи Subversion выбирают именно его? Чем таким оно лучше того же Git'а?

Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск системы управления версиями Apache Subversion 1.14.0" –4 +/–

Сообщение от Аноним (4), 28-Май-20, 23:27

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

Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от Аноним (1), 28-Май-20, 23:32

В гите совсем нет возможности подрезать хранимый объём старых комитов? Я честно не знаю. Я дальше пары команд из мануала не практиковал его ещё.

Ответить | Правка | Наверх | Cообщить модератору

47. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 13:18

причем тут "старые комиты"? blend файлы вряд ли часто обновляют - хватит ровно одной копии.
Просто потому что она огромная.
В случае svn ты можешь просто не чекаутить ненужные тебе гигасы филеза.
В случае git ты их тоже можешь не чекаутить - но легче тебе от этого не станет, поскольку они у тебя будут в .git в твоей локальной копии.
Существуют ли в природе dvcs, умеющие работать только с частью дерева - учоные спорят.
Но microsoft уже бежит к вам на помочь, со своей lfs.

Ответить | Правка | Наверх | Cообщить модератору

55. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от user (??), 29-Май-20, 13:46

Ещё одна причина не использовать монорепо. Кто сам не редактирует это блобы, тот должен их обновлять через пакетный менеджер или rsync.

Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск системы управления версиями Apache Subversion 1.14.0" +2 +/–

Сообщение от erthink (ok), 28-Май-20, 23:46

В git всё давно есть, только больше.

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

22. "Выпуск системы управления версиями Apache Subversion 1.14.0" +3 +/–

Сообщение от Аноним (22), 29-Май-20, 06:44

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

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

24. "Выпуск системы управления версиями Apache Subversion 1.14.0" –3 +/–

Сообщение от Аноним (24), 29-Май-20, 08:05

Он же проприетарный

Ответить | Правка | Наверх | Cообщить модератору

29. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от Аноним (29), 29-Май-20, 10:00

А что плохого?

Ответить | Правка | Наверх | Cообщить модератору

49. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 13:22

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

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

Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 29-Май-20, 14:29

> А то куды бежать с hg - я вот не знаю. svn
> не очень подходит для параллельной работы, увы.
Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются).
Если мартышкам в руки давать --- купите что-то вроде smartgit --- там кнопки
есть, можно давить. И обложите ограничениями прав на серверной
стороне (под gitlab или bitbucket, ...), чтобы не порушили чего
по природной сообразительности.

Ответить | Правка | Наверх | Cообщить модератору

66. "Выпуск системы управления версиями Apache Subversion 1.14.0" –2 +/–

Сообщение от пох. (?), 29-Май-20, 16:50

>> А то куды бежать с hg - я вот не знаю. svn
>> не очень подходит для параллельной работы, увы.
> Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются).
мне для себя, не для мартышек. Есть вещи которые делаются в нескольких параллельных ветках. Ветки эпизодически (кусками) мержатся, причем - в любую сторону. svn такого не любит, в нем мерж допустим только из trunk вниз.
git чудовищно неудобен - во всем (hg местами, к этому можно было привыкнуть).
Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться? Как минимум, попытка сохранить фиксацию версий говорит о том что люди делали это для себя.
> Если мартышкам в руки давать --- купите что-то вроде smartgit --- там
> кнопки есть, можно давить. И обложите ограничениями прав на серверной
и кто мержить за них будет - я? Нафиг-нафиг-нафиг.
за них гуи думают. Я поразился, поставив себе msvc, насколько вообще можно ничего не понимать в том как оно работает.

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от anonymous yet another (?), 29-Май-20, 17:56

>[оверквотинг удален]
>> Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются).
> мне для себя, не для мартышек. Есть вещи которые делаются в нескольких
> параллельных ветках. Ветки эпизодически (кусками) мержатся, причем - в любую сторону.
> svn такого не любит, в нем мерж допустим только из trunk
> вниз.
> git чудовищно неудобен - во всем (hg местами, к этому можно было
> привыкнуть).
> Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться?
> Как минимум, попытка сохранить фиксацию версий говорит о том что люди
> делали это для себя.
Видите ли, если для себя, то сильнее git'а ничего нет.
Надо идти и разбираться. Там почти всё по делу. Идеи, лежащие в основе ---
гениальны (т.е. они пригодились и позволили делать вещи, о которых
изначально и не предполагали, не трогая концепцию).
P4 для разработки --- сплошное мучение. Его концептуально, похоже,
делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ
специфичными хотелками. Всякая прочая деятельность на нём ---
хождение по мукам. Если, конечно, вам не нужен большой файлообменник
с версионированием файлов (правда сильно большие файлы нельзя,
и зараз пихать много файлов тоже нельзя).
Т.е. пользоваться можно, но за очень большие деньги.
Пользователю. За вредность.
Конторка, которая его делает --- чует конец и переобувается в консультантов
и создателей цветастых окошек поверх git'а.

Ответить | Правка | Наверх | Cообщить модератору

71. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от Няшмяш (?), 29-Май-20, 18:11

>[оверквотинг удален]
> P4 для разработки --- сплошное мучение. Его концептуально, похоже,
> делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ
> специфичными хотелками. Всякая прочая деятельность на нём ---
> хождение по мукам. Если, конечно, вам не нужен большой файлообменник
> с версионированием файлов (правда сильно большие файлы нельзя,
> и зараз пихать много файлов тоже нельзя).
> Т.е. пользоваться можно, но за очень большие деньги.
> Пользователю. За вредность.
> Конторка, которая его делает --- чует конец и переобувается в консультантов
> и создателей цветастых окошек поверх git'а.
Очень хорошо сказано.

Ответить | Правка | Наверх | Cообщить модератору

90. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от Аноним (-), 31-Май-20, 23:54

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

Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 18:31

>> Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться?
>> Как минимум, попытка сохранить фиксацию версий говорит о том что люди
>> делали это для себя.
> Видите ли, если для себя, то сильнее git'а ничего нет.
> Надо идти и разбираться. Там почти всё по делу. Идеи, лежащие в
но мне не нужно уметь извлекать патчи из рассылки. И отправлять их обратно, что характерно - тоже, я комичу в транк, да. (мне нужна _моя_ история)
А обычная моя работа в нем чудовищно неудобна. Я не хочу думать о кишках двигателя - я хочу просто пользоваться удобным инструментом - и мне совершенно все равно какая там магия под капотом. Например, без персистентных человекочитаемых версий - чудовищно неудобно. Это как раз и говорит о том, что изобретателям гитоподелки история вообще нах не вперлась, возвращаться к ней они не планируют.
> P4 для разработки --- сплошное мучение. Его концептуально, похоже,
можно все же - детали, а не мнения?
> делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ
> специфичными хотелками. Всякая прочая деятельность на нём ---
вдруг мои хотелки - совпадут.
> хождение по мукам. Если, конечно, вам не нужен большой файлообменник
> с версионированием файлов (правда сильно большие файлы нельзя,
НУЖЕН!
> и зараз пихать много файлов тоже нельзя).
сколько в граммах? "Большие" и "много" у всех свои.
> Конторка, которая его делает --- чует конец и переобувается в консультантов
> и создателей цветастых окошек поверх git'а.
останется только один, причем, как обычно, наихудший. Но я не собираюсь жить вечно.

Ответить | Правка | К родителю #70 | Наверх | Cообщить модератору

75. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от Аноним (75), 29-Май-20, 19:34

> Например, без персистентных человекочитаемых версий - чудовищно неудобно
Имена у branch и tag — человекочитаемы, а персистентность можно обеспечить административными способами

Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от пох. (?), 29-Май-20, 22:14

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

Ответить | Правка | Наверх | Cообщить модератору

91. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (91), 01-Июн-20, 00:00

> Меня интересует для себя, любимого, сделать - хорошо и удобно. Можно за деньги.
Ну, затарься качественным бухлом и пистолетом. Можешь даже в кредит, это уже не важно. Что еще разумного посоветовать можно на глобусе где Торвальдс всех как обычно порвал? :)
> И никогда-никогда не видеть убе...ских номеров комитов. Это изобрести мог
> только один человек - тот, которому нахрен не нужна история, и, соответственно, vcs вообще.
По ним на самом деле довольно удобно посылать тела совершенно не в теме в конкретные комиты.

Ответить | Правка | Наверх | Cообщить модератору

82. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 30-Май-20, 00:14

> но мне не нужно уметь извлекать патчи из рассылки. И отправлять их
> обратно, что характерно - тоже, я комичу в транк, да. (мне
> нужна _моя_ история)
Это что, легенда какая-то или психологическая травма?
Есть ситуации когда так удобно. Иногда очень удобно.
Но это далеко не единственный workflow.
> А обычная моя работа в нем чудовищно неудобна. Я не хочу думать
> о кишках двигателя - я хочу просто пользоваться удобным инструментом -
> и мне совершенно все равно какая там магия под капотом. Например,
> без персистентных человекочитаемых версий - чудовищно неудобно. Это как раз и
> говорит о том, что изобретателям гитоподелки история вообще нах не вперлась,
> возвращаться к ней они не планируют.
Persistent human-readable --- зто про r100500? Так ни в одном из вменяемых
DVCS'ов так не делают по вполне понятным причинам.
Да и централизованных системах цена этого решения сильно высока.
А смысла нет. (мало-мальски нетривиальное версионирование --- это
слабоупорядоченные множества, и смысл этой человеко-читаемости
идёт мимо).
>> P4 для разработки --- сплошное мучение. Его концептуально, похоже,
> можно все же - детали, а не мнения?
Да берите и пробуйте. По мне --- очень дорогое г. (акцент на "г.",
а не на "дорогое").
>> делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ
>> специфичными хотелками. Всякая прочая деятельность на нём ---
> вдруг мои хотелки - совпадут.
Вам виднее. На вкус и цвет, как известно, все фломастеры разные.
>> хождение по мукам. Если, конечно, вам не нужен большой файлообменник
>> с версионированием файлов (правда сильно большие файлы нельзя,
> НУЖЕН!
Так флаг вам в руки, барабан на шею и ветер в спину.
В одном кооперативе (он там и как VCS заодно используется ;))
по факту через P4 презентациями и аналогами докладных записок
(а заодно фотографиями, мувиками, ...) обмениваются.
Каждые два-три месяца на регламент ложился --- полки, наверное, доставляли.
Ну, и ценность истории при такой организации работы --- полный ноль.
Я ещё одну контору на нём знаю, но там его после меня принесли.
>> и зараз пихать много файлов тоже нельзя).
> сколько в граммах? "Большие" и "много" у всех свои.
Мне хватило, чтобы я напоролся на это при _нормальной_ работе
без извращений. Сейчас у меня этого чуда мысли образца 1980 года
под рукой нет и я этим фактом вполне удовлетворён.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

83. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 30-Май-20, 09:45

Немножко времени есть, подкину информации по P4.
Работать с источниками в ней неудобно. Все характерные
задачи при работе с источниками в ней решаются через ... .
Её, похоже, изначально делали как "хранилище конфигураций".
Однако затолкать что-то существенное (свежесобранная операционка,
в скромном варианте) не получается --- ограничение по количеству
файлов (файлов!) в транзакции. Снапшот источников ядра за одну
транзакцию тоже, кстати, не проходит.
Сравнить две "конфигурации" --- пляски с бубнами. Получить
в двух разных местах две идентичные конфигурации --- тоже
тот ещё квест. Решаемый, конечно. Но на хрена всё время
бодаться с проблемами такого рода?
Однако гвоздями прибит определённый workflow разработки, считаемый
авторами единственно верным и незыблемым.
[моё личное мнение].

Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от пох. (?), 30-Май-20, 10:30

> Немножко времени есть, подкину информации по P4.
> Работать с источниками в ней неудобно. Все характерные
> задачи при работе с источниками в ней решаются через ... .
ну а еще подробнее - какие задачи (мож у меня и нет таких?) и в чем неудобство.
> Её, похоже, изначально делали как "хранилище конфигураций".
хм, да, не мой случай (в смысле, вряд ли вышло лучше чем у svn, а той мне еще на двадцать лет хватит, благо не на пихоне писано)
> Однако затолкать что-то существенное (свежесобранная операционка,
> в скромном варианте) не получается --- ограничение по количеству
> файлов (файлов!) в транзакции. Снапшот источников ядра за одну
> транзакцию тоже, кстати, не проходит.
ну то есть несколько тысяч - вполне пройдут? Идея внезапно-появившегося в проекте ядра линуха одним куском меня не особо и так впечатляет. Линус вас, кстати, тоже осудит - "порежьте чтоб в экран влазило и заверните каждую отдельным комитом" (представьте что он вам таки разрешил вмержить в ядро zfs?).
> Сравнить две "конфигурации" --- пляски с бубнами. Получить
> в двух разных местах две идентичные конфигурации --- тоже
оно не умеет сравнивать r100101 и 100102 ? Или чекаутить 100103? Или вы что-то другое подразумевали?
> Однако гвоздями прибит определённый workflow разработки, считаемый
ну так описать-то его можете?
Меня вот гитовый workflow не устраивает - да, он не прибит гвоздями, но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни, не в сферическом вакууме.
P.S. персистентные человекочитаемые (и желательно монотонно-растущие) версии нужны хотя бы для того, чтобы я - не видя вашего номерка перед глазами, он уже уехал за край страницы  - все еще помнил что он 100500. И насторожился бы, увидев в рабочей среде вместо него 100502. А гитовую бесполезность невозможно ни запомнить, ни сравнить без diff. e90e3cf e093ecf - это одна версия или разные? Попатчте ему лог уже кто-нибудь, чтобы он показывал вместо них HEAD, HEAD~ HEAD~22 - все равно никто ни с какими другими не работает. (отдельно убить того кто придумал эти дурацкие большие буквы) Будет вполне отражать тот вокфлоу, на который он заточен - "версия должна быть последняя или ненужно".
Да, hg это попыталась решить, там никто не работает с хэшами, но эти версии локальны, что бесит - сегодня она у тебя 40, завтра мы перезалили репо - и та же версия стала 62. Понятно, почему  так, но крайне интересно было бы глянуть, как попытались сделать по-человечески.

Ответить | Правка | Наверх | Cообщить модератору

86. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 30-Май-20, 11:03

Я коротко. Время для трёпа закончилось.
>> Немножко времени есть, подкину информации по P4.
>> Работать с источниками в ней неудобно. Все характерные
>> задачи при работе с источниками в ней решаются через ... .
> ну а еще подробнее - какие задачи (мож у меня и нет
> таких?) и в чем неудобство.
Я реферат писать не буду. С источниками в P4 _мне_ работать
было не то что неудобно, а невозможно. А я с ними работать
могу и умею. Решал внешними средствами.
> ну то есть несколько тысяч - вполне пройдут? Идея внезапно-появившегося в проекте
> ядра линуха одним куском меня не особо и так впечатляет. Линус
> вас, кстати, тоже осудит - "порежьте чтоб в экран влазило и
> заверните каждую отдельным комитом" (представьте что он вам таки разрешил вмержить
> в ядро zfs?).
Во первых, задачи разные бывают. Во-вторых --- P4 неудовлетворительно
отработало почти по всем полезным workflow/use-cases. Т.е. вынужденно
жить я с ней мог, но это перманентная борьба на ровном месте.
Оно мне надо?
>> Сравнить две "конфигурации" --- пляски с бубнами. Получить
>> в двух разных местах две идентичные конфигурации --- тоже
> оно не умеет сравнивать r100101 и 100102 ? Или чекаутить 100103? Или
> вы что-то другое подразумевали?
Там модель другая. Поэтому употребляемые термины не подходят.
По смыслу --- задачу решить можно, но сравнительно трудоёмко
и достаточно глубоко предмет знать надо.
>> Однако гвоздями прибит определённый workflow разработки, считаемый
> ну так описать-то его можете?
Ещё раз: хотите, берите и пробуйте. По мне --- не существует
единственно верного workflow на все (даже только мои) случаи.
> Меня вот гитовый workflow не устраивает - да, он не прибит гвоздями,
> но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни,
> не в сферическом вакууме.
Он не навязывает никаго workflow. Как построите работу, так и будет.
Git мне в этом построении не мешает.

>[оверквотинг удален]
> ему лог уже кто-нибудь, чтобы он показывал вместо них HEAD, HEAD~
> HEAD~22 - все равно никто ни с какими другими не работает.
> (отдельно убить того кто придумал эти дурацкие большие буквы) Будет вполне
> отражать тот вокфлоу, на который он заточен - "версия должна быть
> последняя или ненужно".
> Да, hg это попыталась решить, там никто не работает с хэшами, но
> эти версии локальны, что бесит - сегодня она у тебя 40,
> завтра мы перезалили репо - и та же версия стала 62.
> Понятно, почему  так, но крайне интересно было бы глянуть, как
> попытались сделать по-человечески.
Без комментариев. Математическими основами не владеете.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

92. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (91), 01-Июн-20, 00:06

> но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни,
> не в сферическом вакууме.
Если ты о профакивании изменений в дереве при git pull - то это сделать для начала гит как раз и не даст, зарубив pull пока как минимум не заныкаешь куда-нибудь свой креатив.
> Да, hg это попыталась решить, там никто не работает с хэшами, но эти версии локальны, что бесит
Ну вот на хэш можно ссылаться глобально - и это всегда корректно. Адресат посыла всегда пойдет в правильное место. А что такое r100102 - ему может говорить столько же сколько и sha1.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

95. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от пох. (?), 01-Июн-20, 12:12

> Если ты о профакивании изменений в дереве при git pull - то это сделать для начала гит как раз
лолшта? Эксперты опеннета...
Заметно что гит они пользуют исключительно по методичке со стека, копи-пасть.
git clone
vi ...
git add && commit
git pull...ой!
и хорошо если сразу заметил. А если через три итерации - как оно чаще всего и бывает?
> даст, зарубив pull пока как минимум не заныкаешь куда-нибудь свой креатив.
а это как раз _отдельная_ ненужная глупость афтырей.
svn -даст, hg - даст. git заставляет заниматься ненужно.

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

64. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от Аноним (64), 29-Май-20, 16:13

hg был хорош, особенно в плане мержей и конфликтов, жаль git победил.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

65. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от пох. (?), 29-Май-20, 16:36

> hg был хорош, особенно в плане мержей и конфликтов, жаль git победил.
там обратная беда была - иногда таки и впрямь ненужно тащить свою внутреннюю кухню в чужой проект, а надо выдать пачку патчей поверх состояния - чужого, которое тебе нафиг не нужно.
Отражающих структуру кода (не "порежьте помельче", а структуру ;-) а не историю твоей возни с ним - потому что дальше возиться будет кто-то другой.
Это сделали через mq, и так что лучше б не делали - опять нужны ненужные знания о внутреннем устройстве инструмента.
hg был хорош пока у тебя вся разработка общая, либо ты пилишь в одно жало параллельно несколько веток (в svn мержи такие что после второй ветки проще удавиться чем за ними уследить, и именно эту проблему hg решил раз навсегда, у него любой комит это мерж)
К сожалению, по всей видимости, svn его успеет пережить.
Именно за счет авторизации, разделения доступов и возможности не таскать за собой потроха репо там, где нужен только чекаут или вообще одноразовый export.
А "распределенность" сама по себе оказалась не так полезна, как о ней рассказывали.

Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от пох. (?), 30-Май-20, 10:32

> Это сделали через mq, и так что лучше б не делали -
> опять нужны ненужные знания о внутреннем устройстве инструмента.
да, а histedit у нас бесполезное ненужно, потому что работает только в репозитории без веток - где они вообще такой нашли?!

Ответить | Правка | Наверх | Cообщить модератору

93. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Роман (??), 01-Июн-20, 04:49

Используйте меркуриал, он хранит дифы

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от Аноним (6), 28-Май-20, 23:34

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

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

11. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (24), 29-Май-20, 00:00

Кстати, гитхаб поддерживает работу с svn-клиентами

Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 10:32

это не github, а git-svn поддерживает.
Причем делает это так, что лучше бы не поддерживал - может кто нормальное бы что написал (только вряд ли)
Ты видел, во что оно превращает историю и логи на обоих концах цепочки?

Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 29-Май-20, 14:35

> это не github, а git-svn поддерживает.
> Причем делает это так, что лучше бы не поддерживал - может кто
> нормальное бы что написал (только вряд ли)
> Ты видел, во что оно превращает историю и логи на обоих концах
> цепочки?
Это руки из ... . Можно и аккуратно делать. И чинить
эпичекие концептуальные мегаумствования аторов subversion
(это каждый раз уникально; я думал, я всё уже видал, но
они там всё равно находят свежие назамутнённые мыслью приёмы).

Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от имя (ok), 29-Май-20, 01:15

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

37. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 10:40

> А васяны, пишущие в стол и никуда не собирающиеся в данный момент публиковать код, чертыхаясь,
> пытаются поднять svnserve, не осиливают
и, надеюсь, идут в макдак продавцами? Потому что что нагуанокодит ниасилятор поднять svnserve для самого себя - я боюсь даже представить.
Кстати, не хотел бы тебя огорчать, но для кода, который ты не собираешься публиковать, svnserve не нужен, это средство публикации. В отличие от гита - самодостаточное, обеспечивающее разделение прав доступа и fine-grained контроль.
> сплошные форумные треды о том, как же правильно пользоваться ветками
я так и не сумел научить наших разработчиков пользоваться ветками - вообще. Они в принципе не понимают, для чего нужны ветки.
Разные варианты одного и того же кода - раскладывают именно в новаяпапка(28), хотя они не то что никогда не бывают нужны на одном сервере, а опасны - возможностью случайно запустить не тот.
В гите, да.
Зато каждая отдельная задача (по полсотни в день!) оформляется в виде ненужной ветки и ненужного мержа в мастер.

Ответить | Правка | Наверх | Cообщить модератору

58. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от user (??), 29-Май-20, 13:50

Гит на сервере - ССЗБ. Неосиляторы rsync должны страдать.

Ответить | Правка | Наверх | Cообщить модератору

67. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 16:53

> Гит на сервере - ССЗБ. Неосиляторы rsync должны страдать.
а история ненужна, ага.



Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от user (??), 29-Май-20, 21:10

Разрабатывать прямо на проде? Мсье знает толк в адреналине и вазелине.

Ответить | Правка | Наверх | Cообщить модератору

20. "Выпуск системы управления версиями Apache Subversion 1.14.0" +3 +/–

Сообщение от Аноним (20), 29-Май-20, 04:24

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

38. "Выпуск системы управления версиями Apache Subversion 1.14.0" +2 +/–

Сообщение от Линус (?), 29-Май-20, 10:43

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

Ответить | Правка | Наверх | Cообщить модератору

42. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от Аноним (42), 29-Май-20, 12:13

Не шуми, мальчик. Сходи к взрослым дядям, например, сюда https://codereview.qt-project.org и посмотри, на каком суку они крутили твоё брэнчевание. И твои коммиты им тоже нафиг не нужны. Их надо в один преобразовывать. А потом ещё посмотри на тему линейности истории.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

45. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 12:29

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

Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от anonymous yet another (?), 29-Май-20, 14:19

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

Ответить | Правка | Наверх | Cообщить модератору

68. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 16:54

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

Ответить | Правка | Наверх | Cообщить модератору

72. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от anonymous yet another (?), 29-Май-20, 18:14

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

Ответить | Правка | Наверх | Cообщить модератору

54. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (54), 29-Май-20, 13:37

У нас на работе всего 3 программиста, но без веток вообще ничего сделать невозможно.

Ответить | Правка | К родителю #20 | Наверх | Cообщить модератору

53. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (54), 29-Май-20, 13:36

А если появится 2-3 автора? Сразу будет много веток

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

69. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от пох. (?), 29-Май-20, 17:06

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

Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 29-Май-20, 18:16

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

Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (54), 29-Май-20, 13:49

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

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

96. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от пох. (?), 01-Июн-20, 12:15

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

Ответить | Правка | Наверх | Cообщить модератору

94. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Роман (??), 01-Июн-20, 04:51

Так такие системы как mercurial или git (если не зарываться) гораздо проще того же svn. Вот в чем штука. hg или svn - если тебе нужен совсем простой случай, делашь hg init или git init и все готово, а svn настраивать надо серверы (сервисы).

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

97. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от пох. (?), 01-Июн-20, 12:23

> Так такие системы как mercurial или git (если не зарываться) гораздо проще
> того же svn.
покажите хоть один пример.
> если тебе нужен совсем простой случай, делашь hg init или git
> init и все готово, а svn настраивать надо серверы (сервисы).
А, понятно. Можете уже не показывать. Эксперт опеннета в треде, ховаемся.
svnadmin create  - разумеется чем-то супер-глобальным отличается от git init. Ага.
Неумением прочитать ман из десяти строк. Зато urban legends наслушаться.

Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 01-Июн-20, 22:31

> Так такие системы как mercurial или git (если не зарываться) гораздо проще
> того же svn. Вот в чем штука.
Subvsrsion проще. Т.е. тривиальнее. И git и mercurial
гораздо сильнее. Но hg попытался очеловечиться, tempora mutantur.
Vulgrais.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

9. "Выпуск системы управления версиями Apache Subversion 1.14.0" +6 +/–

Сообщение от Аноним (9), 28-Май-20, 23:51

Права доступа на директорию, получение любого файла без клонирования, обновление части проекта, блокировка файлов, externals

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

13. "Выпуск системы управления версиями Apache Subversion 1.14.0" +2 +/–

Сообщение от erthink (ok), 29-Май-20, 00:20

1. Гитом достаточно сложно пользоваться не понимая как он работает.
Поэтому основная причина = нежелание изучать новое и/или менять привычное.
Адепты svn нередко говорят что в git нет "externals" (на самом деле есть submodules и subtree), нет возможности обновить часть проекта (на самом деле checkout умеет).
2. Идеологическая разница. В svn есть центральный репозиторий/сервер, а git предлагает каждой копии быть самодостаточной. Поэтому в svn есть набор странных "фиче-костылей":
- права доступа на директорию, в git это абсурдно (но при желании можете локально выполнить chmod/chown).
- блокировка файлов "на сервере", в git вы хозяин локальной копии, а "на сервере" может жить множество версий без проблем.
- и т.д. образно говоря, в git нет кучи проблем, поэтому нет средств для их преодоления.
И этого следует принципиальное ограничение - svn плохо масштабируется по кол-ву активных участников.
3. Иногда добавляется еще одна причина - нежелание менять кучу скриптов.
4. Иногда примешивается "религия" - freebsd не может перейти на git...

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

16. "Выпуск системы управления версиями Apache Subversion 1.14.0" –7 +/–

Сообщение от Gemorroj (ok), 29-Май-20, 01:44

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

Ответить | Правка | Наверх | Cообщить модератору

19. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Ivan_83 (ok), 29-Май-20, 03:57

Фря таки туда упорно идёт.
Даже какой то коммитет вроде есть, и живые зеркала на гитхабе.

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

27. "Выпуск системы управления версиями Apache Subversion 1.14.0" –5 +/–

Сообщение от пох. (?), 29-Май-20, 09:51

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

Ответить | Правка | Наверх | Cообщить модератору

23. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от Ю.Т. (?), 29-Май-20, 07:58

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

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

25. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от Аноним (64), 29-Май-20, 08:46

> Сделал человек патч, а гит не знает
Странный у тебя гит, мой умеет.
git apply m.patch

Ответить | Правка | Наверх | Cообщить модератору

46. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от пох. (?), 29-Май-20, 12:41

> В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл".
вы похоже ниасилили гит даже на уровне терминологии?
pull может сделать только владелец репо. Ты мог бы сделать только push, но чужое репо тебе обычно недоступно на запись.
В наше время при нынешних размерах того ПО - очень неудобно работать с присылаемыми порезанными помельче патчами. Поэтому вполне разумно как раз делать pull-request (для неосиляторов: это _просьба_ владельцу сделать pull from me), в терминах гитшлака.
Альтернативный метод - технологии code review. Когда патчи не валят кучей в рассылку, а скармливают какой-нибудь вебморде. На предмет смотрения глазками. commit или push в зависимости от технологии - сделает вебморда, от имени и по поручению того у кого есть право одобрять изменения.
Что не мешает доверенным разработчикам - работать в обход, напрямую с репо.
> А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?..
и патч скорее всего - тоже г-но, он ведь такой еще много чего не знает. Как программировать уж точно не.
Так что если уж ниасилено даже нажать кнопочку clone me on github (гит для этого, кстати, знать незачем) - ну его нахрен тратить время разработчиков на такого альтернативно-одаренного.

Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

50. "Выпуск системы управления версиями Apache Subversion 1.14.0" –2 +/–

Сообщение от Ю.Т. (?), 29-Май-20, 13:26

>> В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл".
> вы похоже ниасилили гит даже на уровне терминологии?
> pull может сделать только владелец репо. Ты мог бы сделать только push,
А мужики-то и не знали. Я передал ЖАРГОН разработчиков, затычка ты в каждую бочку.
>> А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?..
> и патч скорее всего - тоже г-но, он ведь такой еще много
> чего не знает. Как программировать уж точно не.
Один ты всё на свете знаешь. "Одна только горесть -- никто не читает".

Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от пох. (?), 29-Май-20, 13:33

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

Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от Ю.Т. (?), 29-Май-20, 14:03

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

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск системы управления версиями Apache Subversion 1.14.0" –2 +/–

Сообщение от пох. (?), 29-Май-20, 10:14

> 1. Гитом достаточно сложно пользоваться - потому что он by design - дерьмо
поправил, не благодари.
Чтобы пользоваться электропилой - не нужно понимать как работают асинхронные электродвигатели - совсем. Нужно уметь ей пилить, не оттяпав себе ногу и не уронив дерево на голову. Поэтому она таки лучше бензиновой, где волей-неволей придется приобретать совершенно ненужные навыки моториста.
git устроен настолько уродливо и нефункционально (потому что его изначальная функция перпендикулярна человеческим vcs - сбор патчей из мусора рассылки) - что без знания его совершенно уродских и бесполезных потрохов им действительно сложно делать что-то сложное.
К счастью великому макак-разработчиков - им это и не нужно. Они умеют кодить, а не пользоваться vcs. git clone, git commit, git push. Что эти команды означают - знать незачем. Самые крутые знают про rebase. Впрочем, visual studio или phpstorm все это делает за них, от альтернативно-одаренного требуется только указать репо на гитшлаке.
svn придумана совершенно для иной цели - совместной работы с кодом, БЕЗ костыликов и подпорочек в виде веб-морды на пол-терабайта оперативы.
> Идеологическая разница. В svn есть центральный репозиторий/сервер, а git предлагает каждой
> копии быть самодостаточной
в разработке одного проекта нет и не может быть никаких "самодостаточных". Их по факту и нет.
"самодостаточность" твоей копии кончается на первом же push.
> права доступа на директорию, в git это абсурдно
действительно, с точки зрения макаки это абсурдно, какие еще права доступа, она и слов таких не знает.
Чмод какой-то нашла в гугле, хз что означает - говорят, самый крутой - 777, о, заработало.
Что кто-то может дать тебе возможность изменять _только_ доверенную тебе часть репо, и это не имеет ни малейшей связи с локальными атрибутами файлов на твоем макбучеке - тебе и в голову не придет, да?
И да, у svn нет никакой катастрофы хранить закрытые ключи и прочие нужные для запуска артефакты, которых так боятся случайно подгрести в комит гитляпцы - ты их даже и не увидишь.
> блокировка файлов "на сервере",
мы уже поняли что вы не умеете пользоваться svn
> в git вы хозяин локальной копии
которой можете подтереться, если, конечно, все еще собираетесь совместно работать.
По факту вы не хозяин в ней даже своим изменениям - "ваша история нахрен нам не вперлась, нас интересует только наша история" - rebase или format-patch. И да, не забудьте порезать поменьше, в экран не влазиет.
> И этого следует принципиальное ограничение - svn плохо масштабируется по кол-ву активных
> участников.
svn прекрасно поддерживает громадные проекты. Видимо, проблема не в том что плохо масштабируется, а в том что вы ничего кроме порежьте-помельче-пришлите не умеете?

Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

48. "Выпуск системы управления версиями Apache Subversion 1.14.0" –2 +/–

Сообщение от anonymous yet another (?), 29-Май-20, 13:19

Вопрос не корректный. subversion старше, а не лучше.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

51. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 13:27

два года разницы в двадцатилетнем проекте имеют очень больше значение. (нет)
subversion отпочковался от cvs в 2000м, bitkeeper который кое-как скосплеили в git - всучили линусу в 2002м.

Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от anonymous yet another (?), 29-Май-20, 14:51

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

Ответить | Правка | Наверх | Cообщить модератору

2. "Выпуск системы управления версиями Apache Subversion 1.14.0" –4 +/–

Сообщение от Аноним (4), 28-Май-20, 23:20

Только не говорите что устарело, может в вашем open source git победил, но в работе с мультимедией и тяжелыми исходниками в серьёзных корпорациях ваш гит будет сливать в чистую. Там где надо загрузить одну картинку размером 900 Кб придётся клонировать весь репозиторий терабайт на 5

Ответить | Правка | Наверх | Cообщить модератору

8. "Выпуск системы управления версиями Apache Subversion 1.14.0" +4 +/–

Сообщение от gitover (?), 28-Май-20, 23:47

git lfs? нет - не стлышал...

Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск системы управления версиями Apache Subversion 1.14.0" –2 +/–

Сообщение от Аноним (24), 28-Май-20, 23:57

Костыль

Ответить | Правка | Наверх | Cообщить модератору

17. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (17), 29-Май-20, 02:36

Да, ну и что?

Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от no country for old men (?), 29-Май-20, 00:07

Чукча не читатель, чукча -- писатель.
https://git-lfs.github.com/

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

14. "Выпуск системы управления версиями Apache Subversion 1.14.0" –2 +/–

Сообщение от хотел спросить (?), 29-Май-20, 00:34

можно вытащить с веб морды.. например в GitLab

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

18. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от DiabloPC (ok), 29-Май-20, 03:10

Ага, а потом непонятно каким образом затолкать её в локальное дерево. Ню-ню

Ответить | Правка | Наверх | Cообщить модератору

44. Скрыто модератором +/–

Сообщение от пох. (?), 29-Май-20, 12:21

git am/git patch жеж. Эти [censored] НА САМОМ деле вот так, через задницу все делают. И считают что так очень удобно - передние лапы освобождаются для дро4ки.

Ответить | Правка | Наверх | Cообщить модератору

76. Скрыто модератором +3 +/–

Сообщение от Anonymoustus (ok), 29-Май-20, 19:43

Для завивки шерсти на хвосте.
Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML? Напиши книжку советов. На опеннете всё равно потеряется, а так бы кто-то читал и просвещался.

Ответить | Правка | Наверх | Cообщить модератору

77. Скрыто модератором +1 +/–

Сообщение от Няшмяш (?), 29-Май-20, 19:51

> Для завивки шерсти на хвосте.
> Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML?
> Напиши книжку советов. На опеннете всё равно потеряется, а так бы
> кто-то читал и просвещался.
Во истину, все проблемы человечество от отсутствия сей великой книги!

Ответить | Правка | Наверх | Cообщить модератору

78. Скрыто модератором –1 +/–

Сообщение от Anonymoustus (ok), 29-Май-20, 20:18

>> Для завивки шерсти на хвосте.
>> Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML?
>> Напиши книжку советов. На опеннете всё равно потеряется, а так бы
>> кто-то читал и просвещался.
> Во истину, все проблемы человечество от отсутствия сей великой книги!
Кому как, а я регулярно читаю здесь в исполнении Поха разные неожиданные мысли и решения.

Ответить | Правка | Наверх | Cообщить модератору

81. Скрыто модератором +/–

Сообщение от пох. (?), 29-Май-20, 22:40

> Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML?
> Напиши книжку советов. На опеннете всё равно потеряется, а так бы
я из принципа написал бы на *roff, пусть-ка потрахаются прочитать. (интересно, порешали там проблемы с locale, за 20 лет, или снова самому патчить?)
Для заметок углем на манжетах вполне подходящий инструмент.
Но скорее я потрачу оставшиеся годы жизни на книжку по психологии приручения собак (человечьей, конечно). От храпящего на ковре пушистого "коврика", радости как-то больше, чем от ущербных технологий.

Ответить | Правка | К родителю #76 | Наверх | Cообщить модератору

21. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (20), 29-Май-20, 04:25

Дядь, почитай про sparse checkout.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

57. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (75), 29-Май-20, 13:50

> 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.
Не внушает доверия.

Ответить | Правка | Наверх | Cообщить модератору

26. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от КО (?), 29-Май-20, 09:21

>не прибегая к таким ухищрениям как сохранение патча через "svn diff" с последующим его восстановлением через "svn patch".
А я то просто еще одну папку с транком делал и в ней уже правил. Но, наверное, это слишком сложно. :)

Ответить | Правка | Наверх | Cообщить модератору

39. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 10:49

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

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск системы управления версиями Apache Subversion 1.14.0" –2 +/–

Сообщение от ALex_hha (ok), 29-Май-20, 09:53

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

Ответить | Правка | Наверх | Cообщить модератору

35. "Выпуск системы управления версиями Apache Subversion 1.14.0" –1 +/–

Сообщение от пох. (?), 29-Май-20, 10:27

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

Ответить | Правка | Наверх | Cообщить модератору

30. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от ALex_hha (ok), 29-Май-20, 10:07

> Дядь, почитай про 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.

Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Аноним (64), 29-Май-20, 10:21

Акелла то промахнулся.

Ответить | Правка | Наверх | Cообщить модератору

87. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от Аноним (20), 30-Май-20, 11:18

Это вариант раз
git clone --no-checkout
git sparse-checkout init --cone
git sparse-checkout set <your dir>
Это вариант два
git clone --filter=blob:none --no-checkout
Чё как, хорошо владеете гитом? Учиться никогда не поздно, да?

Ответить | Правка | К родителю #30 | Наверх | Cообщить модератору

98. "Выпуск системы управления версиями Apache Subversion 1.14.0" +1 +/–

Сообщение от пох. (?), 01-Июн-20, 12:30

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

> git clone --filter=blob:none --no-checkout
мне нужен был blob - но только один, а не стопиццот. И не нужна его история изменений, в пятидесяти копиях. Его все равно нельзя сравнить diff'ом.
> Чё как, хорошо владеете гитом? Учиться никогда не поздно, да?
учиться выбирать инструмент, не требующий зазубривания миллиона идиотских ключиков, и решающи твои задачи, а не перпендикулярные твоим задачи божка-с-пальцовкой - вам уже поздно.

Ответить | Правка | Наверх | Cообщить модератору

89. "Выпуск системы управления версиями Apache Subversion 1.14.0" +/–

Сообщение от Ilya Indigo (ok), 31-Май-20, 05:36

Я так и знал, что зайдя в ветку svn буду читать про git! :-)
P.S. Ради этого и зашёл! :-)

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
Сообщение от Аноним (1), 28-Май-20, 23:16
А где-нибудь можно почитать о том, почему пользователи Subversion выбирают именно его? Чем таким оно лучше того же Git'а?
Ответить \| Правка \| Наверх \| Cообщить модератору


	4. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–4 +/–
	Сообщение от Аноним (4), 28-Май-20, 23:27
	Попробуйте хранить в гите .blend файлы, он моментально раздуется. А svn будет хорошо, конечно на сервере будет раздуваться, но не на каждом клиенте. То же фонд блендера свои мультфильмы в svn хостили
	Ответить \| Правка \| Наверх \| Cообщить модератору


	5. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–1 +/–
	Сообщение от Аноним (1), 28-Май-20, 23:32
	В гите совсем нет возможности подрезать хранимый объём старых комитов? Я честно не знаю. Я дальше пары команд из мануала не практиковал его ещё.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–1 +/–
	Сообщение от пох. (?), 29-Май-20, 13:18
	причем тут "старые комиты"? blend файлы вряд ли часто обновляют - хватит ровно одной копии. Просто потому что она огромная. В случае svn ты можешь просто не чекаутить ненужные тебе гигасы филеза. В случае git ты их тоже можешь не чекаутить - но легче тебе от этого не станет, поскольку они у тебя будут в .git в твоей локальной копии. Существуют ли в природе dvcs, умеющие работать только с частью дерева - учоные спорят. Но microsoft уже бежит к вам на помочь, со своей lfs.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от user (??), 29-Май-20, 13:46
	Ещё одна причина не использовать монорепо. Кто сам не редактирует это блобы, тот должен их обновлять через пакетный менеджер или rsync.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	7. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+2 +/–
	Сообщение от erthink (ok), 28-Май-20, 23:46
	В git всё давно есть, только больше.
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	22. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+3 +/–
	Сообщение от Аноним (22), 29-Май-20, 06:44
	>Попробуйте хранить в гите .blend файлы Двойное нeнужнo. Прекрасно храним .ma, .mb, .hip фанеры и файлы в perforce и он не раздувается. 👍
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	24. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–3 +/–
	Сообщение от Аноним (24), 29-Май-20, 08:05
	Он же проприетарный
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+1 +/–
	Сообщение от Аноним (29), 29-Май-20, 10:00
	А что плохого?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	49. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–1 +/–
	Сообщение от пох. (?), 29-Май-20, 13:22
	манагер денег не дает - "вот же, тут 6ешплатно. взять, взять!" Лучше б рассказал кто в курсе - что, почем, где там грабли раскиданы. А то куды бежать с hg - я вот не знаю. svn не очень подходит для параллельной работы, увы.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	61. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от anonymous yet another (?), 29-Май-20, 14:29
	> А то куды бежать с hg - я вот не знаю. svn > не очень подходит для параллельной работы, увы. Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются). Если мартышкам в руки давать --- купите что-то вроде smartgit --- там кнопки есть, можно давить. И обложите ограничениями прав на серверной стороне (под gitlab или bitbucket, ...), чтобы не порушили чего по природной сообразительности.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	66. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–2 +/–
	Сообщение от пох. (?), 29-Май-20, 16:50
	>> А то куды бежать с hg - я вот не знаю. svn >> не очень подходит для параллельной работы, увы. > Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются). мне для себя, не для мартышек. Есть вещи которые делаются в нескольких параллельных ветках. Ветки эпизодически (кусками) мержатся, причем - в любую сторону. svn такого не любит, в нем мерж допустим только из trunk вниз. git чудовищно неудобен - во всем (hg местами, к этому можно было привыкнуть). Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться? Как минимум, попытка сохранить фиксацию версий говорит о том что люди делали это для себя. > Если мартышкам в руки давать --- купите что-то вроде smartgit --- там > кнопки есть, можно давить. И обложите ограничениями прав на серверной и кто мержить за них будет - я? Нафиг-нафиг-нафиг. за них гуи думают. Я поразился, поставив себе msvc, насколько вообще можно ничего не понимать в том как оно работает.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	70. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+1 +/–
	Сообщение от anonymous yet another (?), 29-Май-20, 17:56
	>[оверквотинг удален] >> Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются). > мне для себя, не для мартышек. Есть вещи которые делаются в нескольких > параллельных ветках. Ветки эпизодически (кусками) мержатся, причем - в любую сторону. > svn такого не любит, в нем мерж допустим только из trunk > вниз. > git чудовищно неудобен - во всем (hg местами, к этому можно было > привыкнуть). > Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться? > Как минимум, попытка сохранить фиксацию версий говорит о том что люди > делали это для себя. Видите ли, если для себя, то сильнее git'а ничего нет. Надо идти и разбираться. Там почти всё по делу. Идеи, лежащие в основе --- гениальны (т.е. они пригодились и позволили делать вещи, о которых изначально и не предполагали, не трогая концепцию). P4 для разработки --- сплошное мучение. Его концептуально, похоже, делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ специфичными хотелками. Всякая прочая деятельность на нём --- хождение по мукам. Если, конечно, вам не нужен большой файлообменник с версионированием файлов (правда сильно большие файлы нельзя, и зараз пихать много файлов тоже нельзя). Т.е. пользоваться можно, но за очень большие деньги. Пользователю. За вредность. Конторка, которая его делает --- чует конец и переобувается в консультантов и создателей цветастых окошек поверх git'а.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+1 +/–
	Сообщение от Няшмяш (?), 29-Май-20, 18:11
	>[оверквотинг удален] > P4 для разработки --- сплошное мучение. Его концептуально, похоже, > делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ > специфичными хотелками. Всякая прочая деятельность на нём --- > хождение по мукам. Если, конечно, вам не нужен большой файлообменник > с версионированием файлов (правда сильно большие файлы нельзя, > и зараз пихать много файлов тоже нельзя). > Т.е. пользоваться можно, но за очень большие деньги. > Пользователю. За вредность. > Конторка, которая его делает --- чует конец и переобувается в консультантов > и создателей цветастых окошек поверх git'а. Очень хорошо сказано.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	90. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+1 +/–
	Сообщение от Аноним (-), 31-Май-20, 23:54
	> Очень хорошо сказано. Удваиваю. Гит сделан живым человеком для себя и людей. А вон то - корпорасами, на продажу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	74. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–1 +/–
	Сообщение от пох. (?), 29-Май-20, 18:31
	>> Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться? >> Как минимум, попытка сохранить фиксацию версий говорит о том что люди >> делали это для себя. > Видите ли, если для себя, то сильнее git'а ничего нет. > Надо идти и разбираться. Там почти всё по делу. Идеи, лежащие в но мне не нужно уметь извлекать патчи из рассылки. И отправлять их обратно, что характерно - тоже, я комичу в транк, да. (мне нужна _моя_ история) А обычная моя работа в нем чудовищно неудобна. Я не хочу думать о кишках двигателя - я хочу просто пользоваться удобным инструментом - и мне совершенно все равно какая там магия под капотом. Например, без персистентных человекочитаемых версий - чудовищно неудобно. Это как раз и говорит о том, что изобретателям гитоподелки история вообще нах не вперлась, возвращаться к ней они не планируют. > P4 для разработки --- сплошное мучение. Его концептуально, похоже, можно все же - детали, а не мнения? > делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ > специфичными хотелками. Всякая прочая деятельность на нём --- вдруг мои хотелки - совпадут. > хождение по мукам. Если, конечно, вам не нужен большой файлообменник > с версионированием файлов (правда сильно большие файлы нельзя, НУЖЕН! > и зараз пихать много файлов тоже нельзя). сколько в граммах? "Большие" и "много" у всех свои. > Конторка, которая его делает --- чует конец и переобувается в консультантов > и создателей цветастых окошек поверх git'а. останется только один, причем, как обычно, наихудший. Но я не собираюсь жить вечно.
	Ответить \| Правка \| К родителю #70 \| Наверх \| Cообщить модератору


	75. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–1 +/–
	Сообщение от Аноним (75), 29-Май-20, 19:34
	> Например, без персистентных человекочитаемых версий - чудовищно неудобно Имена у branch и tag — человекочитаемы, а персистентность можно обеспечить административными способами
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от пох. (?), 29-Май-20, 22:14
	Меня не интересуют ваши любимые привычные костыли и обязательность ношения намордника под угрозой штрафа, а так же как через него вы умудряетесь жрать г-но с лопаты. Меня интересует для себя, любимого, сделать - хорошо и удобно. Можно за деньги. И никогда-никогда не видеть убе...ских номеров комитов. Это изобрести мог только один человек - тот, которому нахрен не нужна история, и, соответственно, vcs вообще.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	91. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от Аноним (91), 01-Июн-20, 00:00
	> Меня интересует для себя, любимого, сделать - хорошо и удобно. Можно за деньги. Ну, затарься качественным бухлом и пистолетом. Можешь даже в кредит, это уже не важно. Что еще разумного посоветовать можно на глобусе где Торвальдс всех как обычно порвал? :) > И никогда-никогда не видеть убе...ских номеров комитов. Это изобрести мог > только один человек - тот, которому нахрен не нужна история, и, соответственно, vcs вообще. По ним на самом деле довольно удобно посылать тела совершенно не в теме в конкретные комиты.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	82. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от anonymous yet another (?), 30-Май-20, 00:14
	> но мне не нужно уметь извлекать патчи из рассылки. И отправлять их > обратно, что характерно - тоже, я комичу в транк, да. (мне > нужна _моя_ история) Это что, легенда какая-то или психологическая травма? Есть ситуации когда так удобно. Иногда очень удобно. Но это далеко не единственный workflow. > А обычная моя работа в нем чудовищно неудобна. Я не хочу думать > о кишках двигателя - я хочу просто пользоваться удобным инструментом - > и мне совершенно все равно какая там магия под капотом. Например, > без персистентных человекочитаемых версий - чудовищно неудобно. Это как раз и > говорит о том, что изобретателям гитоподелки история вообще нах не вперлась, > возвращаться к ней они не планируют. Persistent human-readable --- зто про r100500? Так ни в одном из вменяемых DVCS'ов так не делают по вполне понятным причинам. Да и централизованных системах цена этого решения сильно высока. А смысла нет. (мало-мальски нетривиальное версионирование --- это слабоупорядоченные множества, и смысл этой человеко-читаемости идёт мимо). >> P4 для разработки --- сплошное мучение. Его концептуально, похоже, > можно все же - детали, а не мнения? Да берите и пробуйте. По мне --- очень дорогое г. (акцент на "г.", а не на "дорогое"). >> делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ >> специфичными хотелками. Всякая прочая деятельность на нём --- > вдруг мои хотелки - совпадут. Вам виднее. На вкус и цвет, как известно, все фломастеры разные. >> хождение по мукам. Если, конечно, вам не нужен большой файлообменник >> с версионированием файлов (правда сильно большие файлы нельзя, > НУЖЕН! Так флаг вам в руки, барабан на шею и ветер в спину. В одном кооперативе (он там и как VCS заодно используется ;)) по факту через P4 презентациями и аналогами докладных записок (а заодно фотографиями, мувиками, ...) обмениваются. Каждые два-три месяца на регламент ложился --- полки, наверное, доставляли. Ну, и ценность истории при такой организации работы --- полный ноль. Я ещё одну контору на нём знаю, но там его после меня принесли. >> и зараз пихать много файлов тоже нельзя). > сколько в граммах? "Большие" и "много" у всех свои. Мне хватило, чтобы я напоролся на это при _нормальной_ работе без извращений. Сейчас у меня этого чуда мысли образца 1980 года под рукой нет и я этим фактом вполне удовлетворён.
	Ответить \| Правка \| К родителю #74 \| Наверх \| Cообщить модератору


	83. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от anonymous yet another (?), 30-Май-20, 09:45
	Немножко времени есть, подкину информации по P4. Работать с источниками в ней неудобно. Все характерные задачи при работе с источниками в ней решаются через ... . Её, похоже, изначально делали как "хранилище конфигураций". Однако затолкать что-то существенное (свежесобранная операционка, в скромном варианте) не получается --- ограничение по количеству файлов (файлов!) в транзакции. Снапшот источников ядра за одну транзакцию тоже, кстати, не проходит. Сравнить две "конфигурации" --- пляски с бубнами. Получить в двух разных местах две идентичные конфигурации --- тоже тот ещё квест. Решаемый, конечно. Но на хрена всё время бодаться с проблемами такого рода? Однако гвоздями прибит определённый workflow разработки, считаемый авторами единственно верным и незыблемым. [моё личное мнение].
	Ответить \| Правка \| Наверх \| Cообщить модератору


	84. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от пох. (?), 30-Май-20, 10:30
	> Немножко времени есть, подкину информации по P4. > Работать с источниками в ней неудобно. Все характерные > задачи при работе с источниками в ней решаются через ... . ну а еще подробнее - какие задачи (мож у меня и нет таких?) и в чем неудобство. > Её, похоже, изначально делали как "хранилище конфигураций". хм, да, не мой случай (в смысле, вряд ли вышло лучше чем у svn, а той мне еще на двадцать лет хватит, благо не на пихоне писано) > Однако затолкать что-то существенное (свежесобранная операционка, > в скромном варианте) не получается --- ограничение по количеству > файлов (файлов!) в транзакции. Снапшот источников ядра за одну > транзакцию тоже, кстати, не проходит. ну то есть несколько тысяч - вполне пройдут? Идея внезапно-появившегося в проекте ядра линуха одним куском меня не особо и так впечатляет. Линус вас, кстати, тоже осудит - "порежьте чтоб в экран влазило и заверните каждую отдельным комитом" (представьте что он вам таки разрешил вмержить в ядро zfs?). > Сравнить две "конфигурации" --- пляски с бубнами. Получить > в двух разных местах две идентичные конфигурации --- тоже оно не умеет сравнивать r100101 и 100102 ? Или чекаутить 100103? Или вы что-то другое подразумевали? > Однако гвоздями прибит определённый workflow разработки, считаемый ну так описать-то его можете? Меня вот гитовый workflow не устраивает - да, он не прибит гвоздями, но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни, не в сферическом вакууме. P.S. персистентные человекочитаемые (и желательно монотонно-растущие) версии нужны хотя бы для того, чтобы я - не видя вашего номерка перед глазами, он уже уехал за край страницы - все еще помнил что он 100500. И насторожился бы, увидев в рабочей среде вместо него 100502. А гитовую бесполезность невозможно ни запомнить, ни сравнить без diff. e90e3cf e093ecf - это одна версия или разные? Попатчте ему лог уже кто-нибудь, чтобы он показывал вместо них HEAD, HEAD~ HEAD~22 - все равно никто ни с какими другими не работает. (отдельно убить того кто придумал эти дурацкие большие буквы) Будет вполне отражать тот вокфлоу, на который он заточен - "версия должна быть последняя или ненужно". Да, hg это попыталась решить, там никто не работает с хэшами, но эти версии локальны, что бесит - сегодня она у тебя 40, завтра мы перезалили репо - и та же версия стала 62. Понятно, почему так, но крайне интересно было бы глянуть, как попытались сделать по-человечески.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	86. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от anonymous yet another (?), 30-Май-20, 11:03
	Я коротко. Время для трёпа закончилось. >> Немножко времени есть, подкину информации по P4. >> Работать с источниками в ней неудобно. Все характерные >> задачи при работе с источниками в ней решаются через ... . > ну а еще подробнее - какие задачи (мож у меня и нет > таких?) и в чем неудобство. Я реферат писать не буду. С источниками в P4 _мне_ работать было не то что неудобно, а невозможно. А я с ними работать могу и умею. Решал внешними средствами. > ну то есть несколько тысяч - вполне пройдут? Идея внезапно-появившегося в проекте > ядра линуха одним куском меня не особо и так впечатляет. Линус > вас, кстати, тоже осудит - "порежьте чтоб в экран влазило и > заверните каждую отдельным комитом" (представьте что он вам таки разрешил вмержить > в ядро zfs?). Во первых, задачи разные бывают. Во-вторых --- P4 неудовлетворительно отработало почти по всем полезным workflow/use-cases. Т.е. вынужденно жить я с ней мог, но это перманентная борьба на ровном месте. Оно мне надо? >> Сравнить две "конфигурации" --- пляски с бубнами. Получить >> в двух разных местах две идентичные конфигурации --- тоже > оно не умеет сравнивать r100101 и 100102 ? Или чекаутить 100103? Или > вы что-то другое подразумевали? Там модель другая. Поэтому употребляемые термины не подходят. По смыслу --- задачу решить можно, но сравнительно трудоёмко и достаточно глубоко предмет знать надо. >> Однако гвоздями прибит определённый workflow разработки, считаемый > ну так описать-то его можете? Ещё раз: хотите, берите и пробуйте. По мне --- не существует единственно верного workflow на все (даже только мои) случаи. > Меня вот гитовый workflow не устраивает - да, он не прибит гвоздями, > но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни, > не в сферическом вакууме. Он не навязывает никаго workflow. Как построите работу, так и будет. Git мне в этом построении не мешает. >[оверквотинг удален] > ему лог уже кто-нибудь, чтобы он показывал вместо них HEAD, HEAD~ > HEAD~22 - все равно никто ни с какими другими не работает. > (отдельно убить того кто придумал эти дурацкие большие буквы) Будет вполне > отражать тот вокфлоу, на который он заточен - "версия должна быть > последняя или ненужно". > Да, hg это попыталась решить, там никто не работает с хэшами, но > эти версии локальны, что бесит - сегодня она у тебя 40, > завтра мы перезалили репо - и та же версия стала 62. > Понятно, почему так, но крайне интересно было бы глянуть, как > попытались сделать по-человечески. Без комментариев. Математическими основами не владеете.
	Ответить \| Правка \| К родителю #84 \| Наверх \| Cообщить модератору


	92. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от Аноним (91), 01-Июн-20, 00:06
	> но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни, > не в сферическом вакууме. Если ты о профакивании изменений в дереве при git pull - то это сделать для начала гит как раз и не даст, зарубив pull пока как минимум не заныкаешь куда-нибудь свой креатив. > Да, hg это попыталась решить, там никто не работает с хэшами, но эти версии локальны, что бесит Ну вот на хэш можно ссылаться глобально - и это всегда корректно. Адресат посыла всегда пойдет в правильное место. А что такое r100102 - ему может говорить столько же сколько и sha1.
	Ответить \| Правка \| К родителю #84 \| Наверх \| Cообщить модератору


	95. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от пох. (?), 01-Июн-20, 12:12
	> Если ты о профакивании изменений в дереве при git pull - то это сделать для начала гит как раз лолшта? Эксперты опеннета... Заметно что гит они пользуют исключительно по методичке со стека, копи-пасть. git clone vi ... git add && commit git pull...ой! и хорошо если сразу заметил. А если через три итерации - как оно чаще всего и бывает? > даст, зарубив pull пока как минимум не заныкаешь куда-нибудь свой креатив. а это как раз _отдельная_ ненужная глупость афтырей. svn -даст, hg - даст. git заставляет заниматься ненужно.
	Ответить \| Правка \| К родителю #92 \| Наверх \| Cообщить модератору


	64. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–1 +/–
	Сообщение от Аноним (64), 29-Май-20, 16:13
	hg был хорош, особенно в плане мержей и конфликтов, жаль git победил.
	Ответить \| Правка \| К родителю #49 \| Наверх \| Cообщить модератору


	65. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от пох. (?), 29-Май-20, 16:36
	> hg был хорош, особенно в плане мержей и конфликтов, жаль git победил. там обратная беда была - иногда таки и впрямь ненужно тащить свою внутреннюю кухню в чужой проект, а надо выдать пачку патчей поверх состояния - чужого, которое тебе нафиг не нужно. Отражающих структуру кода (не "порежьте помельче", а структуру ;-) а не историю твоей возни с ним - потому что дальше возиться будет кто-то другой. Это сделали через mq, и так что лучше б не делали - опять нужны ненужные знания о внутреннем устройстве инструмента. hg был хорош пока у тебя вся разработка общая, либо ты пилишь в одно жало параллельно несколько веток (в svn мержи такие что после второй ветки проще удавиться чем за ними уследить, и именно эту проблему hg решил раз навсегда, у него любой комит это мерж) К сожалению, по всей видимости, svn его успеет пережить. Именно за счет авторизации, разделения доступов и возможности не таскать за собой потроха репо там, где нужен только чекаут или вообще одноразовый export. А "распределенность" сама по себе оказалась не так полезна, как о ней рассказывали.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от пох. (?), 30-Май-20, 10:32
	> Это сделали через mq, и так что лучше б не делали - > опять нужны ненужные знания о внутреннем устройстве инструмента. да, а histedit у нас бесполезное ненужно, потому что работает только в репозитории без веток - где они вообще такой нашли?!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	93. "Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
	Сообщение от Роман (??), 01-Июн-20, 04:49
	Используйте меркуриал, он хранит дифы
	Ответить \| Правка \| К родителю #4 \| Наверх \| Cообщить модератору


	6. "Выпуск системы управления версиями Apache Subversion 1.14.0"	–1 +/–
	Сообщение от Аноним (6), 28-Май-20, 23:34
	А нужен ли гит, если его используемые фичи перекрываются svn с запасом? Смотришь на том же гитхабе - один проект, один автор и одна ветка. Смахивание на попытку вскопать огород вскрышным экскаватором.
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору