Старт задачи в остановленном (suspended) состоянии.

[Андрей Чуйкин]

Добрый день.

Часто архитектура проекта подразумевает следующую последовательность
действий.
1. Запускается процесс-инициализатор, который выполняет инициализацию
драйверов, модулей, служб и т.д. (у кого что).
2. После инициализации процесс-инициализатор запускает "рабочие" процессы.

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

Предлагаю в класс process<...> добавить возможность задачам стартовать
приостановленными. В этом случае схема будет выглядеть так:
процесс-инициализатор выполняет инициализацию и пробуждает рабочие процессы.
Рутинного кода значительно меньше и он не размазан по файлам.

Реализация очень проста, не требует дополнительного ОЗУ и сохраняет обратную
совместимость.
Вот она (вычищено):

template<TPriority pr, size_t stack_size>
class process : public TBaseProcess
{
public:
INLINE_PROCESS_CTOR process(bool suspended = false);
OS_PROCESS static void exec();
OS_PROCESS static void suspended_exec() { sleep(0); exec(); }
};

template<TPriority pr, size_t stack_size>
OS::process<pr, stack_size>::process(bool suspended /*= false*/):
TBaseProcess(&Stack[stack_size / sizeof(stack_item_t)]
, pr
,
reinterpret_cast<void (*)()>(suspended ? suspended_exec : exec)
#if
scmRTOS_DEBUG_ENABLE == 1
, Stack
#endif
)
{ }

Пример.

typedef OS::process<OS::pr0, 1024> T1;
typedef OS::process<OS::pr1, 1024> T2;
typedef OS::process<OS::pr2, 1024> T3;

T1 t1;
T2 t2(true);
T3 t3(true);

namespace OS
{
template<> OS_PROCESS void T1::exec()
{
Init_all();
t2. force_wake_up ();
t3. force_wake_up();
while ( true )
{
...
}
}
template<> OS_PROCESS void T2::exec()
{
while ( true )
{
...
}
}
template<> OS_PROCESS void T3::exec()
{
while ( true )
{
...
}
}
} // ns OS

P.S.
Сразу скажу почему реализовано не как extensions. Ядро scmRTOS состоит из
трех сущностей: планировщик, задачи и синхронизация. Изменения (добавления),
вносимые в них, должны оставаться в ядре. Все что не попадает в эти три
сущности может быть реализовано как extensions. Отличный пример тому -
профилировщик.

[Anton Gusev]

Мне идея нравится, я - за. У меня в каждом проекте есть
OS::TEventFlag startEvent, которого ждут все процессы, пока наиболее
приоритетный проводит инициализацию.

Только я бы сделал параметр не bool, а enum { CREATE_ACTIVE,
CREATE_SUSPENDED }, чтобы нагляднее инициализировать:

T1 t1;
T2 t2(CREATE_SUSPENDED);
T3 t3(CREATE_SUSPENDED);

[Чуйкин Андрей]

В отпуске все что ли. 

[Harry Zhurov]

06.07.2015 16:30, Андрей Чуйкин пишет:

>
> Реализация очень проста, не требует дополнительного ОЗУ и сохраняет
> обратную совместимость. Вот она (вычищено):
>
> template<TPriority pr, size_t stack_size> class process : public
> TBaseProcess { public: INLINE_PROCESS_CTOR process(bool suspended =
> false); OS_PROCESS static void exec(); OS_PROCESS static void
> suspended_exec() { sleep(0); exec(); } };
>
> template<TPriority pr, size_t stack_size> OS::process<pr,
> stack_size>::process(bool suspended /*= false*/):
> TBaseProcess(&Stack[stack_size / sizeof(stack_item_t)] , pr ,
> reinterpret_cast<void (*)()>(suspended ? suspended_exec : exec) #if
> scmRTOS_DEBUG_ENABLE == 1 , Stack #endif ) { }
>
> Пример.
>
> typedef OS::process<OS::pr0, 1024> T1; typedef OS::process<OS::pr1,
> 1024> T2; typedef OS::process<OS::pr2, 1024> T3;
>
> T1 t1; T2 t2(true); T3 t3(true);
>

Я правильно понял, что выбор поведения осуществляется на рантайме путём
анализа аргумента 'suspended'? И собственно механизм реализован за счёт
того, что в конструкторе подсовывается адрес другой функции -
'suspended_exec' вместо 'exec'?

Если так, то пара замечаний.

1. Действия на рантайме всё-таки потенциально добавляют какой-то код,
хотя хороший компилятор должен однозначно сделать выбор на этапе
компиляции. Т.ч. это, наверное, мелочь.

2. Не должно ли в коде писать теперь так:

template<> OS_PROCESS void T2::suspended_exec()
{

while ( true )
{
...
}
}

?

--
HZ

[Harry Zhurov]

06.07.2015 16:49, Anton Gusev пишет:

Да, поддерживаю, что перечислимый тип в аргументе более информативен.

[Андрей Чуйкин]

1. Да, но оверхед ничтожный.
2. Нет, писать надо по-старому.
По-хорошему, надо suspended_exec() сделать protected.

> --
> --
> Страница группы -- http://groups.google.com/group/scmrtos-ru
> ---
> Вы получили это сообщение, поскольку подписаны на группу scmrtos-ru.
>
> Чтобы отменить подписку на эту группу и больше не получать от нее
> сообщения, отправьте письмо на электронный адрес scmrtos-
> ru+unsu...@googlegroups.com.
> Настройки подписки и доставки писем: https://groups.google.com/d/optout.

[Anton Gusev]

Harry Zhurov пишет 07.07.2015 17:14:

> 1. Действия на рантайме всё-таки потенциально добавляют какой-то код,
> хотя хороший компилятор должен однозначно сделать выбор на этапе
> компиляции. Т.ч. это, наверное, мелочь.

Кстати, да, мелочь-не мелочь, но всё же.
Можно сделать доп параметр шаблона:

enum CreateFlag { CREATE_RUNNING, CREATE_SUSPENDED };

template<TPriority pr, size_t stack_size,
CreateFlag createFlag = CREATE_RUNNING>

class process : public TBaseProcess
{
public:

INLINE_PROCESS_CTOR process()

: TBaseProcess(&Stack[stack_size / sizeof(stack_item_t)]
, pr

, reinterpret_cast<void (*)()>(launch)

#if scmRTOS_DEBUG_ENABLE == 1
, Stack
#endif
)
{}

OS_PROCESS static void exec();
protected:
OS_PROCESS static void launch()
{
if (createFlag == CREATE_SUSPENDED)
sleep(0);
exec();
}
};


И затем:

typedef OS::process<OS::pr0, 1024> T1;

typedef OS::process<OS::pr1, 1024, CREATE_SUSPENDED> T2;
typedef OS::process<OS::pr2, 1024, CREATE_SUSPENDED> T3;

Ы?

[Андрей Чуйкин]

Можно и так. Но runtime код анализа флага присутствует в обоих вариантах, так что здесь вопрос выбора такой: параметр конструктора или параметр шаблона.

Проверил генерацию кода.
Вариант с параметром конструктора занимает на 8 байт меньше. Но код конструктора process одинаков в обоих случаях. Компилятор где-то в другом месте наоптимизировал. Не искал где.
-O3 использовал.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Anton Gusev
> Sent: Wednesday, July 08, 2015 10:16 AM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Андрей Чуйкин]

Нашел разницу (в реализации launch/suspended_exec).
Код

if (createFlag == CREATE_SUSPENDED) sleep(0);
exec();

занимает больше места чем
sleep(0);
exec();

что вполне ожидаемо. Добавляется 4 байта на каждый "suspended" процесс. А т.к. у меня 2 таких процесса в тестовом коде, то получаем 8 байт разницы.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Anton Gusev
> Sent: Wednesday, July 08, 2015 10:16 AM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Андрей Чуйкин]

[Андрей Чуйкин]

А можно и объединить эти два подхода.
Т.е. флаг задается через параметр шаблона, но реализация как у меня изначально.
Код не вырос и не зависит от кол-ва задач.

Кто за какой подход? Я за флаг в шаблоне, это выглядит менее выбивающимся (а точнее не выбивающемся) из стиля scmRTOS.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Anton Gusev
> Sent: Wednesday, July 08, 2015 10:16 AM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Anton Gusev]

Я - за.

Не понимаю, почему в случае

if (createFlag == CREATE_SUSPENDED) sleep(0);

получаются какие-то рантайм-проверки. Я привык, что

if (параметр_шаблона)
Код();

практически эквивалентно

#if defined (что_то)
Код();
#endif.

То есть, строки

if (createFlag == CREATE_SUSPENDED) sleep(0);
exec();

При createFlag == CREATE_SUSPENDED должны быть полностью эквивалентны
sleep(0);
exec();

Скорее всего, gcc почему-то не осилил здесь соптимизировать. Бывает:)

[Harry Zhurov]

Всем привет!

С параметром шаблона симпатичнее и, согласен, более в духе проекта.

А вот дополнительная функция - это не вполне в духе. В духе - это было
бы включать оную фичу на этапе конфигурации. Т.е. завести
конфигурационный макрос, как и для всего остального, и он уже
определяет, просто 'exec' или 'launch/suspended_exec'.

Кроме того, видится ещё один вариант: не добавлять код в существующий
шаблон процесса, а родить другой шаблон (имена обсуждаемы):

template<TPriority pr, size_t stack_size>

class suspended_process : public TBaseProcess
{
public:
INLINE_PROCESS_CTOR suspended_process()

: TBaseProcess(&Stack[stack_size / sizeof(stack_item_t)]
, pr

, reinterpret_cast<void (*)()>(exec)

#if scmRTOS_DEBUG_ENABLE == 1
, Stack
#endif
)
{}
OS_PROCESS static void exec();

};

typedef OS::process<OS::pr0, 1024> T1;

typedef OS::suspended_process<OS::pr1, 1024> T2;
typedef OS::suspended_process<OS::pr2, 1024> T3;


Возможно, что-то упустил. Но если тут всё правильно, то получается
вообще всё прозрачно, просто и с нулевым оверхедом. И дух не нарушается.
:) Имхо.


--
HZ

[Anton Gusev]

Harry Zhurov пишет 08.07.2015 13:18:

> В духе - это было
> бы включать оную фичу на этапе конфигурации. Т.е. завести
> конфигурационный макрос, как и для всего остального, и он уже
> определяет, просто 'exec' или 'launch/suspended_exec'.

Так не получится, потому что обычно нужны процессы обоих типов, то есть,
нужны как процессы с exec, так и процессы с launch/suspended_exec.

> Кроме того, видится ещё один вариант: не добавлять код в существующий
> шаблон процесса, а родить другой шаблон (имена обсуждаемы):

Так в этом другом шаблоне всё равно нужны обе функции, и exec (это
собственно функция процесса, и launch/suspended_exec (которая спит,
затем вызывает exec).
По-моему, это уже оверинжиниринг - вместо одного параметра шаблона
создавать новый шаблон:) (К тому же это противоречит самой идее шаблонов).

[Андрей Чуйкин]

> конфигурационный макрос, как и для всего остального, и он уже
> определяет, просто 'exec' или 'launch/suspended_exec'.
>

Насчет еще одного конфигурационного макроса.
Описанная архитектура предполагает наличие как обычных процессов, так и остановленных процессов.
Как именно с помощью одного макроса указать, что вот эта задача обычная, а вот эта остановленная?

> Кроме того, видится ещё один вариант: не добавлять код в существующий
> шаблон процесса, а родить другой шаблон (имена обсуждаемы):
>

Родить другой шаблон, который на 99% идентичен существующему и мучиться с поддержкой дублированного кода? Я не за, т.е. против.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Wednesday, July 08, 2015 2:19 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Harry Zhurov]

08.07.2015 14:55, Anton Gusev пишет:

>
> Так в этом другом шаблоне всё равно нужны обе функции, и exec (это
> собственно функция процесса, и launch/suspended_exec (которая спит,
> затем вызывает exec). По-моему, это уже оверинжиниринг - вместо
> одного параметра шаблона создавать новый шаблон:) (К тому же это
> противоречит самой идее шаблонов).

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

Что касается идеи шаблонов, то тут всё в порядке: параметризованный тип
рожает объект согласно параметрам - приоритет, размер стека. Рантаймный
анализ безусловно, при том, что в подавляющем большинстве случаев он не
нужен, не радует. Либо изобретите специализацию шаблона, чтобы
несаспендный процесс юзал 'exec'. Вот это будет хорошее решение.

--
HZ

[Harry Zhurov]

08.07.2015 15:03, Андрей Чуйкин пишет:

> Родить другой шаблон, который на 99% идентичен существующему и
> мучиться с поддержкой дублированного кода? Я не за, т.е. против.

Ну, и сколько там того кода?

Не нравится другой процесс, тогда специализация.

[Anton Gusev]

Harry Zhurov пишет 08.07.2015 15:20:

> Либо изобретите специализацию шаблона, чтобы
> несаспендный процесс юзал 'exec'. Вот это будет хорошее решение.
>

Так сейчас как раз так и есть. Параметр шаблона, по нему компилятор в
compile-time подсовывает в качестве параметра конструктора TBaseProcess
либо exec, либо suspended_exec. Тем, кому этот функционал не нужен,
ничего менять не придётся, и ни одного лишнего байта они не потеряют.

[Harry Zhurov]

Сергей Борщ грит, у него сообщения где-то прорастают по дороге, просил
закинуть:

***********************************************************

On 08.07.2015 07:16, Anton Gusev wrote:
>Можно сделать доп параметр шаблона:

Параметр шаблона можно, поскольку на каждый процесс и так генерится свой
код и добавление параметра не приведет к увеличению дублирования кода.
Мне непонятен сам путь решения проблемы: почему процесс не может при
необходимости просто в своем конструкторе сбросить свой флаг в
TKernel::ReadyProcessMap? TBaseProcess имеет для этого готовую функцию
set_unready(). Добавляем в конструкторе

if(create_flag == CREATE_SUSPENDED)
set_unready();

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

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

--
HZ

[Harry Zhurov]

08.07.2015 16:30, Anton Gusev пишет:

>
> Так сейчас как раз так и есть. Параметр шаблона, по нему компилятор в
> compile-time подсовывает в качестве параметра конструктора
> TBaseProcess либо exec, либо suspended_exec. Тем, кому этот
> функционал не нужен, ничего менять не придётся, и ни одного лишнего
> байта они не потеряют.

Теоретически. Иначе это тогда что:

"Проверил генерацию кода.
Вариант с параметром конструктора занимает на 8 байт меньше. Но код
конструктора process одинаков в обоих случаях. Компилятор где-то в
другом месте наоптимизировал. Не искал где.
-O3 использовал."


--

HZ

[Harry Zhurov]

А вот как Сергей предложил с 'set_unready()', мне нравится.

--
HZ

[Андрей Чуйкин]

С set_unready() я начинал.
Эта функция реализована как Kernel.set_process_unready(this->Priority);
А объект Kernel не обязан быть сконструированным к моменту вызова его из конструктора процесса (на что я и напоролся).

> Теоретически. Иначе это тогда что:
>

Это разница в размере кода между моей изначальной реализацией и реализацией, предложенной Антоном.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Wednesday, July 08, 2015 5:01 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Anton Gusev]

Harry Zhurov пишет 08.07.2015 16:01:

> Теоретически. Иначе это тогда что:
>
> "Проверил генерацию кода.
> Вариант с параметром конструктора занимает на 8 байт меньше. Но код
> конструктора process одинаков в обоих случаях. Компилятор где-то в
> другом месте наоптимизировал. Не искал где.
> -O3 использовал."

Это сравнение первого варианта от Андрея с первым моим вариантом.
Потом Андрей скрестил эти два варианта, и получился паритет:)
В любом случае, лишние байты будут только при создании спящих процессов.

Но это уже неважно, теперь в моём хит-парате побеждает вариант от Сергея
Борща:)

[Андрей Чуйкин]

Промерял еще раз.

Если пользователь не использует suspended фичу для него ничего не изменяется: ни в исходниках, ни в размере кода.
Если пользователь использует suspended, то добавляется 24 байта кода.

По-моему, все отлично. Кто не пользуется, тому ничего лишнего изучать не надо и никакими ресурсами он не платит.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Wednesday, July 08, 2015 5:02 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

> А вот как Сергей предложил с 'set_unready()', мне нравится.
>
> --
> HZ
>
>

[Harry Zhurov]

08.07.2015 17:12, Anton Gusev пишет:

> Но это уже неважно, теперь в моём хит-парате побеждает вариант от
> Сергея Борща:)

Да, но вот Андрей серьёзное возражение выдвинул - при конструировании
процессов ядро ещё может быть не готово.

[Anton Gusev]

Harry Zhurov пишет 08.07.2015 16:35:

> Да, но вот Андрей серьёзное возражение выдвинул - при конструировании
> процессов ядро ещё может быть не готово.

Да, тогда конечно нужно вернуться к предыдущему варианту.

Как я понял, вот такому:

enum CreateFlag { CREATE_RUNNING, CREATE_SUSPENDED };

template<TPriority pr, size_t stack_size,
CreateFlag createFlag = CREATE_RUNNING>
class process : public TBaseProcess
{
public:
INLINE_PROCESS_CTOR process()

: TBaseProcess(&Stack[stack_size / sizeof(stack_item_t)]
, pr

, createFlag = CREATE_SUSPENDED ?
reinterpret_cast<void (*)()>(launch) :

reinterpret_cast<void (*)()>(exec) :
#if scmRTOS_DEBUG_ENABLE == 1
, Stack
#endif
)
{}
OS_PROCESS static void exec();

[Harry Zhurov]

08.07.2015 17:20, Андрей Чуйкин пишет:

> Промерял еще раз.
>
> Если пользователь не использует suspended фичу для него ничего не
> изменяется: ни в исходниках, ни в размере кода. Если пользователь
> использует suspended, то добавляется 24 байта кода.
>
> По-моему, все отлично. Кто не пользуется, тому ничего лишнего изучать
> не надо и никакими ресурсами он не платит.

Звучит убедительно. Если возражений нет, то фиксировать в репозиторий
такой вариант.

--
HZ

[Андрей Чуйкин]

Последний нюанс.
Как я помню был style guide на имена.
Как в соответствии с ним назвать enum и элементы enum?
enum CreateFlag { create_running, create_suspended };
Не?

> Как я понял, вот такому:
>

Немного не так.
Параметр конструктора TBaseProcess формируется как
reinterpret_cast<void (*)()>((cf == create_running) ? exec : suspended_exec)

А suspended_exec () (по-твоему launch) просто { sleep(0); exec(); }

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Wednesday, July 08, 2015 6:08 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Anton Gusev]

Андрей Чуйкин пишет 08.07.2015 17:19:

> Как я помню был style guide на имена.
> Как в соответствии с ним назвать enum и элементы enum?
> enum CreateFlag { create_running, create_suspended };

Судя по
enum TValue { efOn = 1, efOff= 0 };
и
enum TPriority { pr0 ...
, здесь у нас camelCase с префиксом.

то есть, так:

enum CreateFlag { cfRunning, cfSuspended };

И да, suspended_exec лучше, ибо отражает суть.
launch был уместен в моём первом примере, где он именно запускал exec().

[Harry Zhurov]

08.07.2015 19:16, Anton Gusev пишет:

>> Как я помню был style guide на имена. Как в соответствии с ним
>> назвать enum и элементы enum? enum CreateFlag { create_running,
>> create_suspended };
>
> Судя по enum TValue { efOn = 1, efOff= 0 }; и enum TPriority { pr0
> ... , здесь у нас camelCase с префиксом.
>
> то есть, так:
>
> enum CreateFlag { cfRunning, cfSuspended };
>

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

Насчёт CreateFlag. Не правильнее ли будет, согласно стилю, TCreateFlag?
И, вообще, почему CreateFlag, а не CreateType или StartMode, StartState.
Create тут, имхо, как-то не вполне адекватно - ведь речь не про создание
идёт, а именно про режим/состояние процесса на старте.

[Anton Gusev]

Harry Zhurov пишет 08.07.2015 18:36:

> И, вообще, почему CreateFlag, а не CreateType или StartMode, StartState.

Это у меня всплыло по аналогии с виндовым CreateThread(). Там
соответствующий параметр называется dwCreationFlags, и один из флагов
имеет значение CREATE_SUSPENDED.

А так, если смотреть по смыслу, то, имхо, что-то типа StartState.

[Андрей Чуйкин]

Так (?):
enum StartState { ssRunning, ssSuspended };

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Wednesday, July 08, 2015 7:37 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Harry Zhurov]

09.07.2015 9:02, Андрей Чуйкин пишет:

> Так (?): enum StartState { ssRunning, ssSuspended };
>

Годится.

--
HZ

[Андрей Чуйкин]

Зафиксировано.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov
> Sent: Thursday, July 09, 2015 10:20 AM
> To: scmrt...@googlegroups.com
> Subject: Re: Старт задачи в остановленном (suspended) состоянии.
>

[Anton Gusev]

Залил в репозиторий пример использования suspended процессов.

Samples/CortexM3/GCC/STM32F1XX/5-SuspendedTask

[Harry Zhurov]

Всем привет!

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

Напишу много букв, дабы как можно полнее донести мотивы, прошу не судить
за это строго. :)

Случилось так, что уже почти полтора года в текущих проектах в качестве
системы управления версиями использую git вместо svn (в этом году
пересадил на неё всех своих пацанов), и могу сказать только одно...
после git на svn даже смотреть не хочется. Честное слово. При всём
уважении к svn, много лет помогавшей в работе (только благодарность ей и
её авторам за это), она, скорее, является системой управления
архивированием проекта, а не системой управления версиями, это хорошо
понимаешь, поработав с тем же git'ом. Главная причина - работа с
ветвлением. В svn этого, можно сказать, нет. Я всегда чувствовал некий
недостаток, используя svn, как будто чего-то не хватает, как будто
какое-то ограничение... и потом я понял, что это.

Вот ситуация. Работаешь с кодом, в какой-то момент возникла идея, надо
бы попробовать, но ломать текущее состояние не хочется. Ясно - надо
завести ветку и экспериментировать в ней. Будет результат, слить его
обратно в рабочую. И вот тут оно и проявляется. Создать ветку как? На
сервере? Это как-то не очень кузяво - ветка может получиться чисто
экспериментальной и никуда не пойти, т.е. это по сути окажется "мусор".
И зачем это публиковать на сервере? Не говоря уже о не очень бодрой
работе с удалённым сервером (не знаю, у кого как, а у меня с sf.net
обмен данными весьма неторопливый). Ещё момент: если что-то сделано
неправильно - например, не тот url указал (ошибся с уровнем вложенности
папок), то эти косяки безвозвратно фиксируются в репозитории проекта,
что ни разу не нравится - мусорные коммиты на публичном сервере проекта.

Создать ветку локально через svn copy? Да, такой путь и предпочитаю -
если что-то сделано криво, так это у меня локально всё лежит, можно и
переделать, ничего не ломая, не портя в главном репе. Но это возня с
кучей папок и, по сути, клон всего репозитория со всей его структурой
(trunk, tags, branches) на уровне локального проекта, переход между
ветками не путём переключения их в текущей рабочей директории, а просто
переход в другую директорию (например, из trunk в
branches/<branch_name>). В итоге получается тяжеловесная, негибкая
структура, работать с которой очень неудобно.

Слияние в svn тоже не несёт особой радости. Конечно, по сравнению с cvs
тут гиганский прогресс (как и во многом другом), но тем не менее svn
merge всегда довольно "волнующее" мероприятие с потенциальными сюрпризами.

Как это происходит в git. Вот работаю с кодом и захотелось мне
поэкспериментировать, создаю ветку:

git co -b <branch_name>

при этом в проекте ничего не меняется, т.е. состояние файлов и
директорий то же самое, просто в репозитории (а репозиторий, напомню,
локальный) заводится метка-указатель на текущий коммит (коммит в git -
это просто "слепок" всех объектов (файлов и директорий) проекта), т.е.
на текущий коммит (текущее рабочее состояние проекта) указывает два
указателя - ветка, в которой я был, и ветка, которую я создал, эта
последняя является активной, и именно она будет перемещаться с
коммитами, а если я захочу откатиться в точку, откуда форкнул процесс,
достаточно будет дать команду как выше, только с именем прежней ветки.
Всё происходит практически мгновенно и без ошибок.

Ветка - название в git, не очень отражающие суть, это скорее
традиционное название. Ветка, если соотноситься со смыслом этого слова,
должна бы указывать на совокупность связанных между собой коммитов, как
это имеет место в svn или mercurial (это, кстати, по ходу, главное
отличие ртути от гита), но в git это не так, в git ветка - это просто
указатель на коммит, который, будучи текущим (текущая активная ветка),
автоматически перемещатся при создании нового коммита, указывая на него.

Поэтому создание ветки в git - очень дешёвая, простая операция. Теперь я
могу писать экспериментальный код, делать что угодно, не опасаясь ничего
сломать, и при необходимости быстро и без проблем вернуться к любому
состоянию. Это позволяет создавать ветки, не задумываясь о накладных
расходах, не переходя в другие директории, не меняя ничего в рабочей
директории руками - всё делает git, делает быстро и без ошибок.

Почему я так подробно описываю то, что достаточно хорошо подано в
документации к git'у? Это потому, что именно поддержки этого "паттерна"
в работе svn мне и не хватало. Тут я могу форкнуть процесс разработки,
не теряя точки, от которой "пошёл в сторону", причём делается это
мгновенно и тривиально, т.е. без напрягов во всех смыслах совершенно, и,
что не менее важно, я не загаживаю историю проекта мусорными коммитами -
на удалённый сервер я публикую только те изменения, которые нужны и важны.

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

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

feature branches - разрабатывается всё новое;
hotfix branches - фиксятся ошибки, вносятся/тестируются неотложные правки.

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

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

До кучи очень удобные, простые и полезные фичи git'а, такие как stage,
stash, cherry-pick, rebase и многие другие, делающие работу намного
более продуктивной и безопасной (в смысле потери данных).

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

Обсудил вопрос с Антоном, как использующим git, он посоветовал в этой
ситуации то же самое. Но попутно заметил, что как раз время обратить ещё
раз внимание на этот вопрос, а заодно и переехать с sf.net на github.
Против sf имеется аргумент: оказывается, у этого ресурса некоторое время
назад сменился хозяин, и стали происходить некрасивые вещи:

http://www.opennet.ru/opennews/art.shtml?num=42318
http://www.opennet.ru/opennews/art.shtml?num=42354

что, понятное дело, не радует.

Главное препятствие, которое я вижу на этом пути - это необходимость
всем участникам проекта освоить git. Подробность, с которой написан
текст выше, преследует одну цель: показать собственный опыт (чего
хотелось, что не моглось и что смоглось :)), может быть это как-то,
что-ли, вдохновит.

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

Поэтому выражаю от себя лично и от лица Антона предложение ко всем
остальным участникам проекта:

1. рассмотреть возможность освоения VCS git;
2. рассмотреть возможность перевода проекта на хостинг github.

Не обазательно всё делать резко и сразу. Делать без напряга, спокойно.

*******************************
Попутно замечание: порог вхождения, чтобы начать что-то делать, у git'а
совсем невысокий. Реально достаточно прочитать первые три главы (они
небольшие):

http://git-scm.com/book/ru/v1/Введение
http://git-scm.com/book/ru/v1/Основы-Git
http://git-scm.com/book/ru/v1/Ветвление-в-Git

чтобы начать полноценно работать. Конечно, понимание нюансов, как
обычно, придёт чуть позже, но это не мешает начать работать. На вопросы
и Антон, и я с удовольствием ответим.

Далее установить клиента, при желании настроить alias'ы (ну, чтобы не
писать каждый раз git status, а достаточно было git st или вообще gst (я
щас такой алиас использую)). Реально при наличии немалого количества GUI
клиентов, они, имхо, нафиг не нужны. Очень удобная и эффективная консоль
(unix-style). Для просмотра лога в удобном виде там есть простенькая GUI
смотрелка, входящая в состав базового пакета.
*******************************

В общем, вот как-то так. Прошу высказываться.


--
HZ

[Anton Gusev]

И от меня всем привет!

Хоть Гарри и написал уже, что я за, я всё же решил высказать это явно:)

Я, наверное, не так глубоко погрузился в git, как он, но тоже в
настоящее время с трудом представляю себе разработку без git.

Хочу акцентировать внимание на том, что sourceforge, однажды начав
делать гадости, скорее всего уже не остановится. В настоящее время
хостинг на sf - это приличный минус репутации проекта. Так что моё
мнение по поводу sf - надо оттуда валить.
Github пока вроде в таких вещах не замечен.

Кстати, работать с git-репозиторием на github можно и через svn:
https://github.com/blog/1178-collaborating-on-github-with-subversion
(сам не пробовал).

[Sergey A. Borshch]

On 11.09.2015 13:38, Harry Zhurov wrote:
> Всем привет!
Привет-привет.

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

Возможность позаниматься - это здорово.

> Случилось так, что уже почти полтора года в текущих проектах в качестве системы
> управления версиями использую git вместо svn

Да, все двигаются в эту сторону. Я пытался, но два подхода потерпели неудачу.
Видимо читал документацию не с начала, а в том месте, где описывалось нужное
действие.

Да, переползать надо и чем быстрее тем лучше, но ты же понимаешь - в первое
время мы (я) тебя завалим морем просто абсолютно тупых вопросов.

Что мне не нравится в git (я понимаю, что это данность и это не исправить, но
может я пока не все понимаю):
1) номера ревизий. Если сейчас мне заказчик говорит, что софт ему пишет номер
svn ревизии 503, то я хотя бы понимаю, что это более старая версия, чем 530. В
гите же ревизии нумеруются трудночитаемой и уж точно не запоминаемой абракадаброй.
2) работа с сервером. Решил я однажды попробовать авиасимулятор flightgear. Одна
из его составных частей живет под гитом. Объем репозитория - более 3 гигов.
Качается все это одним куском. Интернет у тещи был не очень хороший. В общем я
раз пять пытался скачать (клонировать?) этот репозиторий, 4 раза связь рвалась
на одном, полутора, двух гигах, гит вываливался с ошибкой после перезапуска
каждый раз он начинал закачивать все сначала. SVN позволяет скачать большой
репозиторий несколькими частями. Я, конечно, понимаю, что объем нашего
репозитория значительно меньше, но вот это вот скачивание и хранение у себя
полной копии всего репозитория от сотворения мира меня несколько напрягает.
История фиксаций пятилетней давности требуется раз в год или реже, в таких
случаях можно и на сервер сходить.

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

Да, и мне придется таки обновлять свой сервер. Фактически строить его заново,
потому что там стоит неподдерживаемый с 2012 года дебиан 5 (работет - не трогай)

--
Regards,
Sergey A. Borshch mailto: sb...@sourceforge.net
SB ELDI ltd. Riga, Latvia

[Harry Zhurov]

11.09.2015 17:59, Sergey A. Borshch пишет:

> Да, переползать надо и чем быстрее тем лучше, но ты же понимаешь - в
> первое время мы (я) тебя завалим морем просто абсолютно тупых
> вопросов.

Это нормальное дело и не пугает ни разу, я только рад помочь, чем могу.
Сам тоже не гуру, уровень - пользователь. Но для работы хватает.

> Что мне не нравится в git (я понимаю, что это данность и это не
> исправить, но может я пока не все понимаю): 1) номера ревизий. Если
> сейчас мне заказчик говорит, что софт ему пишет номер svn ревизии
> 503, то я хотя бы понимаю, что это более старая версия, чем 530. В
> гите же ревизии нумеруются трудночитаемой и уж точно не запоминаемой
> абракадаброй.

Для релизов, которые уходят к заказчику, имхо, надо просто вводить теги,
т.е. метить этот релизный коммит, тогда будет внятная запись, что там
прошито. У меня на svn была автоматическое извлечение номера ревизии с
целью вставки в программу как раз для таких целей. Для гита переделал,
там он эти метки извлекает. Ну, и если даже не пометил, то будет
подобная штука:

gmii_test-96-g41dd939

где

gmii_test - это ближайшая метка, которую я ставил;
96 - это количество коммитов от неё;
g41dd939 - первые 8 символов хеша (фамилии) коммита.

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

> 2) работа с сервером. Решил я однажды попробовать
> авиасимулятор flightgear. Одна из его составных частей живет под
> гитом. Объем репозитория - более 3 гигов. Качается все это одним
> куском. Интернет у тещи был не очень хороший. В общем я раз пять
> пытался скачать (клонировать?) этот репозиторий, 4 раза связь рвалась
> на одном, полутора, двух гигах, гит вываливался с ошибкой после
> перезапуска каждый раз он начинал закачивать все сначала. SVN
> позволяет скачать большой репозиторий несколькими частями. Я,
> конечно, понимаю, что объем нашего репозитория значительно меньше, но
> вот это вот скачивание и хранение у себя полной копии всего
> репозитория от сотворения мира меня несколько напрягает. История
> фиксаций пятилетней давности требуется раз в год или реже, в таких
> случаях можно и на сервер сходить.

Вот насчёт размера не скажу, таких конских репов я не видел, дел не
имел. Но, как знаю, такие репы делать в гите - моветон. Здоровенные
проекты, обычно, разбивают на более мелкие части и ведут их помодульно,
ведь врядли там весь этот код связан между собой. Вон целый линух под
гитом держат и не испытывают проблем. Ну, и наши потребности (как ось,
так и свои проекты) гит накроет в этом смысле без вопросов. Антон грит,
вытягивал реп оси в виде гит-репа, получилось порядка 17.5 мегов.

> Скажем так - я за переезд, документацию по ссылкам по мере
> возможностей почитаю, но вопросы все равно будут глупые. Если вы с
> Антоном действительно хорошо подумали и к ним готовы - тогда
> пааааехали!

По вопросам - без проблем, всегда рады. Стучи в асю/джаббер.

> Да, и мне придется таки обновлять свой сервер. Фактически строить его
> заново, потому что там стоит неподдерживаемый с 2012 года дебиан 5
> (работет - не трогай)

А он-то тут каким боком? Или это какой-то сугубо твой рабочий элемент?

--
HZ

[Андрей Чуйкин]

Привет.

> 1. рассмотреть возможность освоения VCS git; 2. рассмотреть возможность
> перевода проекта на хостинг github.
>

Не вопрос. Я не против.
Офф.
Года полтора назад я приступал к изучению git. Нравилась мне его идеология. Но не срослось. Дело в том, что мои проекты не только исходники кода, но бинарники от PCAD, SolidWorks, Corel и т.п. На тот момент (не знаю как сейчас) git ОЧЕНЬ НЕЭФФЕКТИВНО, в смысле расхода дискового пространства, работал с бинарниками. Это стало главной причиной неперехода на него. Все -таки git заточен на чистых программеров. Но в контексте разработки scmRTOS я поддерживаю за переход на него.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov

[Harry Zhurov]

14.09.2015 13:52, Андрей Чуйкин пишет:

>>
> Не вопрос. Я не против. Офф. Года полтора назад я приступал к
> изучению git. Нравилась мне его идеология. Но не срослось. Дело в
> том, что мои проекты не только исходники кода, но бинарники от PCAD,
> SolidWorks, Corel и т.п. На тот момент (не знаю как сейчас) git ОЧЕНЬ
> НЕЭФФЕКТИВНО, в смысле расхода дискового пространства, работал с
> бинарниками. Это стало главной причиной неперехода на него. Все -таки
> git заточен на чистых программеров. Но в контексте разработки scmRTOS
> я поддерживаю за переход на него.

А вот тут тоже всё оказалось несколько не так. Когда я пересел на git,
то сделал это только для программных проектов, электроника
(схемы/печатные платы, Altium Designer) оставил по svn, полагая, что там
оно хранится эффективнее. Но буквально несколько месяцев назад провёл
эксперимент с целью выявления эффективности хранения нетекстовой
информации в системах контроля версий, что выявило следующее.

Подобный эксперимент я проводил лет 7-8 (или больше) назад с svn:
например, менял в схеме номинал резистора, сохранял файл, закидывал в
репозиторий, смотрел на размер дельты. Она была большой - почти с разме
файла, т.е. мегабайты. Это не обрадовало - система, похоже, тупо грузила
весь файл. Подобную операцию повторял - делал мелкие изменения в схемах,
платах, размер репозитории рос просто конски. Но если такой репозиторий
попробовать пожать архиватором (rar или 7zip), то размер получался очень
небольшой - архиватор успешно справлялся со сжатием этих больших но
похожих друг на друга дельт. Т.е. худо-бедно, но можно репозиторий хотя
бы бекапить в более-менее компатном размере.

Каково же было моё удивление в этот раз, когда подобного эффекта я не
увидел - дельты получались здоровенными, как обычно, но архиваторы их не
сжимали... Возможно, это связано с тем, то в прежний раз svn был старой
версии, до 1.8, там, возможно, использовались иные механизмы/алгоритмы
при построении хранилища.

Попробовал проделать ту же операцию с git'ом. Эффект получился тем же
самым - репозиторий раздувается, несмотря на то, что файлы почти те же
самые - как и любая другая система управления версиями, git не умеет
эффективно выделять дельты нетекстовой информации. Попытка пожать
архиватором тоже показала неуспех - картина ровно та же, что и с svn...

Но когда я запустил git gc (gc - garbage collector, удаляются мусорные
потерянные комиты, сжимается внутренняя база данных), то, о чудо, размер
репозитория резко сократился и стал почти таким, как он был при первом
комите, т.е. когда файлы в него добавились в первый раз. То, с чем не
справились архиваторы, успешно справилась встроенная утилита.

После этого я в текущем проекте и в паре других перетащил из svn репа в
git. И работать стало проще и удобнее, и реп компактнее, а уж когда он
начинает иметь неприличный размер, то одна команда, пять секунд, и вуаля.

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




--
HZ

[Андрей Чуйкин]

Приятный сюрприз. Ну что же. Само просится.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov

> Sent: Tuesday, September 15, 2015 11:33 AM
> To: scmrt...@googlegroups.com

[Harry Zhurov]

Общий привет!

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

Вопрос первый.

Репозиторий из svn с sf.net вытянут с конвертацией в git. Собственно, в
нём одна рабочая ветка и пара незакрытых (3.11 и 4.00), которые давно не
нужны, но удалить руки не дошли. И набор меток, которые указывают на
релизы. И вот смотрели мы с Антоном на это дело, и возникла
мысль-вопрос: а надо ли тянуть всё это в качестве базы? Получается
довольно длинная ветка с кучей рабочих комитов, но которые сейчас
представляют скорее музейную ценность.

В общем, тут два пути:

* базироваться на этой ветке;
* начать новую основную ветку, базируя её на крайнем комите, из
вытянутой с sf.net, а вытянутую из sf.net сложить рядом, пусть лежит для
истории - если надо что-то посмотреть, вытащить из неё, то вот она,
рядом. Но в новом процессе глаза не мозолит - уж больно сильно её вид
отличается от work-flow, получающегося при работе с git.

Лично я сперва хотел первый вариант, но посмотрев на всё это в реале,
сейчас склоняюсь ко второму.

Мнения, предложения, аргументы?


Вопрос второй. Структура нового репозитория.

У svn и git имеется очень существенное различие в организации
репозитория. У svn оно "привязано" к структуре файловой системы, что
имеет свои плюсы и минусы, а у git ориентировано конкретно на рабочую
копию, что тоже имеет свои плюсы и минусы. Плюсом svn является то, что
файловоориентированный подход позволяет вытянуть не весь репозиторий, а
какую-то его часть, каталог, файл, и это, в свою очередь, позволяет
хранить всё - Common, Ports, Samples, Extensions - в одном репозитории,
а при необходимости вытащить куда угодно любую из перечисленных частей и
даже отдельные их части.

Git такое не позволяет сделать, т.к. у него нет ориентации на структуру
каталогов - он может только тянуть весь реп. Поэтому тут принят такой
подход: более-менее законченные части размещаются в отдельных
репозиториях. Т.е. отдельный модуль, отдельный проект - свой
репозиторий. Для включения стороннего кода в git'е используются т.н.
submodules.

Субмодуль - это отдельный каталог в проекте, который настроен на то, что
в него клонируется другой репозиторий. Например, вот есть у нас проект,
в нём наши сорцы, но есть и сторонние - какие-то библиотеки или та же
ось. Вот эти вещи лежат в своих каталогах и они прописаны в проекте как
субмодули. Зайдя в каталог с субмодулем, с этим кодом можно работать
ровно так же, как и со своим (это удобно, если, например, субмодуль -
своя библиотека, находящаяся тоже под контролем версий).

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

Первое, что просится, это убрать примеры в свой отдельный репозиторий.
Оно и логично - что примерам-то делать в рабочем проекте. Примеры - это
сами по себе рабочие проекты, хотя и маленькие.

Второй вопрос более неоднозначный: что делать с оставшемся? Оно состоит
из общей части (Common, Extensions) и платформеннозависимой (Ports).
Проблема в том, что порты, в силу описанной выше особенности git'а,
нельзя вытягивать по одному. Поэтому тут два пути: либо все порты лежат
в одном репозитории друг с другом и с общей частью (и всё это тянется
вместе), либо для каждого порта - отдельный репозиторий.

Какие видятся плюсы и минусы. Отдельный репозиторий для каждого порта
даёт то, что можно его вытянуть, не тащя остальные. На этом плюсы
заканчиваются и начинаются минусы:

1. дополнительная работа;
2. [главный минус, имхо] менее обусловленная по сравнению с общим репом
связь между портами и общей частью - нужно "руками" следить за
консистентностью общей сборки - какие комиты общей части соответствуют
комитам портов.

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

Недостатки: лишнее место занимают, глаза мозолят. Возражения: места
занимают очень немного, и по сегодняшним реалиям на диске это исчезающе
малое расходование ресурса; глаза мозолят - тоже, имхо, несерьёзная
проблема - лежит себе каталог с осью, никто в него не ходит. И даже
маленький плюс - вдруг захочется посмотреть, как сделано то или иное в
другом порте (от сорцов до настроек мейкфайлов).

Ещё "недостаток": пути к каталогам непосредственно самих портов
получаются более длинными - полные пути.

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

[и снова] Мнения, предложения, аргументы?

--
HZ

[Harry Zhurov]

Да, вот ещё какой момент, парни. Надо будет, у кого нет, завести учётные
записи на гитхабе, чтобы вас можно было пригласить в команду. Имена
учёток сюда сообщайте, пожалуйста.

--
HZ

[Sergey A. Borshch]

On 15.09.2015 13:51, Harry Zhurov wrote:
> В общем, тут два пути:
>
> * базироваться на этой ветке;
> * начать новую основную ветку, базируя её на крайнем комите, из вытянутой с
> sf.net, а вытянутую из sf.net сложить рядом, пусть лежит для истории - если надо
> что-то посмотреть, вытащить из неё, то вот она, рядом.

Логично. Я - за. Именно потому, что предыдущие ревизии имеют исключительно
историченскую ценность.

> Вопрос второй. Структура нового репозитория.
>

> Первое, что просится, это убрать примеры в свой отдельный репозиторий. Оно и
> логично - что примерам-то делать в рабочем проекте. Примеры - это сами по себе
> рабочие проекты, хотя и маленькие.

Тоже согласен.

> Поэтому тут два пути: либо все порты лежат в одном репозитории друг с другом и с
> общей частью (и всё это тянется вместе), либо для каждого порта - отдельный
> репозиторий.
>
> Какие видятся плюсы и минусы. Отдельный репозиторий для каждого порта даёт то,
> что можно его вытянуть, не тащя остальные. На этом плюсы заканчиваются и
> начинаются минусы:
>
> 1. дополнительная работа;
> 2. [главный минус, имхо] менее обусловленная по сравнению с общим репом связь
> между портами и общей частью - нужно "руками" следить за консистентностью общей
> сборки - какие комиты общей части соответствуют комитам портов.

И еще один минус - как быть с нумерацией ревизий. Получится, что ОСь имеет две
ревизии - общей части и конкретного порта. Или я чего-то не понял, и это то же
самое, что и пункт 2? В таком случае - или я что-то путаю, или краем глаза
где-то читал, что в гите можно привязать нужную директорию субмодуля к
конкретной ревизии субмодуля? Тогда можно в самом начале привязать в портах
директории общей части к "первой" ревизии субмодуля общей части, а по мере
доработки общей части (увеличения ее версии) после проверки каждого порта
перепривязывать его к текущей на данный момент ревизии общей части. Тогда для
идентификации будет достаточно ревизии порта, а уже из него можно узнать
привязанную ревизию общей части.

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

Да, это мне не нравится. Хотя я и храню копию ОСи в своих проектах и внутри
проекта на репозиторий ОСи не завязан, то есть в общем-то мне это мешать не должно.

> Недостатки: лишнее место занимают, глаза мозолят. Возражения: места занимают
> очень немного, и по сегодняшним реалиям на диске это исчезающе малое
> расходование ресурса; глаза мозолят - тоже, имхо, несерьёзная проблема - лежит
> себе каталог с осью, никто в него не ходит. И даже маленький плюс - вдруг
> захочется посмотреть, как сделано то или иное в другом порте (от сорцов до
> настроек мейкфайлов).

Но мозолит.

> Ещё "недостаток": пути к каталогам непосредственно самих портов получаются более
> длинными - полные пути.

Вот про это можно поподробнее? В гите что, репозиторий нельзя перемещать по диску?

> В общем, мне представляется, что общий репозиторий, наверное, более простой и
> ровный путь.

> [и снова] Мнения, предложения, аргументы?

Как и обещал, у меня пока только глупые вопросы. Для аргументов базовых знаний,
умений и навыков нет.

> > Да, и мне придется таки обновлять свой сервер. Фактически строить его
> > заново, потому что там стоит неподдерживаемый с 2012 года дебиан 5
> > (работет - не трогай)
>
> А он-то тут каким боком? Или это какой-то сугубо твой рабочий элемент?

Ну да, перезжать - так всем колхозом, тьо есть перетаскивать под гит все свои
старые проекты. Это и время освоения и зоопарк должно уменьшить.

[Sergey A. Borshch]

sborshch

[Anton Gusev]

Sergey A. Borshch пишет 16.09.2015 10:54:

> sborshch

Отправил приглашение.

[Anton Gusev]

Harry Zhurov пишет 16.09.2015 10:45:

> Имена учёток сюда сообщайте, пожалуйста.

Учётку Андрея я знаю, отправил ему приглашение.

[Anton Gusev]

Sergey A. Borshch пишет 16.09.2015 10:50:

> Логично. Я - за. Именно потому, что предыдущие ревизии имеют исключительно
> историченскую ценность.

Есть ещё такое, скажем, имиджевое соображение - число коммитов у проекта
и длина его истории. Когда история проекта содержит 249 коммитов, и его
история начинается с 2006 года - это, как минимум, внушает некоторое
уважение. То есть, потенциально это может дать нам несколько
дополнительных пользователей. Нужно нам это или нет?

Насчёт структуры.

(Нам нужно, чтобы scmRTOS было удобно подключить в качестве субмодуля.
То есть, чтобы в проекте просто было получить директорию scmRTOS, в
которой содержится всё, что нужно).

Варианты: ось и порты в одном репозитории, порты в отдельных репозиториях.

Вариант 1. Ось и порты в одном репозитории.
-------------------------------------------

Недостаток 1. Изменятся пути. То есть, вместо scmRTOS/CortexMx получим
scmRTOS/Ports/CortexMx/GCC.

Недостаток 2. Страдает эстетика.


Вариант 2. Порты в отдельных репозиториях.
-------------------------------------------

Если делать отдельный репозиторий для каждого порта, то тут придётся
делать так: порт, в нём субмодулем - ось. (Проблемы с консистентностью
версий оси и порта нет - конкретная ревизия порта содержит конкретную
ревизию оси). Тогда в проект подключаем репозиторий нужного порта (а к
нему, рекурсивно, ось). Тоже неплохо. Но.

Недостаток 1. Не получится сохранить структуру каталога scmRTOS
scmRTOS
Common
PortMame
Extensions.

Будет что-то типа
scmRTOS
Port
OS
Common
Extensions.
, где папка OS - это субмодуль оси.

Недостаток 2. Сложное обновление портов после обновления ревизии оси:
для каждого порта
{
git pull в субмодуле оси;
git commit;
git push;
}
Наверное, это можно как-то автоматизировать, но я пока не знаю как.

Недостаток 3.
в репозиториях примеров будет очень много субмодулей. В каждом наборе
примеров придётся подключить свой субмодуль порта. Что опять же влечёт
сложности при обновлении. В первом варианте в репозитории примеров будет
всего один субмодуль оси.

Недостаток 4. Получится довольно-таки много репозиториев... Легче
запутаться, лишние коммиты при изменении версий субмодулей, бритва
Оккама недовольна:)

В общем, написав всё это, я склоняюсь к одному общему репозиторию:)

[Sergey A. Borshch]

On 16.09.2015 13:00, Anton Gusev wrote:
> Будет что-то типа
> scmRTOS
> Port
> OS
> Common
> Extensions.
> , где папка OS - это субмодуль оси.

Что мешает Extensions вынести тоже в отдельный субмодуль? Получаются два
субмодуля - Common и Extensions. Extensions не всегда и нужны. Структура папок
не пострадает. Мне нравится. Да и логично как-то.

> Недостаток 4. Получится довольно-таки много репозиториев... Легче запутаться,
> лишние коммиты при изменении версий субмодулей, бритва Оккама недовольна:)
>
> В общем, написав всё это, я склоняюсь к одному общему репозиторию:)

В общем, прочитав все это, я не увидел ни одного достоинства гита кроме модности :)

[Anton Gusev]

Sergey A. Borshch пишет 16.09.2015 15:08:

> Что мешает Extensions вынести тоже в отдельный субмодуль? Получаются два
> субмодуля - Common и Extensions. Extensions не всегда и нужны. Структура папок
> не пострадает. Мне нравится. Да и логично как-то.

Да, можно так. Не сообразил.

> В общем, прочитав все это, я не увидел ни одного достоинства гита кроме модности :)

Перечитай начальный пламенный пост Гарри:)

[Андрей Чуйкин]

> * базироваться на этой ветке;
> * начать новую основную ветку, базируя её на крайнем комите, из

> Вопрос второй. Структура нового репозитория.
>

Не представляю к чему приведет тот или иной вариант. Нет мнения у меня.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]
> On Behalf Of Harry Zhurov

> Sent: Tuesday, September 15, 2015 4:51 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Организационные вопросы
>

[Harry Zhurov]

16.09.2015 16:08, Sergey A. Borshch пишет:

> В общем, прочитав все это, я не увидел ни одного достоинства гита
> кроме модности :)

Модность не причём. Начнёшь работать каждоднево, заценишь ветки и другие
фички, эти "недостатки" перестанут казаться недостатками. :)

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

А вот вопрос: как делают в больших проектах? Например, тот же линух подо
что только не сделали, как там порты таскают?


--
HZ

[Harry Zhurov]

Всем привет!

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

1. Вместо одного репозитория, который был под svn, в котором хранилось
всё - от исходников оси до приложений-примеров, на git'е будет их два:

* исходныики ОС (ядро, порты, расширения);
* приложения-примеры.

2. Настройка путей к портам потребует коррекции, т.е. правки makefile,
SConstruct, настроек IDE - в общем, у кого что. Работы не много, но тем
не менее "бесшовного" перехода не получится.

3. Переделка системы подключения к сорцам ОС в проектах. Т.е. вместо
svn:externals надо будет внедрить git-submodule. Это основное по
сложности и трудоёмкости.

Т.е. соместимости не получается. Причём глобально, сразу на уровне
организации проекта. В связи с этим возникло несколько вопросов-предложений.

1. Такие глобальные (в масштабах проекта) изменения требуют
соответствующей коррекции номера ОС. Я вот думал, что следующим выпуском
релиза будет 4.05 или 4.10, но сейчас, чем больше думаю об этом, тем
больше склоняюсь, что это должно быть 5.0.0. Уж слишком и структура, и
использование (на уровне пользовательского проекта) отличаются.

2. Раз уже пошло такое дело, то тут самое время реализовать старую
хотелку. Я её не озвучивал, потому что она была ни к чему. Но теперь для
неё, имхо, самое время. Суть её в следующем: меня давно коробят имена
основных директорий, как по сути, так и по написанию:

/Common
/Ports
/Extensions

Ну, Extensions взялось в таком виде исключительно из соответствия общему
стилю. А вот первые два взялись давно и исторически сложилось так, что
особо над этим не думалось - проект в 2003-м году начинался как
внутренний, какие имена в голову пришли, так и поехало. Но вот по сути
оно не нравится. Взять, к примеру, Common. Что за Common? Общая часть?
Гуд, а расширения по сути не относятся, что-ли, к общей части, они ведь
для всех портов. Безликое имя. Ведь это, по факту, просто ядро. Вот и
надо его та назвать.

И этот стиль вендовый - длинные имена с заглавной буквы... фу.

В общем, я бы изменил это на:

/core
/port
/ext

Коротко и внятно.

Возможные возражения. Пока видно их два.

1. В настройках рабочего проекта придётся исправить не только одни путь
к порту, но и ещё одно (или два - если используются расширения) имя.
Небольшая, прямо скажем, работа, учитывая, что оба места правки
находятся рядом. И на фоне перехода от svn:externals к git-submodule это
вообще незаметно.

2. Потенциально может потеряться связь файлов из-за переименования
директорий. На это указал мне Антон: если, например, дать команду:

git diff HEAD <tag> Common/OS_Target.cpp

которая должна показать изменеия между текущим состоянием (головой) и
комитом по метке, то после переименования это работать не будет, т.к.
путь уже будет не Common/OS_Target.cpp, а core/OS_Target.cpp.

В данном случае это лечится маской:

git diff HEAD <tag> *OS_Target.cpp

Ситуация с портами аналогичная:

$ git diff HEAD <tag> */CortexM3/GCC/OS_Target_cpp.cpp

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

С Антоном перетирали этот вопрос, он жёстко оппонировал (не хотел
отказываться от такой возможности), но, вроде, удалось его уговорить.
Теперь осталось уговорить остальных. :)

Если есть аргументы против, прошу озвучить. Ну, и вообще любые
соображения по поводу озвученного.

Просто сейчас самый момент вносить какие-то такие изменения: переезд -
это всегда гемор, и после переезда всегда какой-то ремонт, хотя бы
косметический. А тут назрело. И в другой момент уже ничо менять нельзя.

--
HZ

[Anton Gusev]

Harry Zhurov пишет 18.09.2015 17:11:

> В общем, я бы изменил это на:
>
> /core
> /port
> /ext

Раз все молчат, выскажусь я. Мы с Гарри это в аське уже обсуждали,
поэтому я пишу этот текст чтобы помочь принять решение остальным участникам.

Сначала я возражал, ибо такое изменение добавляет возни при обновлении
проектов на новую версию и при просмотре истории. Но потом, подумав,
согласился. Тут ведь главное что? Чтобы создание и улучшение оси
приносили удовольствие, моральное удовлетворение. Поэтому такие, на
первый взгляд, незначительные вещи, как

> длинные имена с заглавной буквы... фу.

- очень важны. Так что, если есть возможность сделать так, чтобы было не
"Фу", то это надо делать однозначно :)

[Андрей Чуйкин]

Безусловно новые названия лучше.

> -----Original Message-----
> From: scmrt...@googlegroups.com [mailto:scmrt...@googlegroups.com]

> On Behalf Of Anton Gusev
> Sent: Monday, September 21, 2015 2:57 PM
> To: scmrt...@googlegroups.com
> Subject: Re: Организационные вопросы
>

[Sergey Borshch]

On 18.09.2015 15:11, Harry Zhurov wrote:
> Всем привет!

> 3. Переделка системы подключения к сорцам ОС в проектах. Т.е. вместо
> svn:externals надо будет внедрить git-submodule. Это основное по
> сложности и трудоёмкости.

В своих проектах храню копию ОС, менять придется только в примерах к
порту. Тут вам придется нас научить.

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

Да, логично.

> /core
> /port
> /ext
>
> Коротко и внятно.

И логично. Поддерживаю.


--
Regards,
Sergey A. Borshch mailto: sb...@users.sourceforge.net

[Harry Zhurov]

Всем привет!

Итак, уважаемые участники и гости проекта, имею честь сообщить, что
работа по переносу проекта под управление системы Git успешно завершена.
В настоящее время в проекте имеется два репозитория:

1. непосредственно исходные коды ОС;
2. примеры использования.

Как уже говорилось прежде, перенос с svn на git объективно потребовал
изрядного изменения в структуре директорий, поэтому там внешний вид
несколько отличается от предыдущего варианта, заодно схема именования
файлов проекта приведена "к одному знаменателю", и по факту теперь не
один репозиторий, а два.

https://github.com/scmrtos/scmrtos
https://github.com/scmrtos/scmrtos-sample-projects

В примерах код ОС подключен как подмодуль.

Для удобства работы и поддержания "красивой" истории репозитория
предлагается опредённая методика ведения проекта. Она подробно изложена
на специальной странице wiki проекта:

https://github.com/scmrtos/scmrtos/wiki/Development-rules



Технические подробности.

Репозиторий ОС переносился с sf.net/svn, по возможности все комиты взяты
как есть с сохранением авторов (и их реквизитов - git требует имя и
email). Поскольку у git используется совсем иной подход к организации
веток, то ветки из svn репозитория не переносились, тем более там их
было всего две старых ветки, которые просто не удалили после слияния.
Все прежние релизы извлечены в виде помеченных комитов, кроме этого, по
стволу комитов расставлены метки на точках, соответствуюих релизам, т.ч.
при желании можно будет легко найти все реперные точки прежней разработки.

Момент окончания работы на sf.net/svn помечен меткой 'sf-end', затем
идёт небольшой линейный участок работы по перестройке структуры и прочей
"косметики", затем стоит метка 'gh-begin' (gh: github), и этот комит
знаменует начало работы с использованием основного репозитория проекта
на github'е.

Если посмотреть граф истории (например, с помощью gitk), то видно, что с
этого момента история отличается от прежней - линейной. Дальше работа
ведётся по правилам, описанным по вышеприведённой ссылке.



Из изменений по коду.

Код кое-где причёсан.

Удалена поддержка scmRTOS_OBSOLETE_NAMES.

Добавлено расширение round-robin manager и соответствующие примеры
(msp430/iar, blackfin/vdsp, stm32F2xx/iar).

Всё можно посмотреть в истории на гитхабе.



Планы.

В перспективе будет ещё добавлен репозиторий для документации и,
наверное, репозиторий для релизов, хотя это ещё надо обумать, обсудить.

Ну, и поскольку на гитхабе неплохо реализован движок wiki, по-видимому,
будет предприянта попытка документацию (мануал и остальное) постепенно
выложить на страницы wiki, это будет удобно во многих случях - быстро
что-то посмотреть или кинуть ссылку при обсуждениях тут и на форуме.



Итого. Поздравляю всех с началом нового периода развития проекта и
приглашаю к участию! :)


--
HZ

[Harry Zhurov]

--
HZ

[Anton Gusev]

Harry Zhurov пишет 23.10.2015 18:46:

> Итого. Поздравляю всех с началом нового периода развития проекта и
> приглашаю к участию!

Ура!!!

[Чуйкин Андрей]

Ура, товарищи.

И вот у меня сразу такой вопрос.

Глянул сейчас на расширения и увидел, что каждое из расширений состоит из одного файла, но лежит в собственном подкаталоге. Мне кажется это очень громоздко. Чтобы включить расширение придется писать: #include "scmRTOS/ext/round-robin/round-robin.h

Может быть делать так. Если расширение состоит из одного файла, то оно находится в ext. Если расширение - это несколько файлов, то оно кладется в подкаталог.

?

пятница, 23 октября 2015 г., 19:31:26 UTC+6 пользователь Harry Zhurov написал:

[Чуйкин Андрей]

P.S. В шапках всех файлов ссылка на sourceforge осталась.

[Harry Zhurov]

26.10.2015 15:22, Чуйкин Андрей пишет:

> И вот у меня сразу такой вопрос. Глянул сейчас на расширения и
> увидел, что каждое из расширений состоит из одного файла, но лежит в
> собственном подкаталоге. Мне кажется это очень громоздко. Чтобы
> включить расширение придется писать: #include
> "scmRTOS/ext/round-robin/round-robin.h Может быть делать так. Если
> расширение состоит из одного файла, то оно находится в ext. Если
> расширение - это несколько файлов, то оно кладется в подкаталог. ?

Ну, тут правил жёстких нет, но я бы не объединял. Например, вдруг
захочется что-то допилить и потребуется добавить файл - что, в этом
случае, переносить? Например, в этом же round robin пара функций
просилась в cpp файл (они всё равно вызываются), но мне лень было файл
заводить, функции небольшие, потому оставил один заголовок.

Что касается длинных некрасивых путей, так это не проблема - посмотри,
как сделано в примерах - там

#include <round-robin.h>

и всё. Чтобы компилятор находил это, достаточно добавить директорию с
расширением в пути, в makefile, SConstruct или у кого что.

> P.S. В шапках всех файлов ссылка на sourceforge осталась.

Это пока. Там же ссылка на документацию, и пока у нас дока тут не
выложена, пусть пока туда указывает.


--
HZ

[Чуйкин Андрей]

Ну, тут правил жёстких нет, но я бы не объединял. Например, вдруг
захочется что-то допилить и потребуется добавить файл - что, в этом
случае, переносить? Например, в этом же round robin пара функций
просилась в cpp файл (они всё равно вызываются), но мне лень было файл
заводить, функции небольшие, потому оставил один заголовок.

Согласен, это минус.

 

Что касается длинных некрасивых путей, так это не проблема - посмотри,
как сделано в примерах - там

#include <round-robin.h>

 А это с какой стороны посмотреть. Некоторые (в том числе и я ) предпочитают видеть откуда этот round-robin.h взялся. И по этому, путь полностью или частично указывается.

[Чуйкин Андрей]

Предлагаю такой, компромиссный, вариант. 

Структурировать расширения следующим образом.

Расширения, относящиеся к отладке складывать в подпапку dbg.

Расширения-сервисы в подпапку ipc (Inter Process Communication).

Расширения-планировщики в shedulers.

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

P.S. Просто я уже проходил вариант - каждому файлу своя папка. У меня был каталог drivers (аналог ext), в котором лежали драйвера, каждый в своей директории: adc.c/h в своей, lcd.c/h в своей и т.д. По началу все вроде было удобно. Но при некотором количестве драйверов это стало совсем неудобно. 

Я не думаю, что народ прорвет, и появятся десятки расширений. Но установить правила структурирования заранее, 'на вырост' что называется, будет наверное правильным.

понедельник, 26 октября 2015 г., 18:38:47 UTC+6 пользователь Чуйкин Андрей написал:

[Harry Zhurov]

26.10.2015 18:38, Чуйкин Андрей пишет:

>
> Что касается длинных некрасивых путей, так это не проблема -
> посмотри, как сделано в примерах - там
>
> #include <round-robin.h>
>
>
> А это с какой стороны посмотреть. Некоторые (в том числе и я )
> предпочитают видеть откуда этот round-robin.h взялся. И по этому,
> путь полностью или частично указывается.

А зачем тут путь (даже частичный)? И если хочется частичный путь - пиши,
а в настройках укажи путь поиска до этого пути.

> Предлагаю такой, компромиссный, вариант. Структурировать расширения
> следующим образом.
>
> Расширения, относящиеся к отладке складывать в подпапку dbg.
> Расширения-сервисы в подпапку ipc (Inter Process Communication).
> Расширения-планировщики в shedulers.
>
> При этом получается достаточно короткий и красивый путь к расширению
> с одной стороны, нет избыточности, что каждому расширению своя
> директория, с другой стороны, получается интуитивно понятная
> структура папок с третьей стороны.

Это хорошо, если эти три типа расширений покроют весь набор возможных
вариантов. А как быть, если завтра кто-то сделает поддержку TCP/IP стека
(Сергей Пинигин уже не первый год мне ненавязчиво намекает, что неплохо
бы такую штуку иметь в арсенале, и я уже начинаю потихоньку думать в
этом направлении, есть поле для применения). А послезавтра файловую
систему подпилить. И т.д. Будем добавлять категории (в каждой из которых
будет по одному экземпляру)? :)

Я бы пока это не трогал, пусть побудет так, там видно будет, как дело
пойдёт.

--
HZ

[Anton Gusev]

Чуйкин Андрей пишет 27.10.2015 09:08:

> Расширения, относящиеся к отладке складывать в подпапку dbg.
> Расширения-сервисы в подпапку ipc (Inter Process Communication).
> Расширения-планировщики в shedulers.

Так это только добавит лишний уровень в иерархию расширений.
Всё равно будет желательно, если расширение многофайловое (или если
просто содержит .cpp файлы), поместить его в свою отдельную директорию.

По крайней мере, моя система сборки устроена так, что берёт все *.cpp
файлы из указанных путей. Поэтому если несколько таких расширений будут
лежать в одной директории, то мне будет неудобно.

Я думал про такой вариант: однофайловые расширения можно помещать в
каталог ext, многофайловые - в каталог ext/name. Но тут тоже возможна
засада - что, если однофайловое расширение расширится, и перестанет быть
однофайловым? Тогда его придётся переносить в отдельную директорию. И
все проекты, которые его используют, перестанут компилироваться.

Так что, кмк, нынешняя система - оптимальная (по крайней мере по моим
критериям).