How to make a FreeBSD Subversion Server for newbies ?

Spartrekus

Spartrekus

Hello,

How to make a FreeBSD Subversion Server for newbies ?

It is a simple way over the pkg command line to get already a subversion server running. A bit like samba and apache2, easy to install.

Looking forward to hearing you.
Best regards
 
There are books on the subject. Installing from pkg is super easy. Configuration requires some reading mostly because you must decide which of many possible options.


1. Using the file prefix form is the easiest. It's server-less. You include the file:/// prefixed path to the repo to checkout or import.
# svn [op] file:///path/to/repo
2. I am guessing you want an actual SVN server. Setting up a server allows you to use the svn:///path/to/repo to access your repo. I prefer SASL for this but pkg SVN does not have SASL support. Build from ports to set the flag to enable SASL. Obsigna has a nice write-up on this as does the SVN book.
# svn [op] svn://host/path/to/repo
3. A simpler alternative is to use SVN+SSH. If you already know SSH, you're half way there.

So there's three high level paths to create your own SVN repo.
 
Just why ... subversion was nice as a cvs replacement, but it's slow and unflexible. Install git and be happy -- move repos whereever you like, access them however you like (fileshares, ssh, http, ...) -- no real need for a "server", it's distribited anyways, but there are nice options for hosting bare repos like gitlab or gogs/gitea ...

In fact, I really wonder why FreeBSD is sticking with svn :eek:
 
Zirias said:
Just why ... subversion was nice as a cvs replacement, but it's slow and unflexible. Install git and be happy -- move repos whereever you like, access them however you like (fileshares, ssh, http, ...) -- no real need for a "server", it's distribited anyways, but there are nice options for hosting bare repos like gitlab or gogs/gitea ...

In fact, I really wonder why FreeBSD is sticking with svn :eek:
Click to expand...
Subversion takes much less to install than github, and it is lighter than git.
 
rigoletto@ said:
You can't install GitHub unless you pay for the Enterprise version and no, Subversion is rather more complicated to deploy. IIRC it needs separated "servers" for code, logs, etc.
Click to expand...
Installation of a Subversion server is not complicated at all. We can have encrypted access via svnserve(8) and security/cyrus-sasl2 or alternatively via ssh(1). I wrote a BLog article about the first method: https://obsigna.com/articles/1532516645.html.

A Git server would be actually a Git client which you access by ssh(1). There is another Blog article which explains this, and how to migrate SVN repositories to Git. This article is in German language, though: https://obsigna.com/articles/1537496586.html. In English by the MS-Bing-Translator:
https://www.translatetheweb.com/?from=de&to=en&a=https://obsigna.com/articles/1537496586.html
 
unitrunker said:
There are books on the subject. Installing from pkg is super easy. Configuration requires some reading mostly because you must decide which of many possible options.


1. Using the file prefix form is the easiest. It's server-less. You include the file:/// prefixed path to the repo to checkout or import.
# svn [op] file:///path/to/repo
2. I am guessing you want an actual SVN server. Setting up a server allows you to use the svn:///path/to/repo to access your repo. I prefer SASL for this but pkg SVN does not have SASL support. Build from ports to set the flag to enable SASL. Obsigna has a nice write-up on this as does the SVN book.
# svn [op] svn://host/path/to/repo
3. A simpler alternative is to use SVN+SSH. If you already know SSH, you're half way there.

So there's three high level paths to create your own SVN repo.
Click to expand...
yes, but let's say, if you wanna co-work on a project with a friend, that does call your BSD server, with open ports, you shall use "file://// ... stuff"? Is it secured to leave the svn server running on the www?
'course you can tunnel over ssh, and give coworker the ssh account login/pass but then you shall want no shell. So, then, you need to ssh jail, but this is not really simple. Having a running svn with login/pass, is it sufficiently robust against asian whatever hacker attacks? SSH is quite robust, but svn ?
 
Spartrekus said:
say, if you wanna co-work on a project with a friend, that does call your BSD server, with open ports, you shall use "file://// ... stuff"? Is it secured to leave the svn server running on the www?
Click to expand...
The three examples I gave do not require a web server like apache or nginx. You access your repo entirely through the svn command, not a browser.

With the file:/// prefix - you are using the SVN client to read / write to a repo on your local file system. This is server-less - no svnserver.
With the svn://host/ prefix - your SVN client is talking to an svnserver. That server may or may not speak SASL2 (see Obsigna's comments above).
If it is only one person - file:/// is all you need. If you are working with a team - an svnserver is preferred.
A light weight compromise is SVN+SSH. This can be to an svnserver on the remote end. Getting it to work depends on your understanding of SSH.

One bonus of SSH is - unlike using svn://host/ access to svnserver - the SSH client can cache your credentials so you don't need to re-enter your password for every commit.

One SSH example is to create an SSH tunnel. Your svnserver listens to a port on the loopback address - which isn't internet routable. The SSH tunnel exposes this on the client end as a port on the client's loopback address. Your svn client thinks it is talking to a local svnserver. Your SSH port is exposed but your SVN server is not.

There is no TL;DR here. You will have to do some reading to understand the mechanics and the consequences.
 
Spartrekus said:
Subversion takes much less to install than github, and it is lighter than git.
Click to expand...
Did you even TRY to read or is this the next trolling thread? Apart from the "github" nonsense (as already pointed out), I explicitly mentioned software like gitlab (somewhat complex) and gogs or gitea (more on the simple side) IF you want to host bare repos with some nice web frontend.

But with git (contrary to svn), you don't NEED to host repos at all, as it's distributed by design, IOW, every working copy is a repo as well. When working as a team, you still WANT to host the repo somewhere (so you can push to a central/official place), and you can do a simple hosting (accessing the repo in the filesystem or with ssh) very easily with both git and svn -- I'd argue git is even a little bit simpler. If you want access by http, it gets a bit more complex for both, if you want a fancy web UI with it, it gets even more complex.

Telling svn is "lighter" than git is just nonsense. But git is (a LOT, like often factor 10 and more) faster and more flexible, git doesn't need network connection for doing commits, git allows easy modification of history to correct errors (if you're allowed to, which you are on your local repo -- mess up in svn means ignore it, and if it's a big mess, try to fix with horrible svndumpfilter as administrator on the single central repo), and so on. I don't see any reason to still prefer svn nowadays.
 
Well, I've seen this document before and it's quite old and also not very convincing, e.g. by just focusing on shortened citations from a Torvalds mail, even misinterpreting them.

The key "issue" is that a git repository is "atomic", so with a larger project, you either have to split it into many repositories (which is btw what KDE did) or live with the fact that you always have to clone everything. Git submodules (that work quite well when handled correctly) are just dismissed sloppily as "I don't buy that", although they would be a nice strategy to integrate across multi-repos. And, on the other hand, although FreeBSD is larger than Linux (whole OS versus just a kernel), it's not that much larger, and still smaller than KDE in its entirety. I'd say going with "single repo" would be quite feasible here as well, so the document probably discusses a non-issue. Working with git would be a more responsive experience for everyone, even with a single repo -- with svn, you wait tens of seconds before e.g. an "svn up" even starts to update something.

But then, of course, source control is just a tool, and if the tool works, you can work with it. It does work, obviously. In this recent FreeBSD survey, they asked whether I would contribute more if they switched to git. My honest answer is "probably not", because the tool isn't THAT important here. Unfortunately, noone asked about my happiness working with these tools ;)
 
Zirias said:
.......
In this recent FreeBSD survey, they asked whether I would contribute more if they switched to git. My honest answer is "probably not", because the tool isn't THAT important here. Unfortunately, noone asked about my happiness working with these tools ;) ...
Click to expand...
your statement catches my eye... very interesting question from the survey...
Although I had problems with e.g. git reflog when xCode quit support for svn and I wished that svn stayed in xCode , ....
I would answer the FreeBSD-survey-question clearly with: Yes, I would contribute more !

The last PR I made inside a FreeBSD-related project was an absolutely no brainer .
As Rigoletto said: There's even nothing to install.
Just copy&paste your code into GitHub , send PR, that's it.
Even if you were accidentally e.g. in the wrong local branch, everything is under control of the repository-owner.
The communication with the contributors is superb in Github !
Every day I get (git-automated) emails from the FreeBSD- git- project- communication from the devs , so I can follow the development-details even if I'm currently on another job or elsewhere .
So my next commits will be filled with uptodate- infos I read every day.
That is a tremendous advantage over everything other , it makes code & collaboration better and for my next commit I don't have to invest 500 hours for setups of 1000 tools on my machines and reading books and documentations of 5000 pages :) , always interesting to know details about tools but the code itself should get more attention than the other tools ...
 
drhowarddrfine said:
git is a distributed version control system. Not something you want when you have a multitude of developers but one controlling entity. That is where subversion is useful.
Click to expand...
Not sure how you come to that conclusion? Git is distributed, but that adds stuff, it doesn't remove anything. Normally, you just define "this is my official master repository" (in a big project, it'll be a hosted bare repository) and be good. The distributed approach scales much better with the size of your team (people actually CAN work when they're offline, they can even maintain their private branches without bothering others, etc...) and of course, you still have full control over your official repo.

Side note: at my job, we just (finally!) started using git with Microsoft's TFS instead of TFS' proprietary source control. Of course, the repository hosted on TFS is the official one, is still strictly controlled, any change is linked to an approved work item, and so on. Still, it is a huge improvement to always have your own local git repository.
 
unitrunker said:
The three examples I gave do not require a web server like apache or nginx. You access your repo entirely through the svn command, not a browser.

With the file:/// prefix - you are using the SVN client to read / write to a repo on your local file system. This is server-less - no svnserver.
With the svn://host/ prefix - your SVN client is talking to an svnserver. That server may or may not speak SASL2 (see Obsigna's comments above).
If it is only one person - file:/// is all you need. If you are working with a team - an svnserver is preferred.
A light weight compromise is SVN+SSH. This can be to an svnserver on the remote end. Getting it to work depends on your understanding of SSH.

One bonus of SSH is - unlike using svn://host/ access to svnserver - the SSH client can cache your credentials so you don't need to re-enter your password for every commit.

One SSH example is to create an SSH tunnel. Your svnserver listens to a port on the loopback address - which isn't internet routable. The SSH tunnel exposes this on the client end as a port on the client's loopback address. Your svn client thinks it is talking to a local svnserver. Your SSH port is exposed but your SVN server is not.

There is no TL;DR here. You will have to do some reading to understand the mechanics and the consequences.
Click to expand...
Thank you very much. it is awesome.

The ssh tunnel is pretty simple to make, however it does imply that the user will have a ssh + a jail. I am not a fan of jail or tweaking ssh to let any ssh access. The best is that svn is secured enough and robust enough under svn brute attacks. However, I doubt that it (svn) could be a way (open port) to attack a server.

That people prefer git or svn, it is of less importance. Discussions on color choices and preferences has not much relevance here.
 
You must log in or register to reply here.
Back
Top