LINUX.ORG.RU

Организация совместной разработки ПО на базе SVN+DocBook+Mantis: Часть 2, 3

 , , ,


0

2

Часть 2. Subversion - установка и администрирование сервера


Сам термин администрирование часто отпугивает возможной масштабностью задачи (возьмем к примеру администрирование Oracle, которым на крупных предприятиях занимаются целые сектора). Основная цель статьи — показать пользователям, решившим поддерживать контроль версий своей разработки, что задача администрирования Subversion:

  • посильна для любого программиста;
  • не требует значительных временных затрат;
  • требует организованности и методичности.


Одним из важнейших преимуществ Subversion является многоплатформенность, полная совместимость серверных и клиентских частей, работающих на разных платформах, удивительная простота установки серверной и клиентской частей и легкость администрирования. В статье будут рассматриваться вопросы в аспекте Linux (на примере OpenSUSE 11.2) и Windows XP.


Часть 3. Subversion - работа с версиями проекта


Мы знаем, что запущен сервер Subversion и нам предстоит начинать с ним работу в рамках определенного программного проекта, используя определенный метод доступа к хранилищу. Если создатель хранилища (администратор) создает хранилище исключительно используя прямой доступ (все команды администрирования выполняются без использования URL) непосредственно на компьютере где непосредственно расположено хранилище, то клиент может обращаться к серверу, расположенному:

  • на том же компьютере, что и рабочая копия;
  • на компьютере в локальной сети;
  • сервер доступен через Интернет.


С точки зрения логики работы никакой разницы не будет и только один раз при создании рабочей копии на локальном компьютере надо будет указать, каким образом вы связываетесь с хранилищем данных.

>>> Подробности

★★★

Проверено: mono ()

Ответ на: комментарий от balodja

> А погуглить сначала сложно было? Читай про экстеншон bfiles.

Читаю:

Mercurial was not designed to handle large binary files.
...
The goal of ``bfiles`` is to avoid these problems by taking large binary files entirely out of Mercurial's repository. Instead, their history lives in a *central store* somewhere, and ``bfiles`` downloads only the revisions you need when you need them.

Они там что, переизобрели cvs?

Manhunt ★★★★★
()
Ответ на: комментарий от kraw

> А я использую его именно для разработки ПО. И использую успешно.

И working copy ни разу не ломался? И merge происходит быстро и автоматически? И ни разу сервер не падал, так что ты не мог закомитить?

Не верю ©

Скорей всего ты никогда и не использовал DVCS.

anonymous
()
Ответ на: комментарий от Manhunt

> Некоторые файлы принципиально невозможно мержить. С централизованной VCS каждый участник команды лочит файл перед изменением.

А третий пример можешь? Потому что немержабельные двоичные и большие двоичные файлы - это несколько специальный случай (хотя даже для них вполне используют и Mercurial, и Git).

tailgunner ★★★★★
()
Ответ на: комментарий от balodja

> Кхм, это одна из первых задач, которые решает любая DVCS.

Путем вычеркивания буковки «D»?

Manhunt ★★★★★
()
Ответ на: комментарий от debian6

> назови мне задачу, которую может решить python, но не может решить C.

Быстро разработать современную DVCS силами небольшой команды.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

>это несколько специальный случай (хотя даже для них вполне используют и Mercurial, и Git).

«Некоторые и языком умываются» (c) Кот Матроскин.

kraw ★★★★
()
Ответ на: комментарий от tailgunner

> Быстро разработать современную DVCS силами небольшой команды. Сколько там человек git пилили до первого релиза?

anonymous
()

Централизация - мать порядка!

Губернаторы должны назначаться из Москвы!

Что посеешь - то и всегда на сервере найдёшь.

В git нет докачки, в bzr ломают формат репозитория, а наш советский svn можно собрать в гараже только с помощью циркуля и линейки!

Пафосно шелушишь - людей насмешишь!

.

Всё, подготовил транспоранты, сами их подставляйте, куда удобно, а я спать пойду. А то что-то я пафосный стал.

debian6
()
Ответ на: комментарий от debian6

> Всё, подготовил транспоранты, сами их подставляйте, куда удобно, а я спать пойду. А то что-то я пафосный стал.

каждой задаче свой инструмент. несколько сотен тысяч кода в условиях сотен и тысяч девелоперов для SVN приговор.

Использование hg/git для проектов в пару тысяч строк - проявление ПГМ, свойственное вчерашним студентам, гонящимся за модными словами в резюме.

anonymous
()
Ответ на: комментарий от anonymous

>> Быстро разработать современную DVCS силами небольшой команды.

Сколько там человек git пилили до первого релиза?

А первым релизом считается что именно? Если версия 1.0, то всяко больше, чем Mercurial (потому что сам Линус напиал!!!11). Если имеется в виду первый публичный релиз, то один человек (как и Mercurial).

tailgunner ★★★★★
()
Ответ на: комментарий от balodja

>Тому, кто пользовался VCS, мёрджил и не является мазохистом, тому очевидно.

fixed

dotbg ★★★★
()
Ответ на: комментарий от anonymous

ну почему же. с git можно очень красивую историю коммитов иметь. и stash - это так удобно!

dotbg ★★★★
()
Ответ на: комментарий от tailgunner

> А первым релизом считается что именно? Если версия 1.0, то всяко больше, чем Mercurial (потому что сам Линус напиал!!!11). Если имеется в виду первый публичный релиз, то один человек (как и Mercurial).

А если нет разницы, зачем нужен python?

anonymous
()
Ответ на: комментарий от anonymous

> Использование hg/git для проектов в пару тысяч строк - проявление ПГМ

Вовсе нет. Даже программа из пары тысяч строк легче пишется, если есть mq.

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Вот именно, что svn merge надо асиливать, причем асиливать заново при каждом merge, ибо настолько через жопу сделано, что в мозгу совершенно не откладывается как с этим работать.

Reset ★★★★★
()
Ответ на: комментарий от anonymous

>> А первым релизом считается что именно? Если версия 1.0, то всяко больше, чем Mercurial (потому что сам Линус напиал!!!11). Если имеется в виду первый публичный релиз, то один человек (как и Mercurial).

А если нет разницы

Ты вообще прочитал то, что я написал? Краткое изложение: разница есть, и значительная.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> А третий пример можешь?

Пожалуйста. Организации, где сильная централизованность упрощает административную работу:
1. управление правами доступа разных сотрудников к тем или иным файлам
2. бэкап (твой бранч не издохнет вместе с хардом твоей рабочей станции)
3. сбор статистики по активности сотрудников

Manhunt ★★★★★
()
Ответ на: комментарий от Reset

> возможность работы в offline

Учитывая всеобщее помешательство на онлайн сервисах и облаках, подолью жиру: offline не нужен.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

> 1. управление правами доступа разных сотрудников к тем или иным файлам

2. бэкап (твой бранч не издохнет вместе с хардом твоей рабочей станции)

3. сбор статистики по активности сотрудников

1 - реально (но решается другими методами), 2 и 3 - притянуто за уши.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Ты вообще прочитал то, что я написал? Краткое изложение: разница есть, и значительная.

Линус такой же программист как и остальные. А python для ограниченных умов да.

anonymous
()
Ответ на: комментарий от tailgunner

> 1 - реально (но решается другими методами), 2 и 3 - притянуто за уши. Какой ты упрямый и глупый. Централизованный документооборот это не притянуто за уши. Интересно как ты объяснишь 2 и 3 в случае потери документации на проект стоимостью в пару миллиардов?

anonymous
()
Ответ на: комментарий от tailgunner

> притянуто за уши.

Вовсе не притянуто. У нас как-то система пожаротушения дала ложное срабатывание. Включились разбрызгиватели, и хрен их вырубишь. Воды было по щиколотку. Как ты думаешь, что случилось с системниками, которые стояли на полу? А если правда пожар, сколько рабочих станций откинет ласты?

Manhunt ★★★★★
()
Ответ на: комментарий от anonymous

Разница есть. hg делался изначально как user-friendly, а git начался двигаться в этом направлении совсем недавно

Reset ★★★★★
()
Ответ на: комментарий от anonymous

> Линус такой же программист как и остальные.

Линус получше многих будет.

А python для ограниченных умов да.

Эти ограниченные умы ограниченными силами написали на Python Mercurial, которsq долго уделывал написанный на Си Git по всем статьям. Понятно, что потом Git допилили, и он сравнялся, но это было на год или два позже. О чем, собственно, и речь: «быстро разработать современную DVCS».

tailgunner ★★★★★
()
Ответ на: комментарий от Manhunt

> У нас как-то система пожаротушения дала ложное срабатывание. Включились разбрызгиватели, и хрен их вырубишь. Воды было по щиколотку. Как ты думаешь, что случилось с системниками, которые стояли на полу?

И что? Nightly backup всё равно положено делать. Если вы его делали, вы потеряли максимум день работы. Как тут помог бы SVN?

tailgunner ★★★★★
()
Ответ на: комментарий от Manhunt

> Они там что, переизобрели cvs?

Какая задача поставлена, такое и решение. Никаких переизобретений.

balodja ★★★
()
Ответ на: комментарий от tailgunner

> О чем, собственно, и речь: «быстро разработать современную DVCS».

Вот у python все так. Быстро разрабатываем, медленно работаем.

anonymous
()
Ответ на: комментарий от Reset

Нынче для тех, кто боится учить своих жен пользоваться клавиатурой, есть tortoisehg с интеграцией в nautilus.

balodja ★★★
()
Ответ на: комментарий от anonymous

>> 1 - реально (но решается другими методами), 2 и 3 - притянуто за уши.

Какой ты упрямый и глупый.

Утипути. Если ты такой умный, то объясни, как противоречит централизованный документооборот распределенной VCS? И причем тут пункты: «бэкап» и «сбор статистики» (первое всё равно надо делать для машин пользователей, для второго существуют центральные репозитории)

как ты объяснишь 2 и 3 в случае потери документации на проект стоимостью в пару миллиардов?

Для начала объясни, как документация проекта была потеряна. Она что - никогда не сливалась в центральный репозиторий? Или у этого репозитория не оказалось ни клонов, ни бэкапа? %)

tailgunner ★★★★★
()
Ответ на: комментарий от Reset

> Разница есть. hg делался изначально как user-friendly, а git начался двигаться в этом направлении совсем недавно

не мешайте кормить тролля.

anonymous
()
Ответ на: комментарий от tailgunner

> Nightly backup всё равно положено делать.

Nightly backup админы не делают, по неизвестным мне причинам.

Если вы его делали, вы потеряли максимум день работы.


У нас централизованная VCS, ни один бранч никуда не потерялся.

Manhunt ★★★★★
()
Ответ на: комментарий от anonymous

Так везде, не только в питоне. Чем быстрее пишем, тем медленее работаем. А вот медленные куски всегда можно и cython'ом до си-скорости допилить, если есть желание.

balodja ★★★
()
Ответ на: комментарий от anonymous

>> О чем, собственно, и речь: «быстро разработать современную DVCS».

Вот у python все так. Быстро разрабатываем, медленно работаем.

Доо. Mercurial медленнее Git как раз настолько, что человек этого не замечает.

tailgunner ★★★★★
()
Ответ на: комментарий от balodja

Да и зачем сайтоном, можно обычной сишечкой.

balodja ★★★
()
Ответ на: комментарий от Manhunt

> Nightly backup админы не делают, по неизвестным мне причинам.

Хм, и если работа затянулась, и тут ВНЕЗАПНО сработало пожаротушение, то незафиксированная рабочая копию уходит в нирвану?

У нас централизованная VCS, ни один бранч никуда не потерялся.

И? Какая разница, что с бранчами. Работа потерялась или нет? Незафиксированные изменения в рабочих копиях?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Nightly backup всё равно положено делать.

Да и речь шла об _упрощении_ административной работы. Делать Nightly backup с центральных серверов (которые к тому же реплицированы и физицески находятся в разных офисах) значительно проще, чем с рабочих станций.

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

> > Если вы его делали, вы потеряли максимум день работы.

У нас централизованная VCS, ни один бранч никуда не потерялся.

Децентрализованность VCS не означает, что должен отсутствовать сервер с репозиторием.

balodja ★★★
()
Ответ на: комментарий от balodja

Я это прекрасно знаю. Однако модель rapid-development ничем не лучше enterprise. Инструментарии enterprise (hg/git), ничем не лучше rapid svn'a. Если вам понятна ассоциация.

anonymous
()
Ответ на: комментарий от tailgunner

> И? Какая разница, что с бранчами.

Разница в том, что с DVCS в нирвану в этой ситуации ушли бы не последние незафиксированные кусочи, а целые бранчи (с характерным размером в человекомесяц, например).

Manhunt ★★★★★
()
Ответ на: комментарий от balodja

> Децентрализованность VCS не означает, что должен отсутствовать сервер с репозиторием.

Децентрализованность поощряет слишком редкие вливания на этот сервер.

Manhunt ★★★★★
()
Ответ на: комментарий от balodja

> Нет, не понятна. В одном случае у тебя ынтерпрайз «ничем не лучше» рада, а в другом наоборот.

Красная машина едет быстрее. Комара который кусает тебя за яйца надо убить быстро, а не ужасной смертью. Предавшего темного властелина раба, нужно мучать долго и изобретательно.

Ферштейн?

anonymous
()
Ответ на: комментарий от Manhunt

> Разница в том, что с DVCS в нирвану в этой ситуации ушли бы не последние незафиксированные кусочи, а целые бранчи (с характерным размером в человекомесяц, например).

Вообще не проблема

(1) Разработчик может свой бранч так же загружать на удалённый сервер, его изменения никому не помешают, потому что это отдельный бранч.

(2) Разработчик может иметь свой репозиторий на сервере, который регулярно синхронизируется с его локальным репозиторием.

anonymous
()
Ответ на: комментарий от anonymous

А кто-то из команды hg стоит рядом и держит за руку с фразами «не-е-ет, только не 51ый коммит, пожалуйста»? Кто ограничивает-то?

balodja ★★★
()
Ответ на: комментарий от anonymous

Какая-то лютая шизофазия, ничего не понял. Но подозреваю, что где-то спрятан намек на гаечный ключ с отверткой.

balodja ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.