Как стать автором
Обновить

Комментарии 44

Я пользуюсь, надеюсь в этом нет ничего плохого.
Плохого в этом нет вообще ничего. Ну разве что у SVN есть определенные ограничения, но вас они вполне могут не касаться. Скажем в мою бытность в Дойче банке у нас SVN хостилась где-то непойми где, судя по пингу — достаточно далеко, так что всякие операции типа merge релизной ветки куда-то в trunk могли проходить часами. На git такого скорее всего не будет, потому что он распределенный. Но вожможно будет что-то другое.
Разумеется!
Зачем Веб Клиент, если и в Шторме и в ВСКоде есть SVN плагины. Да и командную строку никто не отменял.
И еще — картинки бы не помешали.

Например, для тех, кто публикует свой код, полезной является поддержка Markdown для того, чтобы легче представлять развернутую документацию прямо в коде проекта.
В связи с широким распространением Git, начал было думать, что SVN почил в бозе. Рад, что это не так. С SVN связаны приятные воспоминания. На мой взгляд, основное преимущество SVN перед Git — это то, что SVN не дает возможности пользоваться им неправильно, а Git дает такую свободу действий, что далеко не каждый этой свободой может правильно воспользоваться.
Абсолютно согласен! SVN жив!
Где-то до начале 18-го года пользовался повсеместно SVN'ом и это вполне удобно.
Но потом всё-таки решил перевести всё на что-то иное. Провёл несколько исследований, git или hg, и выбор пал на hg.
(На текущей работе вплотную окунулся в git и убедился в том как же я был прав, что выбрал себе hg).

И да, в SVN тебе не дают сломать что-то по ошибке. Вообще, для небольших проектов очень даже неплохой выбор.

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

О, спасибо, так ещё лучше! Действительно, если нужно что то быстро глянуть на телефоне, то очень даже неплохой вариант.


В SVN, кроме проблем с ним самим (он периодически ломается и требует всяких cleanup-ов), больше всего огорчает единственный UI, который ещё не умер. Возможно если вам удастся дотянуть UI до уровня GitHub/GitLab (я именно про просмотр кода и истории, не про всё остальное), то получится современное и удобное решение.


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

Подскажите на примере, сравнения build-system и build-system репозиториев, что надо улучшить с точки зрения обзора кода. Например, можно сделать, так называемую «summary», страницу репозитория (если запрос идет прямо на корень репы), где показывать первые из списка бранчей, первые из списка тегов, первые строки из log (как правило log огромный, но первые 10 комитов уже могут быть полезны) и README.md из транка (если он существует) так, как это делается в cGit. Желательно учитывая разницу между принципами Git и SVN.


Очень нужны дельные советы.


Может быть у вас есть знакомые Web-дизайнеры, которые готовы потратить время на создание тем для интерфейса? Ведь продукт открыт для всех.

Я про UI в общем.


  • В GitLab файлы отображаются более разрежено (больше отступы между файлами), они отделенные друг от друга по средством тонкой границы, а не выделения разным бекграундом;
  • Больше свободного места по краям выделяет контент, нет ощущения перегруженности;
  • Не прокручиваемый хидер сверху меньше по размеру и не так сильно цепляется глазом;
  • Кнопки выглядят как кнопки, а не линки в таблице. То есть при просмотре файла (тоже возможно и для папки) есть действия с ним, закреплённые в верхней части — Это кнопка посмотреть log/blame. И это именно кнопки;
  • Управление ветками вынесено отдельно от просмотра кода. Хотя тут возможно это больше особенность svn;
  • Иконки файлов/папок;
  • Из мелочей создающих общую чистоту ещё немного другой шрифт (или его размер).

Ещё разные другие мелочи. Всё вместе это создаёт ощущение современного UI, так, будто ты работает с десктопным приложением. В общем много работы именно для UI дизайнера.


P.S.: Хорошего Web-дизайнера к сожалению не подскажу.

Спасибо за дельные советы. Поищем дизайнера. Надо делать разные темы, ведь «на вкус и цвет — товарища нет».
Спасибо за напоминание о скриншотах. Пренес ссылку в начало статьи.
Посмотрел — интересно. По функционалу мне нечего сказать, так как пользуюсь SVN на уровне checkout — commit. А вот насчет внешнего вида — «современный web-интерфейс» выглядит несколько устаревшим и чуть чуть печальным, из за сочетания серых тонов с темно красными ссылками. Спору нет, в плане оформления больших ошибок нет, все вроде правильно, но не хватает лоску. В 2020 ваше оформление не цепляет.

Сочетание серых тонов выбрано вот по какой причине: ведущие мровые проекты, такие как GCC, Linux Kernel, ncurses, Apache Subversion, не отличаются современным интерфейсом, наоборот, они сохраняют минималистичный интерфейс и не торопятся вводить новшества. Наверное этим они хотят показать, что главное — это суть проекта, а не его оформление. Именно по этому первый дизайн был построен в мнималистичных тонах для тех, кто работает.


Однако, поскольку оформление интерфейса описано в одном простом csvn.css файле, любой пользователь может создать собственную тему и выбрать любые стили подсветки синтаксиса с помощью переменной syntax-highlight-css в файле csvnrc(5).

Все просто — они забили на дизайн, и на них ровняться не стоит.

Вы говорите минималистический дизайн, хорошо, я за, но юзабилити не должен страдать:
откройте на большом мониторе например документация Linux, а потом дока Vue3. Что удобней читать? На сайте kernel.org приходится крутить головой: строки бесконечной длинны. А на сайте Vue длина блока текста ограничена, головой крутить не нужно, строка охватывается взглядом. Я уж не говорю про структуру визуальных элементов и т.д.

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

А в 2020 минималистический это — примерно так obsidian.md. Или так — github.com
Вот на кого надо ровняться.

Согласен с вами. Но надо учитывать еще то, что cSvn — это UI к репозиториям, а не GitHub или GitLab. В круг задачь cSvn не входит организация совместной работы community и ведение документации как таковой. Задачи cSvn схожи с задачами cGit.


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

Кстати, в палитре подсветки синтаксиса, также в основном присутствуют цвета из набора TERM=xterm-256color.
Распространение svn через github выглядит, как метаироничный стёб :)
Вы правы. Именно по этому мы не стали размещать даже зеркало репозитория cSvn на GitHub.
О! Кстати, https://svnhub.com до сих пор существует.
В определённое время это наверняка сподвигло некоторых на переход на гит в силу предоставленного упрощения процедуры.
Я тоже сначала начал делать зеркала на GitHub, потом перевел большую часть кода в Git, написал пару статей о Git, ну а за тем решил: а какого хрена? я взрослый, самостоятельный человек, почему я иду в этом строю?
Когда лет 10 назад я пользовался svn, то насколько помню в составе пакета шли два файла xslt и css, которые давали отличный результат и работали без вcяких дополнительных модулей (у вас еще нужен nginx + uswgi). При сопоставимом результате. Причем вся настройка заключалась добавлением пары строк в конфиг апача

Ради интереса посмотрел subversion-1.14.0.tar.bz2, эти файлы все так же поставляются — svnindex.css и svnindex.xsl.

А какие есть киллер фичи у csvn?

Главная «киллер фича» cSvn в том, что мы отказались от протокола WebDAV, который в полном объеме поддерживается только HTTP сервером ApacheNginx этот модуль урезан, а другие HTTP серверы могут вообще не поддерживать WebDAV). Это позволяет работать с любыми HTTP серверами, в том числе на встроенных системах, обращаться к репозиториям по протоколам HTTP, svn, svn+ssh. В конце концов, можно усовершенствовать cSvn CGI скрипт так, чтобы обеспечить работу и с Git репозиториями через inetd + git протокол.


Отказ от WebDAV открывает перспективы развития, а новомодные возможности делать комиты и пул-реквесты прямо в web-интерфейсе (а не из командной строки) нам не нужны. Практика показывает, что комиты из web-интерфейса, напрямую, приводят к серьезным интеграционным ошибкам и тормозят разработку.


А те два файлика, о которых вы говорите, привязывают вас к серверу Apache целиком и полностью.


А те два файлика, о которых вы говорите, привязывают вас к серверу Apache целиком и полностью.

А svn уже умеет напрямую через nginx работать? Лет 5 назад точно не умел и в списке рассылок видел, что и не планируют добавлять полную поддержку webdav

Нет. Вам нужно поставить и настроить Apach, а затем сделать как-то так:


#
# SVN from apache:
# ===============
#

#
# NOTE:
# ====
#
#   Console 'checkout' is allowed with both http:// and https:// URI protocol parts.
#
#

    server {
        listen 80;
        server_name svn.example.org;
        return 301 https://svn.example.org$request_uri;
    }

    server {
        listen 443 ssl;
        server_name svn.example.org;

        root /srv/www/htdocs/svn;

        client_max_body_size 32m;

        charset UTF-8;

        ssl on;

        #
        # see:
        #   https://developer.mozilla.org/en-US/docs/Web/Security/HTTP_strict_transport_security ,
        #   https://raymii.org/s/tutorials/HTTP_Strict_Transport_Security_for_Apache_NGINX_and_Lighttpd.html
        #
        # see also: http://classically.me/blogs/how-clear-hsts-settings-major-browsers
        # and do not include includeSubdomains; parameter into line:
        #
        add_header Strict-Transport-Security "max-age=63072000; preload";

        error_log /var/log/nginx/svn.example.org-error.log;
        access_log /var/log/nginx/svn.example.org-access.log;

        keepalive_timeout        60;
        ssl_certificate          /etc/letsencrypt/live/svn.example.org/fullchain.pem;
        ssl_certificate_key      /etc/letsencrypt/live/svn.example.org/privkey.pem;
        ssl_trusted_certificate  /etc/letsencrypt/live/svn.example.org/chain.pem;
        ssl_protocols            SSLv3 TLSv1 TLSv1.1 TLSv1.2;
        ssl_ciphers              "RC4:HIGH:!aNULL:!MD5:!kEDH";
        add_header               Strict-Transport-Security 'max-age=604800';

        location / {

           set $fixed_destination $http_destination;

           if ( $http_destination ~* ^https(.*)$ )
           {
              set $fixed_destination http$1;
           }

           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header Destination $fixed_destination;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

           proxy_pass http://svn.example.org:8043;
        }
    }

Тогда, Nginx предоставит вам WebSVN интерфейс.

И зачем еще один веб сервер, когда апач все это умеет из коробки?

Есть люди, которые не используют Apache, а предпочитают Nginx, как более быстрый и надежный HTTP-сервер.

Так вы сами себе противоречите. Nginx не поддерживает svn, т.е. вы предлагаете ставить nginx + uwsgi только для веб морды?


Но для работы с самим svn все равно нужен Apache. Или я что то не понимаю или nginx/uwsgi тут лишние, имхо

Работать с SVN можно разными способами. По протоколам svn, svn+ssh — Apache не нужен, по HTTP — Apache просто необходим. cSvn позволяет отказаться от Apache (если это необходимо) и, кроме того, использовать любой браузер. То есть cSvn освобождает администратора от необходимости ставить Apache. Вы просто меня не поняли: я вам дал пример того, чем были вынуждены заниматься администраторы, когда для того, чтобы предоставить HTTP-доступ к репам, им было необходимо ставить Apache, а для построение высокоскоросных серверов ставить Nginx (а два сервера им держать было не выгодно).

Ну такое. Высоконагруженные сервера не совмещают с svn, имхо. Насчет svn+ssh знаю, но неудобно админить. Когда у вас 300+ пользователей.


Я в свое время использовал ldap модуль, еще один плюс в копилку apache. У nginx я помню он был очень ограничен в свое время

Когда у вас 300+ пользователей, вы просто покупаете готовое решение на стороне (от ATLASSIAN, например).

Если есть куча лишних денег — то не вопрос. Ибо ценовая политика у них не гуманная. А так и SAP от оракла можно купить.


Я лишь пытаюсь сказать, что ставить на сервер nginx + uwsgi только для вебморды для svn — это overhead

до вчерашнего дня существовал лишь один достойный web-UI (WebSVN)

Вот про «лишь один достойный web-UI» не могу согласиться и поспорю. Какое-то у вас слишком пафосное заявление (и это мягко говоря). Есть интерфейс и значительно интереснее и современнее.

VisualSVN Server поставляется с действительно современным web UI для Subversion репозиториев. Попробовать его вы можете на публичном демо сервере. Можете, например, просмотреть зеркало репозитория Apache Software Foundation.

Кроме всего прочего, интерфейс поддерживает
* Поиск
* Blame
* Markdown
* Показывает PDF, DOCX, AI, PSD файлы прямо в браузере

web-UI (WebSVN), написанный на PHP и, к сожалению, отстающий от современных требований.

А как, подскажите, cSvn более современен чем WebSVN (кроме того что частично работает на JavaScript) или от web UI VisualSVN Server?
VisualSVN Server работает на OS Windows. Я же говорю об Open Source проектах.
И всё-таки в тексте у вас написано другое.
[[[
Это весьма позитивная новость для тех, кто использует централизованные системы версионного контроля по тому, что до вчерашнего дня существовал лишь один достойный web-UI (WebSVN)
]]]

Так точно — один. И называется он WebSVN github.com/websvnphp/websvn. А один он по тому, что кроме него простых и легковесных решений, когда человеку надо обеспечить Web-UI, а не поднимать структуру типа GitLab или Trac, не существует (ну не считая ViewVC, который стремится поддержать и CVS и SVN). А коммерческие решения и решения для MS Windows мы не рассматриваем, мы рассматриваем Open Source проекты типа cGit и WebSVN.


Более того, мы вообще предлагаем отказаться от протокола WebDAV и от взаимодействия с репозиториями на уровне файловой системы.

В общем случае, Web-UI не должен зависеть ни от типа HTTP-сервера, ни от типа репозиториев, которые он откидывает на клиента. Когда-нибудь Вы сможете листать код и даже не задумываться о том, на какой именно SCM он базруется. И только тогда, когда Вы захотите клонировать код на свою локальную систему, Вам нужно будет знать какими утилитами надо пользоваться. Тогда и вечные споры о том, кто лучше, а кто хуже прекратятся навсегда. На первое место встанет такое понятие как «целесообразность».


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

до вчерашнего дня существовал лишь один достойный web-UI (WebSVN), написанный на PHP и, к сожалению, отстающий от современных требований

И чем же Ваш личный проект лучше?

Пользовался несколько лет WebSVN, никаких неудобств не ощущал. Разве что нет выбора кодировки для индивидуального файла.
  • нет необходимости в HTTP-сервере Apache
  • возможность работы с различными HTTP-серверами
  • переносимость в том числе и на встроенные системы
  • современный интерфейс (в том числе и для мобильных девайсов)
  • возможность для пользователей создавать собственные темы, редактируя простой css
  • высокая скорость работы (написан на С)
  • поддержка Markdown, позволяет создавать документацию прямо в ветке исходного кода. Это полезно тем, кто не хочет делать отдельный сайт для презентации своей работы
  • пользователь легко может добавлять теги в header ( не только с помощью переменных csvnrc(5) ) для улучшения индексируемости поисковыми системами (наберите для прикола в поисковике Google 'csvn'). Причем, как для каждого репозитория в отдельности, так и для главной страницы индекса


Много всего, но, как говорится, на вкус и цвет товарища нет.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.