[docs] patches

Сб Фев 18 17:51:47 MSK 2006

On Sat, Feb 18, 2006 at 09:48:15PM +0300, Kirill Maslinsky wrote:

> KM>> То есть случай работы с двумя ветками документации принципиально не 
> KM>> отличается от случая работы с одной веткой -- просто получаем 
> KM>> один и тот же выпуск в два разных места и дальше с ними работаем.
>> Нет, ветка это ветка. В ней может быть серия уникальных изменений, часть
>> из которых будет бэкпортиться в основной документ, часть нет.
KM> Не вижу разницы. Работа с документом всегда заключается в создании локальной
KM> копии и внесении изменений. Туда, откуда была взята копия, может возвращаться только часть изменений. Копия может существовать сколь угодно долго и использоваться любым способом. Чем не ветка?

Ветка и "выпуск" это разные вещи.

> KM>> То есть по идее нам достаточно будет определить нечто вроде симметричного
> KM>> протокола взаимодействия между репозиториями (для обмена ОБЪЕКТАМИ и
> KM>> ИЗМЕНЕНИЯМИ). При наличии протокола теоретически можно сделать реализацию, для
> KM>> которой бекэндом будет хоть svn, хоть cvs, хоть что угодно. 
>> Эта задача многократно сложней задачи создания удобной распределенной
>> системы. До сих пор решение даже этой задачи не удалось никому.
KM> Нельзя решить задачу ``создание удобной системы'', она сформулирована 
KM> неправильно. Насчёт сложней -- не знаю. Вряд ли получится разобраться
KM> со сложными проблемами, решив какую-нибудь простую задачу.

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

>> Вы все усложняете. Куча как таковая не нужна. Нужен единый репозиторий
>> документов, из которого мантейнеры конкретных документов смогут легко
>> сделать пакет. Точно так же, как сейчас это происходит с ядрами.
KM> Не понимаю Вашей терминологии. Куча -- это репозиторий. И Сизиф -- репозиторий.
KM> Или они оба не репозитории? 

Репозитории. Оба два. И от обоих надо отказываться в пользу более
эффективных средств.

KM> Суда по аналогии с ядрами, Вы хотите свести Кучу к одному апстриму, кажется,
KM> так? Это ровно та модель, от которой мы отказались в пользу модели 
KM> АГГРЕГАТОРА документов из разных апстримов. Как Сизиф.

Следствием отказа от этого и стала неприемливая по крайней мере для меня
технология работы с документами.

>> Сама по себе куча лишняя сущность.
KM> Сизиф тоже в некотором роде лишняя сущность. Можно собирать дистрибутивы
KM> прямо из исходных CVS-ов.

Их исходных низя. Не получается.

>> Документ это один файл в некоем текстовом формате. Никаких тарболлов или
>> патчей там быть не может. Все изменения заведомо хранятся средствами svn.
KM> Догматично и полностью не соответсвует практике.
KM> Документ -- это может быть не один файл, а сколько угодно, да ещё 
KM> с подкаталогами и иллюстрациями. 
KM> Поэтому и тарболы быть могут ещё как.

Увижу репозиторий, предназначеный для работы документа, с хранящимися там
_тарболлами_ -- лично выскажу все что думаю об интеллекте создателя такого
репозитория, и отправлю его вместе с его поделкой в вечный игнор.

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

KM> Документ -- это текстовый файл. Его редактируют. Патчи есть и их не может 
KM> не быть.

Если документ лежит в svn, то патчи лежат в нём как в системе. А не в виде
отдельных файликов.

А вот с пакетами так низя -- все равно отдельные файлики нужны.

KM> Все изменения могут вообще не храниться, могут храниться какими угодно 
KM> средствами, уж точно тут нет ничего заведомого.

Ну вот чем больше _здесь_ разнообразия тем меньше шансов что хоть один
человек кроме создателя будет этой системой пользоваться.

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

Программа имеет гораздо более сложную структуру чем документ. Но таки да
-- скажем моя сборка Asterisk имеет очень мало общего со сборкой в любом
другом дистрибутиве, в том числе по исходникам и патчам.

Но мы отклонились от изначальной постановки вопроса. А она такова -- либо
все документы, с коротыми работает _команда_ хранятся в едином svn
репозитории, либо вы делаете всю работу по выпуску документации
исключительно силами тех людей, которым вы за эту работу платите. Потому
как делать полезное дело нахаляву можно, а вот когда при этом ещё и
геморрой устраивают -- оно как-то не хочется.

Соответственно, пока не будет svn, не будет:
 - проверки изменений друг-друга членами команд;
 - доработки чужих документах людьми "немного интересующимися";
 - активного добавления своих документов;

Ещё раз обращаю внимание на wiki -- из-за централизованой системы сейчас
мои wiki-ресурс очень сильно развиваются. Несмотря на очевидный недостаток
в виде отсутствия offline-доступа, и удобного merge для параллельных
изменений. Происходит это только потому что с wiki работать _удобно_, а с
кучей _неудобно_. А делать то, что человеку неудобно, можно его заставить
только за денюжку.

Я уже просто не понимаю о чем мы говорим -- все свои мысли в этом треде я
высказал уже много раз, по несколько раз в каждом письме. Я категорически
не понимаю что вы ещё хотите от меня услышать.

Пытаться меня переубедить в чем-то бесполезно, свою позицию я высказал в
первом же письме. Если что-то в этой позиции непонятно _и_ интересно --
могу разъяснить. Или можно просто закончить этот бессмысленный треп.

Правда при этом хочу напомнить, что мою позицию поддержало несколько
человек из здесь присутствующих. Уверен что поддержало бы больше -- да
только этот фактически мертвый список рассылки мало кто читает.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Одно из преимуществ hasher -- в том, что это всё в пределах POSIX API.
		-- at in devel@