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

Выпуск системы управления версиями Apache Subversion 1.14.0, opennews (??), 28-Май-20, (0) [смотреть все] А где-нибудь можно почитать о том, почему пользователи 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) 1,2,26,28,30,89

Сообщения

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

	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ообщить модератору

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

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