Сообщение Re[58]: факапы на работе от 19.04.2017 13:41
Изменено 19.04.2017 13:46 Vain
Re[58]: факапы на работе
Здравствуйте, ·, Вы писали:
V>>Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься.
·>Это тебе так кажется потому что ты не умеешь.
Ты путаешь не умею с не хочу.
·>А популярность pull requests тебе ни на что не намекает?
Что ещё за популярность? Звучит как популярность геев и садомазо.
V>>А вот уже в общий транк хочешь не хочешь, а мержить придётся.
·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.
V>>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.
·>Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.
Ваша секта именно что навязывает эту идеалогию, нечего здесь кривляться якобы что ты здесь ни причём.
V>>Я пока одни глупости про свн от тебя слышу.
·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
Ты хотя бы вдумывайся для кого она написана и что там написано.
V>>разберись сначала с простой системой типа свн.
·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
Да мне плевать, вот честно.
V>>Такая что тебе общий файл нужен на выходе, а не их разница.
·>А что по-твоему является результатом операции "apply the differences"?
Алгоритм не обязан apply differences делать, у него на входе целые файлы.
V>>Ну да, это он делает для хранения истории изменений.
·>Что "это"?? Причём тут вообще хранение истории?
Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.
V>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
·>Перечисли плиз, _со ссылкой на доку svn_.
С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
V>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.
·>Это общие слова. А как конкретно это работает в svn?
Щито? Это вообще суть мержа, т.е. его цель. То что гано получить имея что-то, а как это будет достигнуто — дело десятое.
V>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.
V>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.
·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой. В сорсфорже по-другому, там надо изначально самому архив создать и залить.
V>>Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься.
·>Это тебе так кажется потому что ты не умеешь.
Ты путаешь не умею с не хочу.
·>А популярность pull requests тебе ни на что не намекает?
Что ещё за популярность? Звучит как популярность геев и садомазо.
V>>А вот уже в общий транк хочешь не хочешь, а мержить придётся.
·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.
V>>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.
·>Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.
Ваша секта именно что навязывает эту идеалогию, нечего здесь кривляться якобы что ты здесь ни причём.
V>>Я пока одни глупости про свн от тебя слышу.
·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
Ты хотя бы вдумывайся для кого она написана и что там написано.
V>>разберись сначала с простой системой типа свн.
·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
Да мне плевать, вот честно.
V>>Такая что тебе общий файл нужен на выходе, а не их разница.
·>А что по-твоему является результатом операции "apply the differences"?
Алгоритм не обязан apply differences делать, у него на входе целые файлы.
V>>Ну да, это он делает для хранения истории изменений.
·>Что "это"?? Причём тут вообще хранение истории?
Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.
V>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
·>Перечисли плиз, _со ссылкой на доку svn_.
С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
V>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.
·>Это общие слова. А как конкретно это работает в svn?
Щито? Это вообще суть мержа, т.е. его цель. То что гано получить имея что-то, а как это будет достигнуто — дело десятое.
V>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.
V>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.
·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой. В сорсфорже по-другому, там надо изначально самому архив создать и залить.
Re[58]: факапы на работе
Здравствуйте, ·, Вы писали:
V>>Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься.
·>Это тебе так кажется потому что ты не умеешь.
Ты путаешь не умею с не хочу.
·>А популярность pull requests тебе ни на что не намекает?
Что ещё за популярность? Звучит как популярность геев и садомазо.
V>>А вот уже в общий транк хочешь не хочешь, а мержить придётся.
·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.
V>>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.
·>Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.
Ваша секта именно что навязывает эту идеалогию, нечего здесь кривляться якобы что ты здесь ни причём.
V>>Я пока одни глупости про свн от тебя слышу.
·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
Ты хотя бы вдумывайся для кого она написана и что там написано.
V>>разберись сначала с простой системой типа свн.
·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
Да мне плевать, вот честно.
V>>Такая что тебе общий файл нужен на выходе, а не их разница.
·>А что по-твоему является результатом операции "apply the differences"?
Алгоритм не обязан apply differences делать, у него на входе целые файлы.
V>>Ну да, это он делает для хранения истории изменений.
·>Что "это"?? Причём тут вообще хранение истории?
Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.
V>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
·>Перечисли плиз, _со ссылкой на доку svn_.
С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
V>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.
·>Это общие слова. А как конкретно это работает в svn?
Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.
V>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.
V>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.
·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой. В сорсфорже по-другому, там надо изначально самому архив создать и залить.
V>>Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься.
·>Это тебе так кажется потому что ты не умеешь.
Ты путаешь не умею с не хочу.
·>А популярность pull requests тебе ни на что не намекает?
Что ещё за популярность? Звучит как популярность геев и садомазо.
V>>А вот уже в общий транк хочешь не хочешь, а мержить придётся.
·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.
V>>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.
·>Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.
Ваша секта именно что навязывает эту идеалогию, нечего здесь кривляться якобы что ты здесь ни причём.
V>>Я пока одни глупости про свн от тебя слышу.
·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
Ты хотя бы вдумывайся для кого она написана и что там написано.
V>>разберись сначала с простой системой типа свн.
·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
Да мне плевать, вот честно.
V>>Такая что тебе общий файл нужен на выходе, а не их разница.
·>А что по-твоему является результатом операции "apply the differences"?
Алгоритм не обязан apply differences делать, у него на входе целые файлы.
V>>Ну да, это он делает для хранения истории изменений.
·>Что "это"?? Причём тут вообще хранение истории?
Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.
V>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.
·>Перечисли плиз, _со ссылкой на доку svn_.
С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
V>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.
·>Это общие слова. А как конкретно это работает в svn?
Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.
V>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.
V>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.
·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой. В сорсфорже по-другому, там надо изначально самому архив создать и залить.