У Cбербанка нашел раздел часто задаваемых вопросов, может кому интересно будет (от 6 апреля 2010 года):
3. Будет ли предоставлена отсрочка по погашению кредита заемщикам, потерявшим работу в связи с мировым финансовым кризисом?
В данный момент Сбербанком России рассматривается вопрос о возможном предоставлении отсрочек по платежам гражданам, попавшим под сокращения. На сегодняшний день вопрос и механизм осуществления данной процедуры еще не решен.
13. Что происходит с неплатежеспособными клиентами по ипотеке?
На самый крайний случай, когда исчерпаны все меры воздействия на неплательщика, у банка остается право обратить взыскание на заложенный объект недвижимости. Средства, вырученные от его продажи, направляются в счет погашения задолженности по кредиту. Если при этом остаются излишки средств, они возвращаются заемщику.
По другим банкам (петрокомерц, втб, газпромбанк, альфа банк) с ходу ответов на подобные вопросы не нашел. Может конечно плохо искал :)
вторник, 6 апреля 2010 г.
вторник, 23 марта 2010 г.
Mercurial и Git
Про них наверное только ленивый не писал, вот и я решил тоже отметиться.
В свое время активно использовал на работе cvs, для контроля изменений на сайте.
На следующей работе использовал perforce и clearcase. На другой работе использовал subversion, затем mercurial, в уме держу git. Надеюсь понятно, что взгляд на системы контроля версий вполне широкий. Да и с утилитами diff, patch очень хорошо знаком.
Во первых, всегда удивляет, что пытаются сравнивать обе системы с svn, cvs, clearcase, но не между собой, когда только между собой их и можно сравнивать. С другими системами просто идеологически нельзя сравнивать. Все остальные не являются распределенными и не зависимыми от сервера. Разве что в плане функциональности сравнивать, где слияние удобнее или еще какие фишки (например, файл конфигурации в clearcase).
Как только вы теряете контакт с сервером вы никто, даже зафиксировать свои изменения не сможете, но в Mercurial и Git можете. И это главное преимущество этих двух систем Mercurial и Git перед всеми остальными.
Пока вы сидите в офисе друг напротив друга, сервачок жужит где-то рядом, все отлично работает в subversion или clearcase, слияние и ответвление, красивые графики в trac, что откуда и куда влилось и вылилось (не без напильника конечно).
Но все это идеально работает до вашей первой командировки в составе команды, когда вечером всей команде срочно требуется править код, так сказать в зависимости от суровых реалий. Когда нет не то что связи с центральным сервером, но даже некогда разбираться с wifi и bluetooth между ноутбуками, а самое верное средство обмена по прежнему флешка.
Причем subversion очень любит запоминать ip адрес сервера и даже простое вливание дампа репозитория сервера на новое место(ноутбук) не поможет, пока не зальете исходники с нового сервера(который встал на ноутбук). В результате, только какой нить merge по локальным файлам и помогает. А по приезду обратно, все начинают мучительно вливать килотонны своих изменений в subversion попутно вспоминая, что же за неделю было сделано и зачем.
Вот после пары, тройки таких командировок стал интересоваться Mercurial, но использовать стал много позже.
Во вторых, Mercurial на момент нашего интереса был более развит под windows, чем Git, сейчас у Git с этим тоже уже нет проблем. Но хочется отметить отличия. Mercurial в основном написан на Python с мелкими вкраплениями на C. В отличие от Git, который целиком написан на с и имеет много зависимостей с архитектурой linux, иначе бы не отвязывали так долго. Соответственно установить mercurial на хостинге с существующим python проще. Но Git в хороших традициях linux/unix состоит из набора консольных программ, чтобы их можно было легко использовать в скриптах на bash, tcl/tk. Соответственно, с Mercurial интереснее взаимодействовать через python, а с Git через обычный ввод/вывод.
В третьих, собственно интерес к Git был однажды снова подогрет после прочтения презентации про Git Линусом Торвальдсом и сравнения двух этих систем на code.google.com.
В качестве фишки, которой меня манил Git, был индекс похожести (similarity index). Дело все в том, что Git ведет не историю отдельных файлов, а сразу историю всех изменений в файловой системе в целом. Если вы переименуете один файл в другой, то Git это легко найдет, так как хэш sha1 двух файлов будет один и тот же, только изменится название файла. Это весьма важная вещь, знать откуда у тебя на самом деле взялся файл, особенно, если он был копией другого уже существующего файла (это конечно можно сделать административно :D).
Но как известно хотелось большего. Цитирую из презентации: "Одно из особенных свойств git — отслеживание изменений всего содержимого, и это отличает git даже от Mercurial, несмотря на то, что они очень похожи. "
В общем, в тайне надеялся, что в Git реализовано отслеживание перемещения кусков кода из одного файла в другой или их размножение путем копирования в рамках одного файла. То есть, увидеть, что какой-то кусок кода был взят из другого проекта, и потом немного исправлен. Я понимаю, несколько утопично, особенно если представить, что for копируется везде где только можно, с легкими изменениями в рамках одной строки :D.
Но увы моя мечта не сбылась, все что удалось добиться сейчас от Git, так это то, что Git может показать, что файл с такой-то вероятностью является копией другого файла, так как его после копирования изменили до неузнаваемости. Да и то для этого надо передать серию волшебных ключиков.
Это максимум что удалось добиться. Кстати, чтобы git легко находил копии файлов рекомендуется на каждый чих делать фиксацию изменений, иначе копию можно изменить до не узнаваемости :D на момент фиксации.
Сейчас я считаю утопичным мое желание, так как оно мне в общем-то ничего не дает, и заодно сильно усложняет сам git, так как задача поиска одинаковых кусков кода по исходникам весьма не простая.
Во всяком случае видеть ее реализацию хотелось бы пожалуй уже немного в другой форме. Например, в утилите blame, когда по участку кода, можно было бы попросить найти, то место откуда код был взят, а не только кто автор. Чтобы проследить эволюцию кода. Также хотелось бы видеть эволюцию кода не только вниз но и вверх, может мою функцию кто нибудь у себя улучшил, а я не знаю, или наоборот в коде предке уже ошибку исправили, а я все еще пользуюсь старой копией ошибочного кода из другого проекта (по идее такоей код надо выделить в подпроекты).
В последних, хотелось бы обратить внимание на то, что Mercurial больше подходит для не больших проектов, к тому же он в самом деле проще в освоении, чем Git в котором только для того, чтобы научиться просмотреть изменения, мне понадобилось перечитать кучу документации и потратить уйму времени, не менее часа. Но Git предоставляет достаточно много опций и утилит облегчающих контроль большого проекта.
Например, способ с помощью которого легко найти проблемный commit, который испортил сборку всего проекта не проверяя каждый commit в отделььности, а лишь только сообщая какой из тысячи commit-ов после теста оказался проблемным или не проблемным. Не простая задача, и таких мелочей в Git много.
Например, возможность добавления в уже зафиксированное изменение забытых файлов, которые вы просто забыли добавить, не создавать же для этого в репозитории отдельное изменение.
В свое время активно использовал на работе cvs, для контроля изменений на сайте.
На следующей работе использовал perforce и clearcase. На другой работе использовал subversion, затем mercurial, в уме держу git. Надеюсь понятно, что взгляд на системы контроля версий вполне широкий. Да и с утилитами diff, patch очень хорошо знаком.
Во первых, всегда удивляет, что пытаются сравнивать обе системы с svn, cvs, clearcase, но не между собой, когда только между собой их и можно сравнивать. С другими системами просто идеологически нельзя сравнивать. Все остальные не являются распределенными и не зависимыми от сервера. Разве что в плане функциональности сравнивать, где слияние удобнее или еще какие фишки (например, файл конфигурации в clearcase).
Как только вы теряете контакт с сервером вы никто, даже зафиксировать свои изменения не сможете, но в Mercurial и Git можете. И это главное преимущество этих двух систем Mercurial и Git перед всеми остальными.
Пока вы сидите в офисе друг напротив друга, сервачок жужит где-то рядом, все отлично работает в subversion или clearcase, слияние и ответвление, красивые графики в trac, что откуда и куда влилось и вылилось (не без напильника конечно).
Но все это идеально работает до вашей первой командировки в составе команды, когда вечером всей команде срочно требуется править код, так сказать в зависимости от суровых реалий. Когда нет не то что связи с центральным сервером, но даже некогда разбираться с wifi и bluetooth между ноутбуками, а самое верное средство обмена по прежнему флешка.
Причем subversion очень любит запоминать ip адрес сервера и даже простое вливание дампа репозитория сервера на новое место(ноутбук) не поможет, пока не зальете исходники с нового сервера(который встал на ноутбук). В результате, только какой нить merge по локальным файлам и помогает. А по приезду обратно, все начинают мучительно вливать килотонны своих изменений в subversion попутно вспоминая, что же за неделю было сделано и зачем.
Вот после пары, тройки таких командировок стал интересоваться Mercurial, но использовать стал много позже.
Во вторых, Mercurial на момент нашего интереса был более развит под windows, чем Git, сейчас у Git с этим тоже уже нет проблем. Но хочется отметить отличия. Mercurial в основном написан на Python с мелкими вкраплениями на C. В отличие от Git, который целиком написан на с и имеет много зависимостей с архитектурой linux, иначе бы не отвязывали так долго. Соответственно установить mercurial на хостинге с существующим python проще. Но Git в хороших традициях linux/unix состоит из набора консольных программ, чтобы их можно было легко использовать в скриптах на bash, tcl/tk. Соответственно, с Mercurial интереснее взаимодействовать через python, а с Git через обычный ввод/вывод.
В третьих, собственно интерес к Git был однажды снова подогрет после прочтения презентации про Git Линусом Торвальдсом и сравнения двух этих систем на code.google.com.
В качестве фишки, которой меня манил Git, был индекс похожести (similarity index). Дело все в том, что Git ведет не историю отдельных файлов, а сразу историю всех изменений в файловой системе в целом. Если вы переименуете один файл в другой, то Git это легко найдет, так как хэш sha1 двух файлов будет один и тот же, только изменится название файла. Это весьма важная вещь, знать откуда у тебя на самом деле взялся файл, особенно, если он был копией другого уже существующего файла (это конечно можно сделать административно :D).
Но как известно хотелось большего. Цитирую из презентации: "Одно из особенных свойств git — отслеживание изменений всего содержимого, и это отличает git даже от Mercurial, несмотря на то, что они очень похожи. "
В общем, в тайне надеялся, что в Git реализовано отслеживание перемещения кусков кода из одного файла в другой или их размножение путем копирования в рамках одного файла. То есть, увидеть, что какой-то кусок кода был взят из другого проекта, и потом немного исправлен. Я понимаю, несколько утопично, особенно если представить, что for копируется везде где только можно, с легкими изменениями в рамках одной строки :D.
Но увы моя мечта не сбылась, все что удалось добиться сейчас от Git, так это то, что Git может показать, что файл с такой-то вероятностью является копией другого файла, так как его после копирования изменили до неузнаваемости. Да и то для этого надо передать серию волшебных ключиков.
git diff --find-copies-harder --pickaxe-all --color HEAD~2 diff --git a/6.txt b/10.txt similarity index 80% copy from 6.txt copy to 10.txt index f8e89fb..cf9ebe7 100644 --- a/6.txt +++ b/10.txt @@ -1,3 +1,4 @@ +888 111 222 333 @@ -5,4 +6,3 @@ 555 666 777 -888 diff --git a/7.txt b/7.txt new file mode 100644 index 0000000..1bfd9c2 --- /dev/null +++ b/7.txt @@ -0,0 +1,5 @@ +111 +222 +333 +444 + diff --git a/8.txt b/8.txt new file mode 100644 index 0000000..92263e5 --- /dev/null +++ b/8.txt @@ -0,0 +1,5 @@ +444 +555 +666 +777 +888 diff --git a/6.txt b/9.txt similarity index 80% copy from 6.txt copy to 9.txt index f8e89fb..cf9ebe7 100644 --- a/6.txt +++ b/9.txt @@ -1,3 +1,4 @@ +888 111 222 333 @@ -5,4 +6,3 @@ 555 666 777 -888
Это максимум что удалось добиться. Кстати, чтобы git легко находил копии файлов рекомендуется на каждый чих делать фиксацию изменений, иначе копию можно изменить до не узнаваемости :D на момент фиксации.
Сейчас я считаю утопичным мое желание, так как оно мне в общем-то ничего не дает, и заодно сильно усложняет сам git, так как задача поиска одинаковых кусков кода по исходникам весьма не простая.
Во всяком случае видеть ее реализацию хотелось бы пожалуй уже немного в другой форме. Например, в утилите blame, когда по участку кода, можно было бы попросить найти, то место откуда код был взят, а не только кто автор. Чтобы проследить эволюцию кода. Также хотелось бы видеть эволюцию кода не только вниз но и вверх, может мою функцию кто нибудь у себя улучшил, а я не знаю, или наоборот в коде предке уже ошибку исправили, а я все еще пользуюсь старой копией ошибочного кода из другого проекта (по идее такоей код надо выделить в подпроекты).
В последних, хотелось бы обратить внимание на то, что Mercurial больше подходит для не больших проектов, к тому же он в самом деле проще в освоении, чем Git в котором только для того, чтобы научиться просмотреть изменения, мне понадобилось перечитать кучу документации и потратить уйму времени, не менее часа. Но Git предоставляет достаточно много опций и утилит облегчающих контроль большого проекта.
Например, способ с помощью которого легко найти проблемный commit, который испортил сборку всего проекта не проверяя каждый commit в отделььности, а лишь только сообщая какой из тысячи commit-ов после теста оказался проблемным или не проблемным. Не простая задача, и таких мелочей в Git много.
Например, возможность добавления в уже зафиксированное изменение забытых файлов, которые вы просто забыли добавить, не создавать же для этого в репозитории отдельное изменение.
среда, 17 февраля 2010 г.
SynchroTron TiddlyWiki или распределенная совместная работа с wiki без сервера почти как в Mercurial или Git
Недавно подсел на TiddlyWiki, wiki которой не нужен сервер, php, базы данных, нужен только клиент в виде браузера IE6.0 и выше, Firefox-1.5 и выше.
Опишу кратенько фишки, которые мне понравились:
1) не нужен сервер, только браузер;
2) все в одном html файле c javascript в нем же;
3) можно указать адрес другой TiddlyWiki сиcтемы, просмотреть список всех статей и плагинов, выбрать нужные и импортировать к себе в вашу локальную wiki;
4) большое количество разномастных плагинов.
И фишки, которые не понравились:
1) все в одном файле, как следствие пухнет, но есть плагин, который позволяет раскидать статьи по нескольким html файлам (в файлах должна быть таже TiddlyWiki), с загрузкой данных из них по требованию, сам не пробовал, но как решение данного недостатка думаю в самый раз;
2) некоторые вещи связанные с интерфейсом, но это все изменяемо.
Использовать ее удобно как wiki описание к проекту. Вы кладете html файл к вашим исходниками, можете закинуть даже в систему контроля версий и получаете wiki систему в которой можете описывать ваш проект, вести его и так далее. На мой взгляд, то что надо. И для этого не надо ставить Apache+Python|PHP|Perl+SQLite|MySQL|PostgreSQL и быть привязанным к серверу, как коза веревкой к колу.
Но мне этого показалось мало, в последнее время я немного был увлечен распределенными системами контроля версий Mercurial и Git. И думал, как бы было удобно, если бы эта wiki имела интеграцию с ними. Я имею ввиду для отслеживания изменений в самой wiki, а не для вывода состояния репозитория в Mercurial или Git как в Trac, и при этом иметь такое же удобство ведения ответвлений как в этих системах.
Я быстренько это дело по-google-ил, и случайно нашел нечто немного другое, но оказавшееся тем, что фактически я и искал.
Наткнулся я на проект SynchroTron (скачать, описание) - Javascript библиотека позволяющая вам осуществить diff, diff3, merge и контроль версий прямо на javascript от вот этой замечательной компании Osmosoft. Кстати, они разрабатывают проект TiddlyWeb, основная задача которого обеспечить доступ к TiddlyWiki через удобное HTTP API, серверная часть там реализована на Python. Мне эта часть была не особо нужна, но раз ее уже придумали, то просто отлично и это еще один повод позаниматься TiddlyWiki подробнее.
Но я отвлекся, суть работы diff на javascript в том, что вы передаете пару фрагментов текста, вызываете diff и получаете различия в виде json массива:
Кстати у google в этом плане оказывается тоже есть наработки и думаю если поискать внимательно на sf.net, то парочка еще точно найдется.
Дальше больше, эту тему они развили здесь Diff for Javascript, revisited, где json массив стал походить не на обычный побуквенный diff, а на вывод в формате patch, в котором указывается также смещение и длинна измененного текста, такой вариант уже будет легко приспособить, чтобы покрасить нужные буквы в нужный цвет при отображении разницы одного текста от другого, вот пример ответа:
Но на этом они не остановились, они реализовали merge, теперь в json находится померженный текст, с указанием конфликтных мест слияния:
Грубо говоря, они создали весьма удобные в использовании функции. Кстати снова не забудем google, ведь у них тоже есть нечто подобное.
Там же вы найдете презентацию Distributed Version Control in JavaScript or any other language that takes your fancy. Tony Garnock-Jones tonyg@lshift.net
LShift Ltd.
в которой присутствуют работающие ссылки на демо страницы.
Думаю те кто использует Mercurial или Git взглянув на следующий скриншот сильно заинтересуются, увидев знакомые ветвистые деревья, есть некоторое сходство :D, но есть разница. Все это на javascript.
Другими словами, в SynchroTron они сделали систему контроля версий на Javascript, которая управляет наборами JSON структур (файлов же нет на javascript :)). Все что я здесь указал кратенько там рассказано, только по английски. Так же там указаны javascript библиотеки, которые они использовали для реализации той иной задачи, думаю это любопытно для тех кто пишет на javascript.
В результате всего этого я все таки наткнулся также на следующую статью: Adding distributed version control to TiddlyWiki, тут у меня задражали пальцы при наборе ссылки, неужели все это дело они уже успели еще до кучи впихнуть в TiddlyWiki? В общем так оно и случилось :)
Добро пожаловать на SynchroTron TiddlyWiki.
Cамое интересное вы увидите на вкладке Versions, которую надо выбрать, она справа от центра.
На следующем рисунке
вы увидите дерево ревизий. Выбрав checkout на одной из ревизии вы увидите, что содержимое статей в wiki изменяется, а также изменяется и состав статей. Дерево отсортировано всегда хронологически.
Самые пытливые заметят пункт Merge и слияние двух веток в одной ревизии. Да, да, да! Это банальное слияние состояний вашей wiki.
Но самые пытливые из пытливых отметят еще и пункт Import! С его помощью вы можете указать другую локальную TiddlyWiki, откуда вы можете импортировать новые и возможно даже измененные существующие уже в вашей TiddlyWiki статьи. После импорта у вас появится ответвление, с которым вы можете смержиться.
Все отличающиеся не конфликтные статьи просто изменяться, а все конфликтные откроются и будет предложено исправить все конфликты вручную, но ведь это wiki, править надо именно wiki текст, а не голый html!
На следующем рисунке вы увидите результат моего эксперимента по импорту статей из второй wiki в первую. Вторая wiki, ранее была создана копированием из первой, потом в первой и второй wiki в строке 222 и 555 в первой и второй теме соответственно были изменены цифры (в 1-й wiki на 7, а во 2-й wiki на 8), чтобы получить конфликт при слиянии сразу в двух темах. На рисунке вы собственно видите, предложение поправить конфликт после импорта первой и второй темы из второй wiki в первую.
Чтобы воспользовваться этим в своей TiddlyWiki достаточно у себя выбрать пункт import указать адрес http://hg.opensource.lshift.net/synchrotron/raw-file/default/tiddlywiki/tiddlydvcs.html и импортировать к себе все пункты, после чего вкладка Versions появится и у вас :) И вы получите wiki движок с распределенной системой контроля версий wiki в одном флаконе и для работы с ним нужен только браузер, а для обмена статьями в таком случае, только html файл c изменившимися статьями.
Совсем недавно наткнулся на еще одну статью полностью на английском языке про это же самое, но только собрано все на одной странице и конкретизировано.
Опишу кратенько фишки, которые мне понравились:
1) не нужен сервер, только браузер;
2) все в одном html файле c javascript в нем же;
3) можно указать адрес другой TiddlyWiki сиcтемы, просмотреть список всех статей и плагинов, выбрать нужные и импортировать к себе в вашу локальную wiki;
4) большое количество разномастных плагинов.
И фишки, которые не понравились:
1) все в одном файле, как следствие пухнет, но есть плагин, который позволяет раскидать статьи по нескольким html файлам (в файлах должна быть таже TiddlyWiki), с загрузкой данных из них по требованию, сам не пробовал, но как решение данного недостатка думаю в самый раз;
2) некоторые вещи связанные с интерфейсом, но это все изменяемо.
Использовать ее удобно как wiki описание к проекту. Вы кладете html файл к вашим исходниками, можете закинуть даже в систему контроля версий и получаете wiki систему в которой можете описывать ваш проект, вести его и так далее. На мой взгляд, то что надо. И для этого не надо ставить Apache+Python|PHP|Perl+SQLite|MySQL|PostgreSQL и быть привязанным к серверу, как коза веревкой к колу.
Но мне этого показалось мало, в последнее время я немного был увлечен распределенными системами контроля версий Mercurial и Git. И думал, как бы было удобно, если бы эта wiki имела интеграцию с ними. Я имею ввиду для отслеживания изменений в самой wiki, а не для вывода состояния репозитория в Mercurial или Git как в Trac, и при этом иметь такое же удобство ведения ответвлений как в этих системах.
Я быстренько это дело по-google-ил, и случайно нашел нечто немного другое, но оказавшееся тем, что фактически я и искал.
Наткнулся я на проект SynchroTron (скачать, описание) - Javascript библиотека позволяющая вам осуществить diff, diff3, merge и контроль версий прямо на javascript от вот этой замечательной компании Osmosoft. Кстати, они разрабатывают проект TiddlyWeb, основная задача которого обеспечить доступ к TiddlyWiki через удобное HTTP API, серверная часть там реализована на Python. Мне эта часть была не особо нужна, но раз ее уже придумали, то просто отлично и это еще один повод позаниматься TiddlyWiki подробнее.
Но я отвлекся, суть работы diff на javascript в том, что вы передаете пару фрагментов текста, вызываете diff и получаете различия в виде json массива:
diff("the quick brown fox jumped over".split(/\s+/), "the quick fox jumps over".split(/\s+/))
[{common:["the","quick"]}, {file1:["brown"], file2:[]}, {common:["fox"]}, {file1:["jumped"], file2:["jumps"]}, {common:["over"]}]
Кстати у google в этом плане оказывается тоже есть наработки и думаю если поискать внимательно на sf.net, то парочка еще точно найдется.
Дальше больше, эту тему они развили здесь Diff for Javascript, revisited, где json массив стал походить не на обычный побуквенный diff, а на вывод в формате patch, в котором указывается также смещение и длинна измененного текста, такой вариант уже будет легко приспособить, чтобы покрасить нужные буквы в нужный цвет при отображении разницы одного текста от другого, вот пример ответа:
[{file1:{offset:2, length:1, chunk:["brown"]}, file2:{offset:2, length:0, chunk:[]}}, {file1:{offset:4, length:1, chunk:["jumped"]}, file2:{offset:3, length:1, chunk:["jumps"]}}, {file1:{offset:6, length:1, chunk:["a"]}, file2:{offset:5, length:2, chunk:["some", "lazy"]}}]
Но на этом они не остановились, они реализовали merge, теперь в json находится померженный текст, с указанием конфликтных мест слияния:
js> uneval(Diff.diff3_merge(derived1, base, derived2, true)); [{ok:["the", "quick", "fox", "jumps", "over"]}, {conflict:{a:["some", "lazy"], aIndex:5, o:["a"], oIndex:6, b:["some", "record"], bIndex:6}}, {ok:["dog"]}]
Грубо говоря, они создали весьма удобные в использовании функции. Кстати снова не забудем google, ведь у них тоже есть нечто подобное.
Там же вы найдете презентацию Distributed Version Control in JavaScript or any other language that takes your fancy. Tony Garnock-Jones tonyg@lshift.net
LShift Ltd.
в которой присутствуют работающие ссылки на демо страницы.
Diff Demo | LShift Ltd. Google |
Diff3 or Merge Demo | LShift Ltd. Google |
DVCS Demo | LShift Ltd. Google (?oops) |
Думаю те кто использует Mercurial или Git взглянув на следующий скриншот сильно заинтересуются, увидев знакомые ветвистые деревья, есть некоторое сходство :D, но есть разница. Все это на javascript.
 |
| Альбом: Все или ничего (The Longest Yard) |
Другими словами, в SynchroTron они сделали систему контроля версий на Javascript, которая управляет наборами JSON структур (файлов же нет на javascript :)). Все что я здесь указал кратенько там рассказано, только по английски. Так же там указаны javascript библиотеки, которые они использовали для реализации той иной задачи, думаю это любопытно для тех кто пишет на javascript.
В результате всего этого я все таки наткнулся также на следующую статью: Adding distributed version control to TiddlyWiki, тут у меня задражали пальцы при наборе ссылки, неужели все это дело они уже успели еще до кучи впихнуть в TiddlyWiki? В общем так оно и случилось :)
Добро пожаловать на SynchroTron TiddlyWiki.
Cамое интересное вы увидите на вкладке Versions, которую надо выбрать, она справа от центра.
На следующем рисунке
 |
| Альбом: Все или ничего (The Longest Yard) |
вы увидите дерево ревизий. Выбрав checkout на одной из ревизии вы увидите, что содержимое статей в wiki изменяется, а также изменяется и состав статей. Дерево отсортировано всегда хронологически.
Самые пытливые заметят пункт Merge и слияние двух веток в одной ревизии. Да, да, да! Это банальное слияние состояний вашей wiki.
Но самые пытливые из пытливых отметят еще и пункт Import! С его помощью вы можете указать другую локальную TiddlyWiki, откуда вы можете импортировать новые и возможно даже измененные существующие уже в вашей TiddlyWiki статьи. После импорта у вас появится ответвление, с которым вы можете смержиться.
Все отличающиеся не конфликтные статьи просто изменяться, а все конфликтные откроются и будет предложено исправить все конфликты вручную, но ведь это wiki, править надо именно wiki текст, а не голый html!
На следующем рисунке вы увидите результат моего эксперимента по импорту статей из второй wiki в первую. Вторая wiki, ранее была создана копированием из первой, потом в первой и второй wiki в строке 222 и 555 в первой и второй теме соответственно были изменены цифры (в 1-й wiki на 7, а во 2-й wiki на 8), чтобы получить конфликт при слиянии сразу в двух темах. На рисунке вы собственно видите, предложение поправить конфликт после импорта первой и второй темы из второй wiki в первую.
 |
| Альбом: Все или ничего (The Longest Yard) |
Чтобы воспользовваться этим в своей TiddlyWiki достаточно у себя выбрать пункт import указать адрес http://hg.opensource.lshift.net/synchrotron/raw-file/default/tiddlywiki/tiddlydvcs.html и импортировать к себе все пункты, после чего вкладка Versions появится и у вас :) И вы получите wiki движок с распределенной системой контроля версий wiki в одном флаконе и для работы с ним нужен только браузер, а для обмена статьями в таком случае, только html файл c изменившимися статьями.
Совсем недавно наткнулся на еще одну статью полностью на английском языке про это же самое, но только собрано все на одной странице и конкретизировано.
среда, 10 февраля 2010 г.
Видеозапись семинаров
Посмотрел тут на видео одного из семинаров, не буду говорить на какую тему, но без слез не взглянешь, уж лучше бы просто выложили электронные презентации, чем так позорится. Люди, не надо позволять себя снимать на вашей первой презентации. Думаю, что только человек проведший не один семинар на ту же самую тему может достойно выступить и рассказать внятно свою тему. Остальное, не подготовленные семинары ни на ком не опробованные.
пятница, 5 февраля 2010 г.
О памяти
Мне кажется, что мысли так редко приходящие мне в голову, забываются со вренем лишь только потому, что они не сгруппированы, не приводят к какой-то завершенной большой и изящной, четко оформленной мысли или суждению о предмете. То есть, набор ни с чем не связанных мыслей подобен хаосу, который просто невозможно не забыть. Может поэтому свои мысли стоит записывать.
среда, 22 июля 2009 г.
Мониторинг сайтов
Нашел сервис http://host-tracker.com/ru , который проверяет доступность сайта из разных регионов мира, в отчете приводится время доступа, скорость, регион, ip, последний параметр похоже показывает в какой ip адрес ваш сайт разыменуется местными dns серверами. Для меня было удивительным, что в Санкт-Петербурге один сайт ссылался на совершенно другой ip адрес, а это значит где-то ошибка и клиенты могут не достучаться именно до вашего сайта, а попадут на какой-то подложный.
Выглядит это все так
Еще нашел наш российский http://monitoring24.ru, который позволяет в отличии от предыдущего сервиса проверять не 2 сайта бесплатно, а уже 5.
Выглядит это все так
Еще нашел наш российский http://monitoring24.ru, который позволяет в отличии от предыдущего сервиса проверять не 2 сайта бесплатно, а уже 5.
вторник, 5 мая 2009 г.
Новый грипп?
Во время прочтения различных блогов не могу не дать ссылку на одну статью из блога DOWNLOADSQUAD Swine flu, там перечислены ссылки на некоторые ресурсы, которые могут быть интересными по данной тематике.
В частности: официальные сайты, новостные сайты, географические карты распространения, сайты с видео и другими мультемидийными материалами и другие.
Лично мне из всех приглянулся сайт Глобальная карта визуализации вспышек. Только там визуализируются не сами вспышки, а упоминания о них в интернет с привязкой по местности используя различные поисковики, например Google News.
В частности: официальные сайты, новостные сайты, географические карты распространения, сайты с видео и другими мультемидийными материалами и другие.
Лично мне из всех приглянулся сайт Глобальная карта визуализации вспышек. Только там визуализируются не сами вспышки, а упоминания о них в интернет с привязкой по местности используя различные поисковики, например Google News.
Подписаться на:
Сообщения (Atom)
Сообщения
