https://www.opennet.dev/openforum/vsluhforumID3/100048.html Компания Google объявила (https://groups.google.com/forum/#!topic/golang-dev/sckirqOWepg) о переводе инфраструктуры разработки языка программирования Go на систему управления исходными текстами Git и платформу совместной разработки GitHub. На днях проекту Go исполнилось пять лет, во время основания проекта была выбрана система Subversion, после чего последовал переход на Perforce, а затем и на Mercurial, из-за необходимости интеграции с существующей системой рецензирования кода. За это время мир изменился и Git занял прочную позицию лидера. Большинство участников сообщества Go используют Git и GitHub для своего кода. Проблемы с системой рецензирования остались в прошлом, поэтому теперь ничто не сдерживает миграцию проекта на Git.<br><br><br> После миграции на Git в качестве системы рецензирования будет использована система Gerrit (http://code.google.com/p/gerrit/), которая уже применяется для кода платформы Android. Миграция на Git начнётся вскоре после релиза 1.4, намеченного на начало декабря. Выпуск 1.5 уже буд https://www.opennet.dev/openforum/vsluhforumID3/100048.html#89 Sun, 16 Nov 2014 12:07:52 GMT &gt; Судя по актуальным тенденциям Git победил и преступил к перетягиванию всех на <br>&gt; себя своей массой (чисто популярностью: "у соседа git - у меня <br>&gt; тоже будет git"), теперь контроль версий = git.<br><br>разработчики FreeBSD смотрят на тебя как на говорящего микроба.<br> https://www.opennet.dev/openforum/vsluhforumID3/100048.html#88 Sun, 16 Nov 2014 12:05:41 GMT &gt;&gt; "А ПОЧЕМУ НЕ НА code.google.com ???" <br>&gt; Потому что по сравнению с гитхабом он.. мм... как бы это помягче <br>&gt; то, без мата? :)<br><br>ничем особо не отличающийся, кроме количества хипстеров?<br> https://www.opennet.dev/openforum/vsluhforumID3/100048.html#87 Sun, 16 Nov 2014 04:06:44 GMT &gt; Многим нравится IPv6, но из-за монополии IPv4 переход очень сложен.<br><br>1) У IPv6 есть навалом своих проблем. В том числе новых и свежих.<br>2) Если кто хочет IPv6, его можно получить. Может кривовато, но все-таки.<br>3) А настоящий next gen на самом деле должен выглядеть в первом приближении как-то так: https://en.wikipedia.org/wiki/Cjdns - заметьте, вменяемые люди не уповают ни на кого и делают из того что есть то что хочется. Наиболее практичный подход.<br> https://www.opennet.dev/openforum/vsluhforumID3/100048.html#86 Sun, 16 Nov 2014 04:01:52 GMT &gt; Плохо.<br><br>Не хуже чем необходимость использования IPv4 и HTTP для отправки сообщений на опеннет.<br><br> https://www.opennet.dev/openforum/vsluhforumID3/100048.html#85 Sun, 16 Nov 2014 03:45:32 GMT Знакомьтесь, это - изен. Он сегодня делает то же что и обычно - тормозит и затупляет.<br> https://www.opennet.dev/openforum/vsluhforumID3/100048.html#84 Sun, 16 Nov 2014 03:39:55 GMT &gt; Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce). <br><br>На самом деле очень зависит от людей и того над чем они работают. Поэтому каких-то абсолютно универсальных рецептов не бывает. У нормальных проектов есть некий запас гибкости для того чтобы провзаимодействовать с неким ценным кадром, желательно как можно меньше напрягая остальных. Собственно, хороший руководитель проекта кроме всего прочего может такие вещи утрясти до формата когда процесс идет, явных продолбов не случается и команда не исходит на мат от кривых инструментов и подходов.<br><br>&gt; Тут хорошая тема поднимается - как делать VCS для нетекстовых данных.<br><br>Ну да, это довольно отдельная тема. И я не уверен что отложенное совместное редактирование например картинок вообще эффективно. Вот толпой отредактировать картинку в реалтайм - может и прокатит, но такие процессы имеют свойство скатываться в бардак который очень бесит участников, если индивиды не идеально скоординированны. Проверено на сервисе совместного р https://www.opennet.dev/openforum/vsluhforumID3/100048.html#83 Sun, 16 Nov 2014 03:19:22 GMT &gt; Merge должен делать человек, понимающий в предмете в первую очередь.<br><br>Совершенно не обязательно, ибо понимание предмета != умение делать технически сложные и достаточно ответственные операции. Технические умения ГСМщиков обычно "не очень" и с компьютерами они "на Вы". Получать мерж после таких индивидов может быть достаточно чреватой идеей. Хоть я и допускаю мысль что часть из них можно научить этому, это уже достаточно индивидуально. А в случае какого-нибудь дизайнера нужда выполнять мерж вообще означает какой-то факап в рабочем процессе.<br><br>&gt; Если в мастере произошли изменения в тех же файлах, что ты правил,<br><br>...то в случае таких ГСМщиков это обычно означает продолб в рабочем процессе.<br><br>&gt; Если несколько переводчиков работают над одним текстом, всунутым в VCS,<br>&gt; им придётся делать merge. И при этом желательно ничего не ломать.<br><br>Если честно, на практике я ни разу не встречал ситуации чтобы несколько переводчиков лопатили 1 файл. Во первых, нормальный переводчик стоит денег и поэтому даже в очень больш https://www.opennet.dev/openforum/vsluhforumID3/100048.html#82 Sat, 15 Nov 2014 18:28:53 GMT &gt; Использование гит != невежество. И да, вас не смущает что вы на <br>&gt; опеннет должны идти по именно TCP/IP? А то может вам IPX/SPX <br>&gt; симпатичнее? И что постить надо по именно протоколу HTTP? А то <br>&gt; мало ли, вдруг вам gopher больше нравится?<br><br>Многим нравится IPv6, но из-за монополии IPv4 переход очень сложен.<br> https://www.opennet.dev/openforum/vsluhforumID3/100048.html#81 Sat, 15 Nov 2014 18:28:05 GMT &gt; Разве это плохо?<br><br>Плохо.<br>