forum.opennet.ru

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

Оглавление

Язык программирования Go переходит с Mercurial на Git и GitHub, opennews (??), 14-Ноя-14, (0) [смотреть все]

Вот читал несколько статей о преимуществах других систем над GIT, но кроме каких, Аноним (-), 09:57 , 14-Ноя-14, (1) +7 //

Поступки, порой, лишены смысла - Но всё-таки Если, к примеру, провести аналог, anthonio (ok), 10:35 , 14-Ноя-14, (7) +2
Никто не знает гит В том смысле, что он можный, но понимать - понимают его ой, Аноним (-), 10:36 , 14-Ноя-14, (8) –4 //

мощный, Аноним (-), 10:38 , 14-Ноя-14, (9)
Так по минимуму его освоить не сложнее чем любую иную VCS, а продвинутости типа , Аноним (-), 10:38 , 14-Ноя-14, (10) +1 //

Ну так мерж, это как бе важная часть даже для базового использования, не Или чт, Аноним (-), 10:39 , 14-Ноя-14, (11)

Реально базовое пользование, на мой взгляд, вот такое pull checkout add com, Какаянахренразница (ok), 11:40 , 14-Ноя-14, (15) +4
Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требует, Аноним (-), 11:51 , 14-Ноя-14, (17)

Т е Git - переусложнён, раз для базовой функциональности - слияния, требуется , Vkni (ok), 16:24 , 14-Ноя-14, (45)

Я вот видел как-то раз закоммиченные неразрешённые конфликты , vn971 (ok), 22:54 , 14-Ноя-14, (54)
Это для слияния в subversion нужен еще какой специалист Хотя система-то попроще, Ytch (ok), 01:16 , 15-Ноя-14, (57) +2
Врядли вы хотите чтобы это вам делали дизайнеры и прочие ГСМщики, которые пару д, Аноним (-), 05:17 , 15-Ноя-14, (63) +1

Merge - это часто требуемая на местах функциональность, которую невозможно пере, Vkni (ok), 06:24 , 15-Ноя-14, (70) –1

Я по прежнему считаю что вы врядли захотите получить результат мержа после дизай, Аноним (-), 14:32 , 15-Ноя-14, (73)

А зачем они вообще должны туда лезть-то Merge должен делать человек, понимающий, Vkni (ok), 20:59 , 15-Ноя-14, (79)

Совершенно не обязательно, ибо понимание предмета умение делать технически сл, Аноним (-), 06:19 , 16-Ноя-14, (83)

Наверно не мерж, а разруливание конфликтов - так это везде повод для паники , umbr (ok), 00:46 , 15-Ноя-14, (56)

А я не знаю почему Vkni возомнил что это в других VCS как-то проще , Аноним (-), 05:18 , 15-Ноя-14, (64) +1
Я неправильно написал меня возмутил подход позвать специалиста и исключение m, Vkni (ok), 06:26 , 15-Ноя-14, (71)

А мне кажется наивным уповать на то что дизайнер или техпис может сделать мерж п, Аноним (-), 14:43 , 15-Ноя-14, (74)

Это желательно Тем более, что это стандартный алгоритм параллелизации работы M, Vkni (ok), 21:24 , 15-Ноя-14, (80)

На самом деле очень зависит от людей и того над чем они работают Поэтому каких-, Аноним (-), 06:39 , 16-Ноя-14, (84)

Как по мне, мердж в гите прост, и уж явно удобнее чем в свн, к примеру А для те, imprtat (ok), 01:56 , 15-Ноя-14, (59) +1

таким разруливание конфликтов лучше вообще не доверять, для начала Человек л, Аноним (-), 05:19 , 15-Ноя-14, (65)

Наверно, в Git и SVN CVS операция merge 8212 ответственная работа В hg про me, iZEN (ok), 16:41 , 15-Ноя-14, (78) –2

Знакомьтесь, это - изен Он сегодня делает то же что и обычно - тормозит и затуп, Аноним (-), 06:45 , 16-Ноя-14, (85) +1

Предпочитать какое-либо решение только потому, что оно является самым популярным, Tav (ok), 11:03 , 14-Ноя-14, (13) +6 //

Со всем согласен кроме На мой взгляд, github во многом упрощает жизнь И по-хоро, Xaionaro (ok), 12:17 , 14-Ноя-14, (18) //

всеобщее клеймение штрихкодами на лбу во многом упрощает жизнь, но почему-то нем, Аноним (-), 12:24 , 14-Ноя-14, (21)

Во-первых, и что с того Как это связано с тем, что написал я Не нравится 821, Xaionaro (ok), 12:27 , 14-Ноя-14, (22) +1

Логично Тогда сделай себе штрихкод на лбу Это явно удобнее, чем паспорт , anonymous (??), 16:14 , 14-Ноя-14, (42) –1

Не эстетично И повторюсь Мне не нравится штрих-код на лбу Не буду использовать, Xaionaro (ok), 16:53 , 14-Ноя-14, (46) –1

Я, лично, хожу с паспортом по СПб крайне редко Чаще всего, никакого удостоверен, Vkni (ok), 21:30 , 14-Ноя-14, (52) –1

Полисмены just in case будут недовольны и могут при случае задержать до выяснени, Аноним (-), 05:21 , 15-Ноя-14, (66)

Практика показала, что для меня этот случай крайне маловероятен Машина собьёт с, Vkni (ok), 06:33 , 15-Ноя-14, (72)

Ну и ок На самом деле я тоже далеко не всегда беру с собой паспорт по тем же, Аноним (-), 14:49 , 15-Ноя-14, (75)

Сообщество разработчиков Go выбрало наиболее удобное для себя решение Это выбор, Аноноим (?), 14:39 , 14-Ноя-14, (35) //

Ненавязанный, свободный выбор может приводить к монополии Вот пример есть две , Аноним (-), 17:55 , 14-Ноя-14, (49) +1

Вот поэтому а так же и потому что можно держать бесплатно закрытые репы я и ис, jOKer (ok), 15:04 , 14-Ноя-14, (37) //

Конечно же , Аноним (-), 16:55 , 14-Ноя-14, (47)

смысл использовать mercurial встроенный предохранитель от переписывания опубл, develop7 (ok), 11:41 , 14-Ноя-14, (16) //

Что это такое Запрет на аналогиню 171 git push --force 187 и всякие 171 g, Xaionaro (ok), 12:21 , 14-Ноя-14, (20) //

поясню на примере http www mail-archive com dri-devel lists sourceforge net ms, develop7 (ok), 15:26 , 14-Ноя-14, (38) +3

Ок, верю, что ему-то это может и надо Аналогично А git рассчитывает diff-ы для б, Xaionaro (ok), 16:55 , 14-Ноя-14, (48) –4

Дельту он попробует посчитать Это не текстовый дифф, конечно Может получиться , Аноним (-), 05:49 , 15-Ноя-14, (68) +1

это же каким упоротым нужно быть чтобы гнать такой бред, all_glory_to_the_hypnotoad (ok), 02:41 , 15-Ноя-14, (62) +1
Вообще-то для начала у него там подробно расписан воркфлоу который он хочет виде, Аноним (-), 05:42 , 15-Ноя-14, (67) +1

Это вообще как И почему это - фича Гит вроде делает логичнее просто некуда - п, Аноним (-), 13:18 , 14-Ноя-14, (28)

Go, go, go А он может так же классно мозг взорвать как и C shared_ptr doub, _KUL (ok), 09:59 , 14-Ноя-14, (2) –3 //

В гамаке и ластах, да не удобно, тень_pavel_simple (?), 10:02 , 14-Ноя-14, (3) +2
Можно и икс себе отрезать что уж, пиши сразу void p void 0x1233425 int , Аноним (-), 10:03 , 14-Ноя-14, (4) +3 //

не, ну вы то ерундо то написали, _KUL (ok), 10:05 , 14-Ноя-14, (5) –1 //

это одинаковая ерунда, что в твоем примере, что в моем Учи c , Аноним (-), 10:20 , 14-Ноя-14, (6)

Ты то пальцем в небо тыкнул, туда байты инта начал загонять, тут понятно что буд, _KUL (ok), 11:30 , 14-Ноя-14, (14) –1

I m feeling luSegmentation fault, Michael Shigorin (ok), 13:11 , 14-Ноя-14, (26) –1

Конструктор shared_ptr, который принимает указатель, нужно вызывать явно explic, arsenicum (??), 10:54 , 14-Ноя-14, (12) +2
интеллектуального оргазм от с с достигается на таком коде code ifndef OPENS, Аноним (-), 12:19 , 14-Ноя-14, (19) –1 //

Сдуру можно и х сломать И root cause тут не сишечка, а 1 Переусложненный пр, Аноним (-), 06:11 , 15-Ноя-14, (69)

Ямщик, не гони sp_test cpp In function 8216 int main 8217 sp_test cpp 10 , Аноним (-), 12:47 , 14-Ноя-14, (24) +1
такие вещи надо писать на ржавчине, а не на плюсах , Аноним (-), 13:44 , 14-Ноя-14, (32)
Это язык для продакшнов, у него задачак как раз не взрывать мозг даже на сложных, Аноним (-), 15:27 , 14-Ноя-14, (39)
тут никакого взрыва мозга нет , all_glory_to_the_hypnotoad (ok), 02:25 , 15-Ноя-14, (60)

ещё в одном, отдельно взятом государстве наступил коммунизм , manster (ok), 12:36 , 14-Ноя-14, (23)
А теперь вопрос для размышления А ПОЧЕМУ НЕ НА code google com , Штунц (?), 13:05 , 14-Ноя-14, (25) +1 //

Потому что оно самое неудобное из всех хостингов и, можно сказать, сдохло , vitalif (ok), 13:16 , 14-Ноя-14, (27) +2
Вот лишь бы ляпнуть Как ты думаешь, где он хостился до этого всё ещё пока хости, агоним (?), 13:19 , 14-Ноя-14, (29) //

Адекватные для начала там никогда и не будут хоститься - достаточно 1 взглядя на, Аноним (-), 13:43 , 14-Ноя-14, (31) //

что за горбатые кирпичи Если речь про плитки, то в десятке они фактически выпил, Аноним (-), 13:52 , 14-Ноя-14, (33) –2

Как сделать хорошо Просто Сначала сделай чтоб было хуже, чтоб совсем плохо , Аноним (-), 19:02 , 14-Ноя-14, (51) +3
Мне если честно уже пофиг - у меня на десктопе и ноуте пингвин и мое DE совершен, Аноним (-), 14:56 , 15-Ноя-14, (76)

Как перенесут leveldb с гугль-кода - значит конец гуглькоду пришел Для меня так, Аноним (-), 14:12 , 14-Ноя-14, (34)

Ну, значит всёhttps code google com p leveldb The LevelDB project has moved to, Аноним (-), 18:49 , 14-Ноя-14, (50)

offtopic есть отличный проект quiterss, прижился, рекомендую , Michael Shigorin (ok), 16:19 , 14-Ноя-14, (43)

Потому что по сравнению с гитхабом он мм как бы это помягче то, без мата , Аноним (-), 13:41 , 14-Ноя-14, (30) //

Эээ гуёвый , Anonim (??), 00:45 , 15-Ноя-14, (55)
ничем особо не отличающийся, кроме количества хипстеров , arisu (ok), 15:05 , 16-Ноя-14, (88)

Судя по актуальным тенденциям Git победил и преступил к перетягиванию всех на се, Нимо Ан (?), 14:58 , 14-Ноя-14, (36) //

Разве это плохо , Аноним (-), 15:35 , 14-Ноя-14, (40) //

плохо ли невежество , develop7 (ok), 15:58 , 14-Ноя-14, (41) –1 //

Смотря что пытаются им назвать, а что -- представить как просвещённость , Michael Shigorin (ok), 16:23 , 14-Ноя-14, (44)
Использование гит невежество И да, вас не смущает что вы на опеннет должны и, Аноним (-), 15:20 , 15-Ноя-14, (77)

Многим нравится IPv6, но из-за монополии IPv4 переход очень сложен , Vkni (ok), 21:28 , 15-Ноя-14, (82) –2

1 У IPv6 есть навалом своих проблем В том числе новых и свежих 2 Если кто хоч, Аноним (-), 07:06 , 16-Ноя-14, (87)

Плохо , Vkni (ok), 21:28 , 15-Ноя-14, (81) –1 //

Не хуже чем необходимость использования IPv4 и HTTP для отправки сообщений на оп, Аноним (-), 07:01 , 16-Ноя-14, (86)

победил как технически более лучшее и удобное решение из доступных альтернатив , all_glory_to_the_hypnotoad (ok), 02:28 , 15-Ноя-14, (61) +3
разработчики FreeBSD смотрят на тебя как на говорящего микроба , arisu (ok), 15:07 , 16-Ноя-14, (89)

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

8. "Язык программирования Go переходит с Mercurial на Git и GitH..." –4 +/–

Сообщение от Аноним (-), 14-Ноя-14, 10:36

"Никто не знает гит". В том смысле, что он можный, но понимать - понимают его ой как далеко не все. Получаются ... с гранатой. :(

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

9. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 14-Ноя-14, 10:38

*мощный

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

10. "Язык программирования Go переходит с Mercurial на Git и GitH..." +1 +/–

Сообщение от Аноним (-), 14-Ноя-14, 10:38

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

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

11. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 14-Ноя-14, 10:39

> Так по минимуму его освоить не сложнее чем любую иную VCS, а
> продвинутости типа мержей и прочего - может делать кто-нибудь относительно вменяемый.
Ну так мерж, это как бе важная часть даже для базового использования, не? Или что вы имели ввиду?

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

15. "Язык программирования Go переходит с Mercurial на Git и GitH..." +4 +/–

Сообщение от Какаянахренразница (ok), 14-Ноя-14, 11:40

Реально базовое пользование, на мой взгляд, вот такое:
* pull
* checkout
* add
* commit
* push
checkout может быть опциональным. А merge будет делать "специалист".

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

17. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 14-Ноя-14, 11:51

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

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

45. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Vkni (ok), 14-Ноя-14, 16:24

> Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требуется только коммит по большому счету.
Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист". Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request.

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

54. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от vn971 (ok), 14-Ноя-14, 22:54

Я вот видел как-то раз закоммиченные неразрешённые конфликты..)

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

57. "Язык программирования Go переходит с Mercurial на Git и GitH..." +2 +/–

Сообщение от Ytch (ok), 15-Ноя-14, 01:16

> Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист".
Это для слияния в subversion нужен еще какой специалист! Хотя система-то попроще будет.

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

63. "Язык программирования Go переходит с Mercurial на Git и GitH..." +1 +/–

Сообщение от Аноним (-), 15-Ноя-14, 05:17

> раз для базовой функциональности - слияния, требуется "специалист"
Врядли вы хотите чтобы это вам делали дизайнеры и прочие ГСМщики, которые пару действий заучить еле могут. От таких - только коммиты с материалом, не более. Люди разные бывают...
> Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request.
При правильном подходе merge можно вынести на плечи тех кто понимает что он делает. Если обезьянка совсем дерево - вы врядли хотите после такой обезьянки мержи себе в проект.
А так git вполне логичная штука. Если не страдать гуманитарным складом ума с полным непониманием рабочих процессов и принятых в распределенных командах подходов.

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

70. "Язык программирования Go переходит с Mercurial на Git и GitH..." –1 +/–

Сообщение от Vkni (ok), 15-Ноя-14, 06:24

> При правильном подходе merge можно вынести на плечи тех кто понимает что
> он делает. Если обезьянка совсем дерево - вы врядли хотите после
> такой обезьянки мержи себе в проект.
Merge - это часто требуемая на местах функциональность, которую невозможно "переложить на плечи специалиста".
Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно, с github'овским master'ом. Т.е. либо git clone ... и ручное внесение своих изменений, либо merge. Чтобы было проще, синхронизироваться нужно раз в день-два. А ведение отдельной ветки до pull-request'а - минимум неделя.
И что - каждый день звать хозяина github'а с просьбой о помощи? :-)

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

73. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 15-Ноя-14, 14:32

> Merge - это часто требуемая на местах функциональность, которую невозможно "переложить
> на плечи специалиста".
Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов. Которые могут подогнать полезный проекту материал, но напрочь не технари и тем более не программисты. Я полагаю что таким людям лучше не проводить мерж ни в какой системе контроля версий, во избежание факапа лишний раз.
> Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно,
> с github'овским master'ом. Т.е. либо git clone ... и ручное внесение
> своих изменений, либо merge.
А чем вам не нравится git pull из мастера, если уж оно надо? Мерж потребуется только при конфликтах, а поскольку дизайнеры, техписы, переводчики и прочие манагеры код трогать вообще не должны, конфликт свидетельствует или о каком-то грубом косяке со стороны такого индивида, или о том что PM пролошился и разные люди два раза работали над одним файлом типа рисунка, что заведомо кривая ситуация, иррелевантно к vcs. А в нормальном виде, покуда нет грубых нарушений воркфлоу - такие люди просто не должны налетать на конфликты и нужду мержа. Меньше проблем всем остальным.
> Чтобы было проще, синхронизироваться нужно раз в
> день-два. А ведение отдельной ветки до pull-request'а - минимум неделя.
Дизайнер или техпис врядли сможет сделать мерж нормально. Как операцию. Независимо от VCS. Поэтому этим должны заниматься другие, во избежание. И таким людям кстати совершенно не обязательно синхриться с мастером раз в пять минут - сделали фичу да выкатили пулл реквест. Остальное вообще не их дело.
> И что - каждый день звать хозяина github'а с просьбой о помощи? :-)
Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать.

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

79. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Vkni (ok), 15-Ноя-14, 20:59

> Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов.
А зачем они вообще должны туда лезть-то? Merge должен делать человек, понимающий в предмете в первую очередь. Если это статья - редактирующий статью, если код - редактирующий код.
> А чем вам не нравится git pull из мастера, если уж оно надо?
Если в мастере произошли изменения в тех же файлах, что ты правил, хочешь-нехочешь, а придётся синхронизировать. Ну и pull-request лучше, всё-таки, делать чистый.
> Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать.
Если несколько переводчиков работают над одним текстом, всунутым в VCS, им придётся делать merge. И при этом желательно ничего не ломать.

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

83. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 16-Ноя-14, 06:19

> Merge должен делать человек, понимающий в предмете в первую очередь.
Совершенно не обязательно, ибо понимание предмета != умение делать технически сложные и достаточно ответственные операции. Технические умения ГСМщиков обычно "не очень" и с компьютерами они "на Вы". Получать мерж после таких индивидов может быть достаточно чреватой идеей. Хоть я и допускаю мысль что часть из них можно научить этому, это уже достаточно индивидуально. А в случае какого-нибудь дизайнера нужда выполнять мерж вообще означает какой-то факап в рабочем процессе.
> Если в мастере произошли изменения в тех же файлах, что ты правил,
...то в случае таких ГСМщиков это обычно означает продолб в рабочем процессе.
> Если несколько переводчиков работают над одним текстом, всунутым в VCS,
> им придётся делать merge. И при этом желательно ничего не ломать.
Если честно, на практике я ни разу не встречал ситуации чтобы несколько переводчиков лопатили 1 файл. Во первых, нормальный переводчик стоит денег и поэтому даже в очень большой и крутой конторе их обычно спасибо если 1-2 человека. В опенсорсных проектах может быть и поболее. А может и не быть. Но тут есть во вторых. Во вторых, обычно работа такого плана разбита на юниты вменяемого размера которые может лопатить по человеку на файл, не задевая друг друга. Так чтобы Войну и Мир сразу двутомником переводили как 1 файл - такого я попросту никогда не видел, так никто не делает. А те кому ну просто крындец как надо много возиться с переводами программ - иногда используют узкоспециализированный онлайн сервис Transifex. Но для большинства случаев это как-то оверкилл.

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

56. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от umbr (ok), 15-Ноя-14, 00:46

Наверно не мерж, а разруливание конфликтов - так это везде повод для паники.

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

64. "Язык программирования Go переходит с Mercurial на Git и GitH..." +1 +/–

Сообщение от Аноним (-), 15-Ноя-14, 05:18

> Наверно не мерж, а разруливание конфликтов - так это везде повод для
> паники.
А я не знаю почему Vkni возомнил что это в других VCS как-то проще.

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

71. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Vkni (ok), 15-Ноя-14, 06:26

> Наверно не мерж, а разруливание конфликтов - так это везде повод для
> паники.
Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из базовой функциональности git (см. комменты выше).
Какое может быть "позвать специалиста", если синхронизировать с github'овским мастером нужно раз в день-два, а разрабатывать свою ветку до pull-request'а неделю? :-)

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

74. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 15-Ноя-14, 14:43

> Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из
> базовой функциональности git (см. комменты выше).
А мне кажется наивным уповать на то что дизайнер или техпис может сделать мерж правильно и ничего при этом не сломать. Хоть там в какой VCS. Поэтому лучше строить воркфлоу так чтобы это делали иные люди. Которые понимают что это такое и как работает. И вполне можно сделать так что индивиду не придется ничего мержить пока он пилит свою фичу. А если индивид окажется не тyпым в техническом плане - можно обучить его основам и поднять эффективность взаимодействия с оным, aka получив возможность совместно работать над одними и теми же файлами. Но это катит только для текстовых файлов (как вы себе представляете мерж картинки со стороны VCS?) и не со 100% индивидов.
> Какое может быть "позвать специалиста",
Если человек не может делать мержи - его налет на нужду это делать должен стало быть исключением а не правилом. Это несколько лимитирует возможные воркфлоу но не делает взаимодействие с человеком невозможным. Хоть и может сделать взаимодействие менее приятным чем могло бы быть.
> если синхронизировать с github'овским мастером нужно раз в день-два,
> а разрабатывать свою ветку до pull-request'а неделю? :-)
Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами надо часто синхриться и тем более что-то мержить. Они по идее вообще ни с кем конфликтовать не должны и если это случается - где-то в воркфлоу порылся нехилый косяк.

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

80. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Vkni (ok), 15-Ноя-14, 21:24

> И вполне можно сделать так что индивиду не придется ничего мержить пока
> он пилит свою фичу.
Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce).
> Но это катит только для текстовых файлов (как вы
> себе представляете мерж картинки со стороны VCS?) и не со 100%
> индивидов.
Тут хорошая тема поднимается - как делать VCS для нетекстовых данных. Кстати, это не сделано ли во всяких Google Docs?
> Если человек не может делать мержи - его налет на нужду это
> делать должен стало быть исключением, а не правилом.
Угук. Только далеко не всегда это возможно, поэтому исключение очень легко может перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён.
> Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами
Если процесс сделан так, то git pull сделает всё сам. Это - идеал, но не всегда возможный идеал.

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

84. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 16-Ноя-14, 06:39

> Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce).
На самом деле очень зависит от людей и того над чем они работают. Поэтому каких-то абсолютно универсальных рецептов не бывает. У нормальных проектов есть некий запас гибкости для того чтобы провзаимодействовать с неким ценным кадром, желательно как можно меньше напрягая остальных. Собственно, хороший руководитель проекта кроме всего прочего может такие вещи утрясти до формата когда процесс идет, явных продолбов не случается и команда не исходит на мат от кривых инструментов и подходов.
> Тут хорошая тема поднимается - как делать VCS для нетекстовых данных.
Ну да, это довольно отдельная тема. И я не уверен что отложенное совместное редактирование например картинок вообще эффективно. Вот толпой отредактировать картинку в реалтайм - может и прокатит, но такие процессы имеют свойство скатываться в бардак который очень бесит участников, если индивиды не идеально скоординированны. Проверено на сервисе совместного редактирования текстов. Очень бесит когда кто-то буквально под твоим пером переписывает у тебя текст на полуфразе и ты остаешься в обломе.
> Кстати, это не сделано ли во всяких Google Docs?
Не знаю, я ими не польуюсь. А что, они умеют мерж допустим картинок из нескольких источников в одну? И как это выглядит? Нет, я понимаю как посчитать бинарный дифф пары битмапов, но он совершенно не обязан оказаться именно тем что все хотели, а как-то более гранулярно выбирать что вот тут мы берем пикселы от Васи, а тут от Пети - выглядит не очень простой в реализации затеей и я что-то не уверен что таким vcs должен заниматься.
> перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён.
Да там и нет никакой ракетной науки. Просто некоторые ГСМщики настолько "на Вы" с компьютером что будет лучше если они не будут это делать и это будет именно исключением для них.
> Если процесс сделан так, то git pull сделает всё сам. Это -
> идеал, но не всегда возможный идеал.
Ну ок, у меня одна картинка а в мастере другая. При том обе отличаются от общего предка. И чего должен сделать автомат? Врубить AI и вместо участников проекта решить какая же картинка правильная? Ну если там такой крутой AI, может команду уже пора уволить? Если AI может такое решение принять - он пожалуй и картинки нарисовать сможет и код напишет :).

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

59. "Язык программирования Go переходит с Mercurial на Git и GitH..." +1 +/–

Сообщение от imprtat (ok), 15-Ноя-14, 01:56

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

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

65. "Язык программирования Go переходит с Mercurial на Git и GitH..." +/–

Сообщение от Аноним (-), 15-Ноя-14, 05:19

> А для тех кто не может осилить набор команд и их параметры
...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не вяжет, а вы ему ответственную работу?!

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

78. "Язык программирования Go переходит с Mercurial на Git и GitH..." –2 +/–

Сообщение от iZEN (ok), 15-Ноя-14, 16:41

>> А для тех кто не может осилить набор команд и их параметры
> ...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не
> вяжет, а вы ему ответственную работу?!
Наверно, в Git и SVN/CVS операция merge — ответственная работа.
В hg про merge должен быть в курсе каждый разработчик, который коммитит в центральный репозиторий. Иначе он не сможет запушить свои изменения, конфликтующие с теми, которые уже есть в репозитории и сделаны до него.
Для успешного разрешения конфликта в hg нужно воспользоваться операцией merge на месте — провести слияние сначала в локальном репозитории, протестировать слияние, закоммитить, а потом уже пушить результат в центральный репозиторий.
То есть понимание работы операции merge является одним из основных особенностей работы в команде с hg. Без этого знания разработчикам на местах делать будет просто нечего — они не смогут обмениваться единым кодом.

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

85. "Язык программирования Go переходит с Mercurial на Git и GitH..." +1 +/–

Сообщение от Аноним (-), 16-Ноя-14, 06:45

Знакомьтесь, это - изен. Он сегодня делает то же что и обычно - тормозит и затупляет.

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

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

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

Партнёры:

Хостинг:

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

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


	8. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–4 +/–
	Сообщение от Аноним (-), 14-Ноя-14, 10:36
	"Никто не знает гит". В том смысле, что он можный, но понимать - понимают его ой как далеко не все. Получаются ... с гранатой. :(
	Ответить \| Правка \| К родителю #1 \| Наверх \| Cообщить модератору


	9. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 14-Ноя-14, 10:38
	*мощный
	Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (-), 14-Ноя-14, 10:38
	Так по минимуму его освоить не сложнее чем любую иную VCS, а продвинутости типа мержей и прочего - может делать кто-нибудь относительно вменяемый.
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	11. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 14-Ноя-14, 10:39
	> Так по минимуму его освоить не сложнее чем любую иную VCS, а > продвинутости типа мержей и прочего - может делать кто-нибудь относительно вменяемый. Ну так мерж, это как бе важная часть даже для базового использования, не? Или что вы имели ввиду?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	15. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+4 +/–
	Сообщение от Какаянахренразница (ok), 14-Ноя-14, 11:40
	Реально базовое пользование, на мой взгляд, вот такое: * pull * checkout * add * commit * push checkout может быть опциональным. А merge будет делать "специалист".
	Ответить \| Правка \| Наверх \| Cообщить модератору


	17. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 14-Ноя-14, 11:51
	Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требуется только коммит по большому счету.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	45. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok), 14-Ноя-14, 16:24
	> Я имел в виду что мержить может кто-то квалифицированный, а от обезьянок требуется только коммит по большому счету. Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист". Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	54. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от vn971 (ok), 14-Ноя-14, 22:54
	Я вот видел как-то раз закоммиченные неразрешённые конфликты..)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	57. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+2 +/–
	Сообщение от Ytch (ok), 15-Ноя-14, 01:16
	> Т.е. Git - переусложнён, раз для базовой функциональности - слияния, требуется "специалист". Это для слияния в subversion нужен еще какой специалист! Хотя система-то попроще будет.
	Ответить \| Правка \| К родителю #45 \| Наверх \| Cообщить модератору


	63. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (-), 15-Ноя-14, 05:17
	> раз для базовой функциональности - слияния, требуется "специалист" Врядли вы хотите чтобы это вам делали дизайнеры и прочие ГСМщики, которые пару действий заучить еле могут. От таких - только коммиты с материалом, не более. Люди разные бывают... > Merge требуется ведь, если просто ведёшь свою ветку, на которую потом сделаешь pull request. При правильном подходе merge можно вынести на плечи тех кто понимает что он делает. Если обезьянка совсем дерево - вы врядли хотите после такой обезьянки мержи себе в проект. А так git вполне логичная штука. Если не страдать гуманитарным складом ума с полным непониманием рабочих процессов и принятых в распределенных командах подходов.
	Ответить \| Правка \| К родителю #45 \| Наверх \| Cообщить модератору


	70. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–1 +/–
	Сообщение от Vkni (ok), 15-Ноя-14, 06:24
	> При правильном подходе merge можно вынести на плечи тех кто понимает что > он делает. Если обезьянка совсем дерево - вы врядли хотите после > такой обезьянки мержи себе в проект. Merge - это часто требуемая на местах функциональность, которую невозможно "переложить на плечи специалиста". Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно, с github'овским master'ом. Т.е. либо git clone ... и ручное внесение своих изменений, либо merge. Чтобы было проще, синхронизироваться нужно раз в день-два. А ведение отдельной ветки до pull-request'а - минимум неделя. И что - каждый день звать хозяина github'а с просьбой о помощи? :-)
	Ответить \| Правка \| Наверх \| Cообщить модератору


	73. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 15-Ноя-14, 14:32
	> Merge - это часто требуемая на местах функциональность, которую невозможно "переложить > на плечи специалиста". Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов. Которые могут подогнать полезный проекту материал, но напрочь не технари и тем более не программисты. Я полагаю что таким людям лучше не проводить мерж ни в какой системе контроля версий, во избежание факапа лишний раз. > Например, merge нужен для того, чтобы синхронизировать свою ветку, которую ведёшь отдельно, > с github'овским master'ом. Т.е. либо git clone ... и ручное внесение > своих изменений, либо merge. А чем вам не нравится git pull из мастера, если уж оно надо? Мерж потребуется только при конфликтах, а поскольку дизайнеры, техписы, переводчики и прочие манагеры код трогать вообще не должны, конфликт свидетельствует или о каком-то грубом косяке со стороны такого индивида, или о том что PM пролошился и разные люди два раза работали над одним файлом типа рисунка, что заведомо кривая ситуация, иррелевантно к vcs. А в нормальном виде, покуда нет грубых нарушений воркфлоу - такие люди просто не должны налетать на конфликты и нужду мержа. Меньше проблем всем остальным. > Чтобы было проще, синхронизироваться нужно раз в > день-два. А ведение отдельной ветки до pull-request'а - минимум неделя. Дизайнер или техпис врядли сможет сделать мерж нормально. Как операцию. Независимо от VCS. Поэтому этим должны заниматься другие, во избежание. И таким людям кстати совершенно не обязательно синхриться с мастером раз в пять минут - сделали фичу да выкатили пулл реквест. Остальное вообще не их дело. > И что - каждый день звать хозяина github'а с просьбой о помощи? :-) Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	79. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok), 15-Ноя-14, 20:59
	> Я по прежнему считаю что вы врядли захотите получить результат мержа после дизайнера, манагера-маркетолога и прочих техписов. А зачем они вообще должны туда лезть-то? Merge должен делать человек, понимающий в предмете в первую очередь. Если это статья - редактирующий статью, если код - редактирующий код. > А чем вам не нравится git pull из мастера, если уж оно надо? Если в мастере произошли изменения в тех же файлах, что ты правил, хочешь-нехочешь, а придётся синхронизировать. Ну и pull-request лучше, всё-таки, делать чистый. > Ну если глупить с организацией воркфлоу - еще и не так можно. Но я думаю что воркфлоу надо строить "с каждого по способностям" и мне кажется наивным уповать на то что переводчик может хорошо сделать мерж и ничего не сломать. Если несколько переводчиков работают над одним текстом, всунутым в VCS, им придётся делать merge. И при этом желательно ничего не ломать.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	83. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 16-Ноя-14, 06:19
	> Merge должен делать человек, понимающий в предмете в первую очередь. Совершенно не обязательно, ибо понимание предмета != умение делать технически сложные и достаточно ответственные операции. Технические умения ГСМщиков обычно "не очень" и с компьютерами они "на Вы". Получать мерж после таких индивидов может быть достаточно чреватой идеей. Хоть я и допускаю мысль что часть из них можно научить этому, это уже достаточно индивидуально. А в случае какого-нибудь дизайнера нужда выполнять мерж вообще означает какой-то факап в рабочем процессе. > Если в мастере произошли изменения в тех же файлах, что ты правил, ...то в случае таких ГСМщиков это обычно означает продолб в рабочем процессе. > Если несколько переводчиков работают над одним текстом, всунутым в VCS, > им придётся делать merge. И при этом желательно ничего не ломать. Если честно, на практике я ни разу не встречал ситуации чтобы несколько переводчиков лопатили 1 файл. Во первых, нормальный переводчик стоит денег и поэтому даже в очень большой и крутой конторе их обычно спасибо если 1-2 человека. В опенсорсных проектах может быть и поболее. А может и не быть. Но тут есть во вторых. Во вторых, обычно работа такого плана разбита на юниты вменяемого размера которые может лопатить по человеку на файл, не задевая друг друга. Так чтобы Войну и Мир сразу двутомником переводили как 1 файл - такого я попросту никогда не видел, так никто не делает. А те кому ну просто крындец как надо много возиться с переводами программ - иногда используют узкоспециализированный онлайн сервис Transifex. Но для большинства случаев это как-то оверкилл.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	56. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от umbr (ok), 15-Ноя-14, 00:46
	Наверно не мерж, а разруливание конфликтов - так это везде повод для паники.
	Ответить \| Правка \| К родителю #11 \| Наверх \| Cообщить модератору


	64. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (-), 15-Ноя-14, 05:18
	> Наверно не мерж, а разруливание конфликтов - так это везде повод для > паники. А я не знаю почему Vkni возомнил что это в других VCS как-то проще.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	71. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok), 15-Ноя-14, 06:26
	> Наверно не мерж, а разруливание конфликтов - так это везде повод для > паники. Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из базовой функциональности git (см. комменты выше). Какое может быть "позвать специалиста", если синхронизировать с github'овским мастером нужно раз в день-два, а разрабатывать свою ветку до pull-request'а неделю? :-)
	Ответить \| Правка \| К родителю #56 \| Наверх \| Cообщить модератору


	74. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 15-Ноя-14, 14:43
	> Я неправильно написал: меня возмутил подход "позвать специалиста" и исключение merge из > базовой функциональности git (см. комменты выше). А мне кажется наивным уповать на то что дизайнер или техпис может сделать мерж правильно и ничего при этом не сломать. Хоть там в какой VCS. Поэтому лучше строить воркфлоу так чтобы это делали иные люди. Которые понимают что это такое и как работает. И вполне можно сделать так что индивиду не придется ничего мержить пока он пилит свою фичу. А если индивид окажется не тyпым в техническом плане - можно обучить его основам и поднять эффективность взаимодействия с оным, aka получив возможность совместно работать над одними и теми же файлами. Но это катит только для текстовых файлов (как вы себе представляете мерж картинки со стороны VCS?) и не со 100% индивидов. > Какое может быть "позвать специалиста", Если человек не может делать мержи - его налет на нужду это делать должен стало быть исключением а не правилом. Это несколько лимитирует возможные воркфлоу но не делает взаимодействие с человеком невозможным. Хоть и может сделать взаимодействие менее приятным чем могло бы быть. > если синхронизировать с github'овским мастером нужно раз в день-два, > а разрабатывать свою ветку до pull-request'а неделю? :-) Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами надо часто синхриться и тем более что-то мержить. Они по идее вообще ни с кем конфликтовать не должны и если это случается - где-то в воркфлоу порылся нехилый косяк.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	80. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Vkni (ok), 15-Ноя-14, 21:24
	> И вполне можно сделать так что индивиду не придется ничего мержить пока > он пилит свою фичу. Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce). > Но это катит только для текстовых файлов (как вы > себе представляете мерж картинки со стороны VCS?) и не со 100% > индивидов. Тут хорошая тема поднимается - как делать VCS для нетекстовых данных. Кстати, это не сделано ли во всяких Google Docs? > Если человек не может делать мержи - его налет на нужду это > делать должен стало быть исключением, а не правилом. Угук. Только далеко не всегда это возможно, поэтому исключение очень легко может перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён. > Не очень понимаю зачем техпису или дизайнеру пашущими над своими файликами Если процесс сделан так, то git pull сделает всё сам. Это - идеал, но не всегда возможный идеал.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	84. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 16-Ноя-14, 06:39
	> Это желательно. Тем более, что это стандартный алгоритм параллелизации работы (Map-Reduce). На самом деле очень зависит от людей и того над чем они работают. Поэтому каких-то абсолютно универсальных рецептов не бывает. У нормальных проектов есть некий запас гибкости для того чтобы провзаимодействовать с неким ценным кадром, желательно как можно меньше напрягая остальных. Собственно, хороший руководитель проекта кроме всего прочего может такие вещи утрясти до формата когда процесс идет, явных продолбов не случается и команда не исходит на мат от кривых инструментов и подходов. > Тут хорошая тема поднимается - как делать VCS для нетекстовых данных. Ну да, это довольно отдельная тема. И я не уверен что отложенное совместное редактирование например картинок вообще эффективно. Вот толпой отредактировать картинку в реалтайм - может и прокатит, но такие процессы имеют свойство скатываться в бардак который очень бесит участников, если индивиды не идеально скоординированны. Проверено на сервисе совместного редактирования текстов. Очень бесит когда кто-то буквально под твоим пером переписывает у тебя текст на полуфразе и ты остаешься в обломе. > Кстати, это не сделано ли во всяких Google Docs? Не знаю, я ими не польуюсь. А что, они умеют мерж допустим картинок из нескольких источников в одну? И как это выглядит? Нет, я понимаю как посчитать бинарный дифф пары битмапов, но он совершенно не обязан оказаться именно тем что все хотели, а как-то более гранулярно выбирать что вот тут мы берем пикселы от Васи, а тут от Пети - выглядит не очень простой в реализации затеей и я что-то не уверен что таким vcs должен заниматься. > перетечь в правило. Поэтому merge должен быть как можно сильнее упрощён. Да там и нет никакой ракетной науки. Просто некоторые ГСМщики настолько "на Вы" с компьютером что будет лучше если они не будут это делать и это будет именно исключением для них. > Если процесс сделан так, то git pull сделает всё сам. Это - > идеал, но не всегда возможный идеал. Ну ок, у меня одна картинка а в мастере другая. При том обе отличаются от общего предка. И чего должен сделать автомат? Врубить AI и вместо участников проекта решить какая же картинка правильная? Ну если там такой крутой AI, может команду уже пора уволить? Если AI может такое решение принять - он пожалуй и картинки нарисовать сможет и код напишет :).
	Ответить \| Правка \| Наверх \| Cообщить модератору


	59. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от imprtat (ok), 15-Ноя-14, 01:56
	Как по мне, мердж в гите прост, и уж явно удобнее чем в свн, к примеру. А для тех кто не может осилить набор команд и их параметры есть гуевыые или встроенные в IDE клиенты.
	Ответить \| Правка \| К родителю #10 \| Наверх \| Cообщить модератору


	65. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+/–
	Сообщение от Аноним (-), 15-Ноя-14, 05:19
	> А для тех кто не может осилить набор команд и их параметры ...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не вяжет, а вы ему ответственную работу?!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	78. "Язык программирования Go переходит с Mercurial на Git и GitH..."	–2 +/–
	Сообщение от iZEN (ok), 15-Ноя-14, 16:41
	>> А для тех кто не может осилить набор команд и их параметры > ...таким разруливание конфликтов лучше вообще не доверять, для начала. Человек лыка не > вяжет, а вы ему ответственную работу?! Наверно, в Git и SVN/CVS операция merge — ответственная работа. В hg про merge должен быть в курсе каждый разработчик, который коммитит в центральный репозиторий. Иначе он не сможет запушить свои изменения, конфликтующие с теми, которые уже есть в репозитории и сделаны до него. Для успешного разрешения конфликта в hg нужно воспользоваться операцией merge на месте — провести слияние сначала в локальном репозитории, протестировать слияние, закоммитить, а потом уже пушить результат в центральный репозиторий. То есть понимание работы операции merge является одним из основных особенностей работы в команде с hg. Без этого знания разработчикам на местах делать будет просто нечего — они не смогут обмениваться единым кодом.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	85. "Язык программирования Go переходит с Mercurial на Git и GitH..."	+1 +/–
	Сообщение от Аноним (-), 16-Ноя-14, 06:45
	Знакомьтесь, это - изен. Он сегодня делает то же что и обычно - тормозит и затупляет.
	Ответить \| Правка \| Наверх \| Cообщить модератору