С finally в случае исключения условно говоря вызывается вирутальная процедура, тело которой записано в блоке finally, а после этого исключение, котрое как было, так и осталось, забрасывается выше. В случае с catch перед тем как вызывать виртуальную процедуру в блоке catch, исключение удаляется из цепочки. В компилируемых языках так, наверняка, здесь аналогично.
Это проблема не собственно SVNа, а идеологии центрального репозитория вообще. Разным задачам разные средства. Мне, в небольшой команде, удобно иметь центральный, reference так сказать, репозиторий. То, что svn не работает при недоступности сервера, кмк, сродни жалобе, что компьютер не работает при отсутствии электричества, а человек — кислорода.
И почему нельзя восстановить svn из рабочей копии (при условии, что она не изменена сильно, максимум, +- дневные изменения)?
Я использую GIT поверх SVN для локальных веток при работе над разными тикетами.
А серьезно? Какие нарекания, интересно же. А то получается, как в презентации Торвальдса по GIT: «Вы пробовали когда-нибудь смерджить что-то в xyz? Это ужас» и закатывание глаз к потолку. Толку-то с такой критики.
Я не спорю — возможно, действительно, есть жуткие косяки, которые мне из-за небольшого опыта не увидеть. Вот и интересно, почему критикуют.
С чего бы это? Кому должны?
Если я коммичу десяток файлов, измененных для какой-то фичи, я напишу, что сделано (добавлена фича xyz), а не почему. Мало ли почему добавлена… захотелось.
Тогда и исходники можно откатывать из резервной копии. Зачем, если есть скв?
важнее понять какие изменения произошли из-за чего нужно делать откат.
diff тоже не всегда поможет — опустим, одну иконку в hex заменили на другую. Как понять, что где?
Сложно представить, где может не хватит комментария к коммиту, который описывает изменения.
Об этом и речь. Понятно, что TLB. Насколько быстрее работа с последовательными данными именно в виртуальной памяти? Что именно кешируется в L2? Я спрашиваю, без подколок. Интересно же.
Нет, получить и установить контекст можно только для остановленного потока, т.е. нужен третий ThreadCloneWorkerThread. Или надо запустить поток, в который будут переданы тиды двух потоков, которые будут остановлены, а после восстановлены с самовыпилом третьего потока.
Не спорю, решений можно придумать много. Просто интуитивно ожидаешь, что системные функции отлажены. Вот они, значения всех регистров, получены, меняй на здоровье. Установлены тоже будут системной функцией. Плюс, заголовки/функции есть и под x86, и под 64.
И почему нельзя восстановить svn из рабочей копии (при условии, что она не изменена сильно, максимум, +- дневные изменения)?
Я использую GIT поверх SVN для локальных веток при работе над разными тикетами.
Я не спорю — возможно, действительно, есть жуткие косяки, которые мне из-за небольшого опыта не увидеть. Вот и интересно, почему критикуют.
Есть ли что-то типа Windows Internals?
Если я коммичу десяток файлов, измененных для какой-то фичи, я напишу, что сделано (добавлена фича xyz), а не почему. Мало ли почему добавлена… захотелось.
diff тоже не всегда поможет — опустим, одну иконку в hex заменили на другую. Как понять, что где?
Сложно представить, где может не хватит комментария к коммиту, который описывает изменения.
Смысл? Откатить, очевидно, при необходимости.
Последовательно расположенными в физической памяти?
Точнее, я имею в виду, system можно ужать почти до нуля, до примерно 1000 строк. SysInit ужимается до 32. SysUtils просто не подключается.
Но отказаться от system уже не так просто. Хотя и можно.
Не спорю, решений можно придумать много. Просто интуитивно ожидаешь, что системные функции отлажены. Вот они, значения всех регистров, получены, меняй на здоровье. Установлены тоже будут системной функцией. Плюс, заголовки/функции есть и под x86, и под 64.