Блог компании Evernote Corporation → Новые премиум-возможности: история версий и 50 мегабайт на заметку
Начиная с сегодняшнего дня у премиум-аккаунта Evernote в дополнение к уже существовующим возможностям появилось еще две новых функции: история заметок и увеличенный максимальный объем заметки.
Новая возможность: история заметки (она же контроль версий)
Теперь Evernote делает копии ваших заметок и их содержимого. Несколько раз в день Evernote проверяет, не было ли внесено изменений в какие-нибудь из них. Если обнаружены модифицированные заметки, Evernote делает новую копию этих заметок и добавляет их в историю, которая хранится на наших серверах. Таким образом в премиум-аккаунте теперь ведется история по каждой из ваших заметок. Никаких ограничений на количество копий нет, а старые версии не влияют на вашу ежемесячную квоту на новые заметки.
Новая возможность: история заметки (она же контроль версий)
Теперь Evernote делает копии ваших заметок и их содержимого. Несколько раз в день Evernote проверяет, не было ли внесено изменений в какие-нибудь из них. Если обнаружены модифицированные заметки, Evernote делает новую копию этих заметок и добавляет их в историю, которая хранится на наших серверах. Таким образом в премиум-аккаунте теперь ведется история по каждой из ваших заметок. Никаких ограничений на количество копий нет, а старые версии не влияют на вашу ежемесячную квоту на новые заметки.
Разработка → DVCS and DAGs
Перевод статьи Эрика Синка (Eric Sink) — DVCS and DAGs (Part 1 and Part 2).
Прим. переводчика: В этой статье я буду использовать оригинальные англоязычные сокращения DVCS и DAG для обозначения распределённых систем контроля версий (Distributed Version Control System — DVCS) и направленных ацикличных графов (Directed Acyclic Graph — DAG).
Прим. переводчика: В этой статье я буду использовать оригинальные англоязычные сокращения DVCS и DAG для обозначения распределённых систем контроля версий (Distributed Version Control System — DVCS) и направленных ацикличных графов (Directed Acyclic Graph — DAG).
Персональные блоги → Аудит системы контроля версий, ч. I
Необходимо регулярно сверять устройство вашей системы контроля версий с
реальностью процесса разработки и внедрения. В этом документе мы постараемся
изложить краткую схему вопросов, на которые необходимо ответить, чтобы
высветить недостатки и потенциальные проблемы в вашей системе.
Для анализа нам потребуется описание структуры веток, список участников
процесса и область их ответственности, описание потоков изменений. Для
наглядности можно попробовать нарисовать пару диаграмм: граф потоков изменений
по веткам и древовидную структуру потока, развернутую во времени. Мы считаем
более важным (и более простым) первый график, тогда как традиционно во многих
текстах по системам контроля версий используется второй, не так чётко
высвечивающий структуру.
В этом документе описывается только анализ системы. Способы решения проблем,
выявленных при анализе, будут обсуждаться отдельно.
реальностью процесса разработки и внедрения. В этом документе мы постараемся
изложить краткую схему вопросов, на которые необходимо ответить, чтобы
высветить недостатки и потенциальные проблемы в вашей системе.
Для анализа нам потребуется описание структуры веток, список участников
процесса и область их ответственности, описание потоков изменений. Для
наглядности можно попробовать нарисовать пару диаграмм: граф потоков изменений
по веткам и древовидную структуру потока, развернутую во времени. Мы считаем
более важным (и более простым) первый график, тогда как традиционно во многих
текстах по системам контроля версий используется второй, не так чётко
высвечивающий структуру.
В этом документе описывается только анализ системы. Способы решения проблем,
выявленных при анализе, будут обсуждаться отдельно.
Разработка → Установка и настройка SVN (сервер+клиент)
По просьбам трудящихся, а так же учитывая, что есть статья по установке SVN (правда +Trac) под Linux, решил написать краткое описание установки и настройки SVN для Windows.Ничего нового для людей, хорошо знающих и работающих с SVN, здесь не будет. Цель статьи — помочь некоторому проценту новичков, пребывающих на Хабре, таки осилить изучение этой системы контроля версий.
.NET → Средства коллективной разработки.
Всем хорошего вечера понедельника (если такое возможно). Хочу спросить у тех кто пишет под .NET платформу, какие средства коллективной разработки они используют? Понятно что есть VS Team systems. Все ли используют его? Может кто-то пользуется чем нить альтернативным? Чем-то полегче?
Веб-разработка → Коллективная работа над сайтом
Не все сайты делаются студией и после отдаются заказчику.
Бывает, что сложные сайты портального типа развиваются поэтапно,
часть доступна в онлайн, другая в стадии разработки,
причем в достаточно крупных проектах над сайтом могут работать несколько почти независимых групп.
Тут и без бинокля видно, что неплохо бы использовать для хранения php и html кода репозиторий.
Но как это сделать правильней?
С дизайнерами и программистами все достаточно просто, они разрабатывают код на локальных машинах и изменения вносят в репозиторий. Можно даже настроить cron, чтобы периодически последние изменения из репозитория выкладывались на online сайт.
Но как быть с контентом?
Контент меняется только на online версии, чтобы не усложнять дело синхронизацией данных из разных БД. Но не весь контент хранится в базе, часто CMS контент статических страниц хранят в .php файлах, из-за чего появляются новые файлы и изменения, которые приходится периодически с "online" переносить в репозиторий, и делать это вручную во избежание конфликтов версий.
Интересно, кто сталкивался и как решал подобные задачи.
Бывает, что сложные сайты портального типа развиваются поэтапно,
часть доступна в онлайн, другая в стадии разработки,
причем в достаточно крупных проектах над сайтом могут работать несколько почти независимых групп.
Тут и без бинокля видно, что неплохо бы использовать для хранения php и html кода репозиторий.
Но как это сделать правильней?
С дизайнерами и программистами все достаточно просто, они разрабатывают код на локальных машинах и изменения вносят в репозиторий. Можно даже настроить cron, чтобы периодически последние изменения из репозитория выкладывались на online сайт.
Но как быть с контентом?
Контент меняется только на online версии, чтобы не усложнять дело синхронизацией данных из разных БД. Но не весь контент хранится в базе, часто CMS контент статических страниц хранят в .php файлах, из-за чего появляются новые файлы и изменения, которые приходится периодически с "online" переносить в репозиторий, и делать это вручную во избежание конфликтов версий.
Интересно, кто сталкивался и как решал подобные задачи.
Персональные блоги → Subversion: чеклист по правильным коммитам
Предполагаем, что читатель: а) работает в коллективе; и б) осознал необходимость правильной работы с системами контроля версий или хотя бы поставлен перед необходимостью использовать таковую.
В примерах будет использоваться Subversion, хотя все рекомендации полностью применимы к любой другой системе контроля версий.
Грубо разделим фазы разработки проекта на три — дебют, миттельшпиль и эндшпиль.
В дебюте новый код пишется огромными кусками, зачастую целые куски системы переносятся с места на место. Релиз далеко, никаких особых требований к общему состоянию системы нет. Допустимо даже разламывать систему до некоторых пределов.
В миттельшпиле система в целом стабилизировалась, продукт близится к релизу. Рефакторинг более чёткий, хотя и иногда достаточно обширный. На этом этапе ожидается уже, что система в целом работает — по крайней мере, сломанный репозиторий порицается.
Наконец, в эндшпиль система переходит непосредственно перед релизом и сразу после. Для веб-приложений постоянно добавляются новые относительно небольшие возможности, а крупные изменения сначала тестируются на ветках. Для более традиционных приложений наоборот, создаётся ветка для maintenance релизов, а разработка следующей большой версии продолжается на стволе.
В примерах будет использоваться Subversion, хотя все рекомендации полностью применимы к любой другой системе контроля версий.
Грубо разделим фазы разработки проекта на три — дебют, миттельшпиль и эндшпиль.
В дебюте новый код пишется огромными кусками, зачастую целые куски системы переносятся с места на место. Релиз далеко, никаких особых требований к общему состоянию системы нет. Допустимо даже разламывать систему до некоторых пределов.
В миттельшпиле система в целом стабилизировалась, продукт близится к релизу. Рефакторинг более чёткий, хотя и иногда достаточно обширный. На этом этапе ожидается уже, что система в целом работает — по крайней мере, сломанный репозиторий порицается.
Наконец, в эндшпиль система переходит непосредственно перед релизом и сразу после. Для веб-приложений постоянно добавляются новые относительно небольшие возможности, а крупные изменения сначала тестируются на ветках. Для более традиционных приложений наоборот, создаётся ветка для maintenance релизов, а разработка следующей большой версии продолжается на стволе.
Персональные блоги → Дайджест на тему «Системы контроля версий»
В марте 2007 года в США случился политический скандал: никому не понятным образом в и без того одиозный Patriot Act были внесены изменения, позволяющие президенту США единолично увольнять федеральных прокуроров. Оказывается, ничего не подозревающие конгрессмены проголосовали за целую кучу поправок "пачкой", не осознавая, что среди них находится настоящая "бомба". Два абзаца были удалены, и добавлен один новый, и всё это произошло буквально за несколько дней до голосования, без уведомления, без обоснования, без оповещения заинтересованных лиц.
В кратчайшие сроки после введения этой поправки семеро федеральных прокуроров были уволены. Отголоски этого решения в американской политической картине чувствуются до сих пор.
Американские гики во главе с Тимом О'Рилли и Карлом Фогелем (первый: владелец небезызвестного издательства, второй: ведущий разработчик Subversion) призывают законодательные власти Америки к введению полноценной системы контроля версий, позволяющей предотвратить возможность повторения подобных инцидентов.
* * *
Блог "Better Explained" в кратчайшие сроки завоевал мегатонну человеческого внимания, опубликовав два чарующе прекрасных с визуальной точки зрения описания систем контроля версий.
* * *
А также:
В кратчайшие сроки после введения этой поправки семеро федеральных прокуроров были уволены. Отголоски этого решения в американской политической картине чувствуются до сих пор.
Американские гики во главе с Тимом О'Рилли и Карлом Фогелем (первый: владелец небезызвестного издательства, второй: ведущий разработчик Subversion) призывают законодательные власти Америки к введению полноценной системы контроля версий, позволяющей предотвратить возможность повторения подобных инцидентов.
Источники:
а) Tim O'Reilly: "Why Congress Needs a Version Control System"
б) Wikipedia: "Dismissal of U.S. Attorneys Controversy"
в) РГ: Федеральный закон Российской Федерации от 4 декабря 2006 г. N 202-ФЗ О внесении изменений в Федеральный закон "О науке и государственной научно-технической политике" и Федеральный закон "Об архивном деле в Российской Федерации" (пример того, как не надо составлять commit messages)
* * *
Блог "Better Explained" в кратчайшие сроки завоевал мегатонну человеческого внимания, опубликовав два чарующе прекрасных с визуальной точки зрения описания систем контроля версий.
а) Better Explained: "A Visual Guide to Version Control"
б) Better Explained: "Intro to Distributed Version Control (Illustrated)"
* * *
А также:
а) Презентация Бена Коллинза-Суссмана и Брайана Фицпатрика (ведущие разработчики Subversion): "Худшие практики использования Subversion"
б) Симпатичная шпаргалка по Git
в) Шпаргалка по Mercurial
Управление проектами → 7 правил гигиены при управлении релизами проекта
Проверочный список на качество управления релизами.
Управление релизами складывается из нескольких практик, практики в большей степени технические и инструментальные, но простые, а потому будут понятны даже тем менеджерам проектов, которые выросли не из программистов, а из каких-то других областей. Кроме того, практически все они так или иначе работают на одну главную идею: распространение информации между участниками проекта.
Управление релизами складывается из нескольких практик, практики в большей степени технические и инструментальные, но простые, а потому будут понятны даже тем менеджерам проектов, которые выросли не из программистов, а из каких-то других областей. Кроме того, практически все они так или иначе работают на одну главную идею: распространение информации между участниками проекта.