Freeman

В программе freefilesync нет возможности организовать безвозвратное удаление файлов.

Ну дык его надо добавить. Программа ж с открытыми исходниками. В structures.h есть перечислимый тип:

enum DeletionPolicy
{
    DELETE_PERMANENTLY,
    DELETE_TO_RECYCLER,
    DELETE_TO_VERSIONING
};

Он потом обрабатывается в synchronization.cpp:

switch (deletionPolicy_)
        {
            case DELETE_PERMANENTLY:
                deleted = zen::removeFile(filepath); //[!] scope specifier resolves nameclash!
                break;

            case DELETE_TO_RECYCLER:
                deleted = recycler.recycleItem(filepath, relativePath); //throw FileError
                break;

            case DELETE_TO_VERSIONING:
                deleted = getOrCreateVersioner().revisionFile(filepath, relativePath, onNotifyFileCopy); //throw FileError
                break;
        }

Добавить еще одно перечислимое значение, типа DELETE_SAFE, дописать обработку и пересобрать.

Есть еще Puran Defrag или Defraggler. На реальной машине Puran Defrag я иногда с дефрагментацией при загрузке (boot defrag) использую, но с задачей типа вашей не сталкивался.

Давайте угадаю: вы пытаетесь запустить 64-битный defrag в 64-битной ОС из 32-битного приложения? It is not recognized as an internal or external command operable program or batch file. :-)

Вот интересно... Я разрабатываю язык со встроенной поддержкой SOLID (в расширенном толковании), попробую ответить на ваш вопрос.

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

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

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

Данный ответ основывается на результатах оригинального исследования. :-)

Я вижу два решения.

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

Этот способ требует онлайн-доступности обоих частей, иначе обновление по svn:external будет зависать до истечения таймаута.

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

Если же частичное зеркалирование невозможно или работает не так, как вам хочется, при помощи svnsync можно расширить первый способ: в обоих филиалах завести полное зеркало и svn:external натравить уже на него. Тогда онлайн-доступность не потребуется, можно будет синхронизироваться как удобно. Издержки с "пишем в одно место" -- "качаем для сборки из другого" останутся.