Честно говоря, думал, что речь пойдет о реальном, а не виртуальном гобане. Многие ценители и знатоки го считают, что без хорошего реального гобана не получится погружения в игру и не будет, соответственно, серьезных успехов.
Вы меня неправильно поняли. Я сам не принадлежу к современному поколению и прекрасно отношусь к фильму «Летят журавли».
Я просто предположил, что доступ к сайтам блокируется из-за того, что туда выкладывают современные киношедевры типа ранеток, на которые распространяется соответствующее законодательство, поэтому становится невозможным посмотреть старые фильмы.
У меня на wheeze apt-get install говорит, что установлена последняя версия bash, хотя файл /bin/bash от 01.01.2013, и простейший тест env X="() { :;} ; echo busted" bash -c "echo stuff" показывает, что уязвимость есть.
Самое трудное для пожилых людей — это найти в интерфейсе ранее незнакомой программы или нового сайта основные элементы управления и навигации, привыкнуть к тому, что одни и те же вещи везде сделаны по разному. Они часто пытаются записать на бумагу последовательность необходимых шагов, а это может помочь только когда пользуешься строго фиксированным набором программ и сайтов.
Смена дизайна сайта — это беда…
В принципе, вы правы, это, в общем случае, более безопасное решение. И развилка на Timeline в случае fork более адекватно описывает ситуацию, чем прямая. Но в реальных ситуациях участники проекта часто работают над малопересекающимися областями и делать каждый раз fork с последующим изучением нового кода и merge — лишние и бесполезные трудозатраты. К тому же при наличии элементарного порядка в организации труда ситуации, когда кто-то, допустим, изменил название переменной, используемой другими, предварительно это не обсудив ни с кем, и даже не предупредив об этом — такие ситуации практически исключены.
Прямого аналога нет. Но того же эффекта можно, наверное, добиться, если вызывать push, pull из bash-скрипта, где предварительно по нужным правилам устанавливать URL — fossil remote-url…
Хотя я, честно говоря, не понял, для чего это нужно и как работает ваша конструкция.
В соответствии с документацией Fossil незавершенная транзакция будет отменена при следующем открытии базы. Такой подход мне кажется более надежным, чем дерево файлов.
Совершенно верно. Процитирую комментарий с stackoverflow:
The fact that there's a tried'n'true transactional database behind every operation makes me sleep better at night. Yes, we've been through more than one horrible incident of stale and corrupt Subversion repositories (thankfully, a helpful community helped us fix them.) I can't imagine that happening in Fossil. Even Subversion 1.7.x use Sqlite now for metadata storage. (Try turning off power in the midst of a git commit — it'll leave a corrupt repos!)
Тот факт, что каждая операция обеспечивается реально транзакционной базой данных, позволяет мне спать спокойно. Мы пережили не один ужасный инцидент, связанный с повреждением хранилищ Subversion (к счастью, сообщество помогло нам справиться с ними ). Я не могу себе представить, чтобы такое случилось с Fossil. Даже Subversion 1.7 использует теперь Sqlite для хранения метаданных. ( Попробуйте выключить питание посреди commit в git — ваш репозитарий будет поврежден! )
Если при записи в одну единственную БД происходит сбой, весь репозиторий накрывается? Как-то подход git на файлах надежнее выглядит.
Необходимость резервного копирования никто не отменял.
Как поведет себя SQLite с базой размером в гигабайт?
Не знаю, не пробовал. Честно говоря, не представляю себе проекта такого размера, если, конечно, большие бинарные файлы в репозиторий не пихать. Учтите к тому же, что Fossil сжимает рабочие файлы. У меня самый большой рабочий каталог исходников — 6 мегабайт с копейками, а соответствующий Fossil репозиторий — чуть больше полутора мегабайт.
Что такое открыть/закрыть репозиторий? Почему закрывать не рекомендуется, зачем тогда эта функция вообще?
В тексте же написано — при открытии создается служебная БД для отслеживания изменений в репозитории. Не рекомендую закрывать — просто чтобы не открывать опять, когда на следующий день возьметесь за работу. Можно ведь и забыть.
Зачем пользователи нужны на локальной машине?
На локальной машине пользователи не нужны. Но ведь при создании репозитория Fossil не знает, будете вы его использовать локально или на сервере.
Разных wiki и багтреккеров over 9000 разных на любой вкус, в т.ч. интегрирующиеся с VCS. Зачем ещё один, жестко прибитый гвоздями к одной VCS?
Ниже все правильно ответили. Добавлю, что в Fossil это работает и на локальном компьютере, для локального репозитория, нет нужды в сторонних сервисах, которые могут отвалиться или изменить свою политку в любой момент.
Почему не автор статьи не рекомендует закрывать я не знаю, так как если я закончил работу, я обычно удаляю рабочие папки, сохраняя их только в репозитории
Для меня репозиторий, все-таки, вспомогательный инструмент и я никогда не удаляю рабочие файлы. А держу открытым — потому что если закрою и забуду опять открыть перед редактированием своих файлов, то придется при последующем открытии говорить ему, чтобы он их не перезаписывал — и если окажусь недостаточно внимателен ( день плохой окажется ), то…
Резюмируя: fossil полезен тем, что у него «всё включено» и идеально подходит для небольших/домашних нужд.
Небольших — понятие относительное. Сам Fossil, да и тот же SQLite вполне благополучно живут на нем. Это, конечно, не очень большие проекты, но и не маленькие.
Я просто предположил, что доступ к сайтам блокируется из-за того, что туда выкладывают современные киношедевры типа ранеток, на которые распространяется соответствующее законодательство, поэтому становится невозможным посмотреть старые фильмы.
Наверное, все-таки, Засурский что-то другое хотел сказать.
env X="() { :;} ; echo busted" bash -c "echo stuff"показывает, что уязвимость есть.Смена дизайна сайта — это беда…
Хотя я, честно говоря, не понял, для чего это нужно и как работает ваша конструкция.
Не знаю, не пробовал. Честно говоря, не представляю себе проекта такого размера, если, конечно, большие бинарные файлы в репозиторий не пихать. Учтите к тому же, что Fossil сжимает рабочие файлы. У меня самый большой рабочий каталог исходников — 6 мегабайт с копейками, а соответствующий Fossil репозиторий — чуть больше полутора мегабайт.
В тексте же написано — при открытии создается служебная БД для отслеживания изменений в репозитории. Не рекомендую закрывать — просто чтобы не открывать опять, когда на следующий день возьметесь за работу. Можно ведь и забыть.
На локальной машине пользователи не нужны. Но ведь при создании репозитория Fossil не знает, будете вы его использовать локально или на сервере.
Ниже все правильно ответили. Добавлю, что в Fossil это работает и на локальном компьютере, для локального репозитория, нет нужды в сторонних сервисах, которые могут отвалиться или изменить свою политку в любой момент.
В том числе и на локальном компьютере для локального же репозитория?
Для меня репозиторий, все-таки, вспомогательный инструмент и я никогда не удаляю рабочие файлы. А держу открытым — потому что если закрою и забуду опять открыть перед редактированием своих файлов, то придется при последующем открытии говорить ему, чтобы он их не перезаписывал — и если окажусь недостаточно внимателен ( день плохой окажется ), то…
Небольших — понятие относительное. Сам Fossil, да и тот же SQLite вполне благополучно живут на нем. Это, конечно, не очень большие проекты, но и не маленькие.
Может, еще не все потеряно.
Беда в том, что просматривает переписку даже не АНБ или ФСБ, а частная компания, предоставляющая сервис.