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