Ну любой железный рейд контроллер должен уметь организовать одновременно несколько наборов. Читайте вашу документацию.
Я такие вещи делал на железных рейдах еще лет 20 назад, все работало.
Но опять таки, это надо руками проверять что будет если файлы разной длины, если svn не сможет определить смещение.
Вообще система контроля версий это явно не про экономию места.
sWanderer,
Я предполагаю, что меняются как раз либо те, кто что-то знает и быстро находит работу получше, либо те, кто плохо знает.
А костяк - в своем большинстве те, которым не хочется что-либо менять, но как вы понимаете, в современной разработке они вряд ли разбираются. Зачастую это уже пенсионеры.
Опять же. Не только я, но и многие другие вам говорят, что гораздо важнее то, что вы возьмете от кафедры, чем то, что вам дадут.
Это справедливо для разных учебных учреждений в СНГ. Попробуйте этот аргумент принять, и понять что он может иметь бОльшее значение, чем небольшая разница между вузами.
rromm, естественно будет бежать с первого коммита по всем. В случае огромных файлов, возможно это будет занимать какое-то время, плюс есть и другие неудобства. Например .svn директория в каждой директории.
А так - svn хранит дельты, и каждый раз их рассчитывает с нуля.
sWanderer,
Если есть знакомые программисты, спросите как часто они писали именно алгоритмы вроде сортировки, или расчета вероятности.
В программировании, большинство математических алгоритмов уже реализовано в виде готовых функций и библиотек - выбирай и пользуйся.
И под алгоритмом подразумевается умение работать с if/else и переходами.
Современное программирование - это объектно-ориентированное программирование, это паттерны, это знание стандартных библиотек, знакомство с фреймворками.
Математические алгоритмы тут мало востребованы, и нужны косвенно.
ВО не будет мешать, и будет сопутствовать, но оно не учит программированию.
Если вы когда-нибудь будете работать с нейросетями, или писать 3д движки, знание математики вам конечно сильно поможет в том, что вы быстрее разберетесь с тем, что происходит и проще будет выяснять ошибку.
elfix, Есть инструменты, которые парсят дом дерево, следовательно можно одной строкой выбрать значение тега href в классе Title и не мучаться с количеством кавычек, скобок и так далее.
sWanderer, По сути - образовательная программа утверждается сверху, поэтому в вузах особой разницы не будет.
Алгоритмы - изучают на математике. Все эти дискретные анализы и теории вероятности будут учить на бумажке, а не на программах.
Программирование в вузах изучают на уровне запрограммировать какой-либо алгоритм в его простейшем виде. В некоторых могут сказать сделать это на ассемблере, в некоторых на паскале.
Отношение к современному программированию это относится никак, поскольку не учат ни смыслу ни стилю ни работе с современными утилитами.
Поэтому нет смысла выбирать что лучше именно для программирования. Выбирайте по удобству. А программирование изучайте ОТДЕЛЬНО от программы вуза.
Вряд ли такое возможно.
Есть огромное количество программистов работающих в аутсорс. И сидя в одной стране, они могут считаться работниками компании в другой стране.
git хранит измененные файлы целиком.
1) Но это гораздо меньше, чем две папки.
2) гораздо быстрее переключаться между двумя версиями, чем отсчитывать дифф с первого изменения, если их много накопилось
Роман Мирр, ну это не вопрос. Это задача поднять две базы, забить их хотя бы 100-гбайтными данными, при этом сопоставимую структуру и мерять. Уж цифры не приведу.
Благодаря индексам, SQL базы могут делать быстрые выборки. Но постройка индексов обходится недешево, и там где sql быстрее выберет, монго НАМНОГО быстрее обновит или вставит, а это бывает зачастую важнее - успеть быстро сохранить данные.
Скажем так, для своей задачи - реляционная база данных архитектурно рассчитана на работу с таблицами, и лочит их обычно по таблицам или по столбцам.
В той же монги такого понятия нет, оверхеда по этому поводу тоже нет.
Поэтому при работе со структурой типа объект, монго будет работать быстрее.
Естественно что эта скорость будет заметна на больших объемах. Мегабайты можно в любой базе примерно со одинаковой скоростью обрабатывать. Но когда счет идет на сотни гигабайт - тут можно подобрать носкл базу, которая лучше подходит под задачи.
Так если у вас сам invoke_shell не поддерживает xterm, нет смысла его ставить.
Попробуйте на стороне сервера поставить терминал без esc последовательностей.
что-то старое
vt100
screen
linux
dumb
Я такие вещи делал на железных рейдах еще лет 20 назад, все работало.