Честно говоря, мужики, не стоит так распыляться на такое творчество)
Но. вытягивать одним архивом исходники, и версии для x32/x64 не стоит. Фар может без проблем запросить сначала версию, потом нужный файл для его платформы. Плагин, в идеале, должен собираться из stable ветки репа, куда её положит автор. Не знаю на счет запар с этим делом. Под юниксами виндовый бинарник врядли соберется. Если только под wine)) или еще как. А держать репозиторий на винде - врядли хорошая идея.
Плагины в фаре загружаются автоматически из любых папок. Это уже реализовано и работает многие годы. Если менять структуру - люди, привыкшие за 5-10 лет к одному и родному получать некий резонанс, да и выигрыша тоже не вижу, поэтому - не стоит. Но. Если страшно, что будут плагины с одинаковыми именами - нет ничего проще, чем генерировать хеш при создании в репе плагина. См. гугл хром, например. Этот же хеш-ключ используется для обновлений.
Вся эта беда, в целом, работает очень просто. Для ключа (будь-то имя или хеш или тупо номер) создаются потоки (atom, rss, xml, ... что угодно. хоть plain text). При запросе к ним фар получает, например, версию и сравнивает её. Почему не сразу пачкой - потому что для этого нужен скрипт на сервере или какой-то сервис-демон. Почему не как-то попроще? Потому что это самый просто и быстрый способ. Отдавать пользователю уже заранее готовый контент, который, к тому же, запрашивается по 500 раз и лежит в кеше. Веб-сервер даже с диска читать не будет при отдаче уже второму. Ну а файлы заранее собираются и готовятся из stable ветки плагина (того, что зальет автор - как именно он будет заливать - вопрос десятый). Надеюсь, алгоритм ясен)
Но я бы, на месте разработчиков, пошарил бы сначала уже готовые решения) Можно и svn, конечно, использовать для бинарников, не исключаю, что для исходников будет удобно, но это отдельная история. кроме девелоперов оно врядли надо кому, да и svn клиент должен быть плагином поставлен. Но бинарники. Представьте как реп будет проседать, когда по 500 человек в понедельник на воскресное обновление наскочат. Об этом тоже надо думать. И если отдавать 2 бинарника + исходники каждый раз - будет беда. Вообще, она так и так будет, но не в таком масштабе.
И кстати. Чего далего ходить, когда есть DEB, RPM репозитории. Pecl, CPAN, и прочие, и прочие... Просто смотрим, какой больше нравиться и используем его упрощенную версию. Там, все таки, из-за зависимостей все сильно усложнено. Хотя, если плагины фара будут зависить друг от друга: скажем, теоретичский IDE плагин FarPHP требует FarColorer, при чем версия 1 требует 5, а версия 3 уже FarColorer 6, а еще этот плагин требует установленный php для своих каких-то нужд
— т.е. вообще не плагин, но эта зависимость тоже может быть описана и высказана пользователю после установки. Опять же, если не надо будет в плагине прописывать проверку такого рода зависимостей, а фар сам будет знать, то ему будет проще ими управлять. Может появиться реальный менеджмент плагинов. Ладно. Ни к чему это)
bla-bla. bla.