Running a Subversion server

tommiie

Active Member

Reaction score: 39
Messages: 152

Hey all,

I want to get started with Subversion (perhaps I should go for Git as there is quite an abundance of documentation on that) and part of that is setting up my own svn server—as, as far as I'm aware, there is no github for Subversion. Now I'm trying to figure out how to start svnliteserve at boot time. Are there flags for /etc/rc.conf like:

Code:
svnd_enable="YES"
svnd_flags="-r /var/svn"
I'm quite new to FreeBSD and although I'm currently reading the book Version Control with Subversion, Second Edition, I don't find it too illuminating.
 

malavon

Active Member

Reaction score: 75
Messages: 111

I personally would recommend going for Git and that's coming from one of the biggest SVN advocates a few years ago. Simply put, SVN was a better CVS.
Git on the other hand is completely different and just a more modern approach to versioning systems.
There are many reasons a big part of the world switched to Git from SVN and other versioning systems. For serious work, it's more powerful. For home use, it's just as easy as SVN.

On top of that there are Github, Gitlab, BitBucket and others that you can use without needing to set up a server yourself.
 

obsigna

Aspiring Daemon

Reaction score: 527
Messages: 909

In case you want to access the SVN service from outside, you want to consider to provide encrypted access. The easiest way is to use SASL, instead of HTTPS, since for the latter you need to install a web server. The SASL option became quite a bit forgotten, it is yet a very lightweight one. I wrote a BLog post, on how to install it:

 

Spartrekus

Aspiring Daemon

Reaction score: 136
Messages: 899

Hej

I would be keen to replace the SVN host I have and to use mine over SSH.

What is the process to tunnel and to install the SVN server on a freebsd machine?
 
OP
OP
tommiie

tommiie

Active Member

Reaction score: 39
Messages: 152

There are many reasons a big part of the world switched to Git from SVN and other versioning systems.
I've seen this trend also when researching versioning systems a bit but decided I should learn SVN since that's what FreeBSD still uses. I'm also not a big advocate of following the masses, e.g. look at systemd (and its heated discussion on this forum a few weeks ago).

But I will take your advice to heart and reconsider. It makes sense when learning about versioning systems to go with what most people are using, i.e. Git.
 

malavon

Active Member

Reaction score: 75
Messages: 111

I've seen this trend also when researching versioning systems a bit but decided I should learn SVN since that's what FreeBSD still uses.
Well, both ports and source are also mirrored in Github although it's read only. I don't think the project will switch to Git soon, I'm not even sure Git can be put in base legally (it's GPL licensed).
Then again, it'll never hurt knowing both SVN and Git.
Small note: Git actually has an SVN bridge (or whatever it's called) to use SVN as a backend for Git. Very useful when migrating, but also useful to use the power of Git on top of an existing SVN repo.
To be fair, Git does have more and more advanced commands than SVN has. But there's plenty of information around the internet to use them without hassle.

I'm also not a big advocate of following the masses, e.g. look at systemd (and its heated discussion on this forum a few weeks ago).
Agreed, never follow the masses.
In my case I had a few years of (advanced) professional Git experience before I switched myself but there's no way I'd ever even consider going back.
I'd say that's a good indication that it's a good choice.
Also, you'll be hard pressed to find real opponents to Git (that actually have substantial experience with it) whereas systemd is a really divisive piece of software.

Yesterday I forgot to actually answer your question :)
I used to have an SVN server set up using the svnserve wrapper of devel/subversion.
But that was from before there was a server in base, although I'm guessing it won't be very different to set up.
All I needed was to enable it in rc.conf, create a repo, add a user and that was all.
 

obsigna

Aspiring Daemon

Reaction score: 527
Messages: 909

I do all my programming for FreeBSD (service and tools, and GUI by providing a web interface) with Xcode on a Mac desktop. The FreeBSD machines, except one with a GNOME 3 desktop for testing purposes, are all headless.

Xcode happened to always have Subversion support nicely integrated, until Xcode 10, where Git is now the only choice. Not without moaning, I set up a Git service aside the already existing Subversion service on my main FreeBSD server, and I imported the most active Subversion repositories into it, using the git-svn-clone command - see (my BLog post in German):
This is now a few months ago, and I can tell you, I did not love Git before, and I neither do now nor won’t I love it anytime in the future. All this pushing and pulling feels like using the Plunger for clearing blockages in the flush toilet. Occasionally, you have to use it, but you don’t like it, and once done, you stow the ugly tool out of sight.

To begin with, for me the whole philosophy of distributed SCM systems is flawed. For me, the principle mis-concept is that code and structural improvements are smeared around a number of repositories up to a point where nobody can follow it up anymore, and eventually good work becomes lost. I am a chemist, and for me this is nothing else than production of entropy, i.e. hot air.

Git comes with countless subcommands with in-numerous of options, which do not seem to fit quite well into a logical hierarchy, but seem to have been added in an ad hoc manner in order to let a developer do an arbitrary job in the Git way of doing things, namely clearing a blockage.

The good news for all this mess is that we may use Git like it were Subversion. Although, sometimes, using Git is like pulling teeth at the dentist, that means it works, however don’t expect it to be painless. In any case, my advice to those wanting to use Git is to stay on the narrow road, and to put the focus on your source code and not on any sophistication of its management.
 
Last edited:

kpedersen

Daemon

Reaction score: 480
Messages: 1,355

If you are on an OS with a convenient SSH server (i.e not Windows ;) then Git and ssh is a pretty good choice. Otherwise svnserve is my favorite choice. I think it is a little bit crazy that Git doesn't come with an elegant single binary server or a secure protocol to use it.

Its a bit naff but I generally run svnserve from /etc/rc.local or even on cron @reboot on Linux because those cretins broke their rc.local XD.
 

Michael-O

Member

Reaction score: 5
Messages: 26

I've been running Subversion off Apache 2.2/2.4 for 8 years now combined with WebSVN. I can share my config if someone's interested. All necessary stuff is in the ports sytem. You can read this (needs an update) and exchange the auth for your needs.
 

malavon

Active Member

Reaction score: 75
Messages: 111

Since the thread seems to have died down, I'd like to take the time to address obsigna's post and hope both he and I can elaborate a bit.
It is quite off-topic though, so if OP (tommiie) would rather not pollute this thread just let me know.

First off this: like mentioned earlier I've used Subversion for a long time (10+ years) in a professional setting. Then I started using Git for 4 years in a likewise professional setting.
During those later years I also started teaching people how to use Git and get the most out of it (ease-of-use and productiveness). I noticed it's much easier to teach people Git
when it comes to branching/workflow management than it was to teach people Subversion.
Since I do intend to keep teaching people, it's always useful for me to have as many use-cases available, especially from people who do not like Git and would rather stick with SVN.

Not without moaning, I set up a Git service aside the already existing Subversion service on my main FreeBSD server
I don't know if this is something that's XCode-specific since I don't use IOS/Mac (I've been sleeping under the proverbial FreeBSD-desktop rock for 15 years now).
Could you point out why this is necessary? Personally I wouldn't do this with Git, but I can't think of a benefit with SVN either (though I haven't touched SVN in the past 5 years).
This is now a few months ago, and I can tell you, I did not love Git before, and I neither do now nor won’t I love it anytime in the future. All this pushing and pulling feels like using the Plunger for clearing blockages in the flush toilet. Occasionally, you have to use it, but you don’t like it, and once done, you stow the ugly tool out of sight.
To be fair, I've never used Git with the SVN backend in actual work besides migration. Could you elaborate what you mean with "all this pushing and pulling"? Isn't that the same in SVN?
To update from the remote repository, you'd git pull or svn update. It's more or less the same.
Sending data to the repository is a two-step process (commit & push) in Git though, but that comes with the territory and actually has a lot of really useful benefits.
To begin with, for me the whole philosophy of distributed SCM systems is flawed. For me, the principle mis-concept is that code and structural improvements are smeared around a number of repositories up to a point where nobody can follow it up anymore, and eventually good work becomes lost. I am a chemist, and for me this is nothing else than production of entropy, i.e. hot air.
I'm a bit puzzled by this. In the recommended use-case both Git and SVN have a central repository that everyone connects to.
If people don't commit (SVN) or commit/push (Git) their work, it won't be on the remote and that's true for most SCM's that I know.
The difference between a distributed and non-distributed system is that there are more options, but the most important difference is that everyone has the entire repository.
It's basically like having your own copy of the repo just like it is on the Subversion server. Switching between branches doesn't require a connection to the server at all, which wasn't possible
in SVN. When I used SVN, I used to have different "working copies" on my hard drive just to checkout multiple branches. Git does away with all this in a pretty clean way.
Caveat however is that it's possible to keep code on the local branch for longer and this might be what you meant. That has its advantages and drawbacks, but it's a decision made by the
people, not by the system.
Git comes with countless subcommands with in-numerous of options, which do not seem to fit quite well into a logical hierarchy, but seem to have been added in an ad hoc manner in order to let a developer do an arbitrary job in the Git way of doing things, namely clearing a blockage.
Definitely agreed when it comes to the commands and their options! Linus (the original creator of Git, same Linus as the Linux kernel one) went about this pretty chaotically.
There are advantages that commands are really powerful, but it makes teaching more difficult. I've noticed that it's mostly conforming to personal preference, where one person
will use commands A, B and C while someone else uses A, D and F to reach the same goals.
On the other hand, Subversion's branch management and merging is incredibly complex in a single command. This has been split up in Git into two commands ( merge
and cherry-pick), with one (extremely powerful) extra command: rebase. That last one would be enough for me to recommend Git to every developer in the world.
The potential improvement (depending on the developer) that this one command brings as far as commit quality and productivity goes, is massive.
The good news for all this mess is that we may use Git like it were Subversion. Although, sometimes, using Git is like pulling teeth at the dentist, that means it works, however don’t expect it to be painless. In any case, my advice to those wanting to use Git is to stay on the narrow road, and to put the focus on your source code and not on any sophistication of its management.
I'm not really sure why someone would like to do this. Git is more powerful than SVN, but it's not like SVN is a subset of Git. Certain things are done differently and knowing this really
enhances productivity. Management in Git is definitely less bad than it is in SVN once you're talking about branching and merging.
The age old adagio is however very true with Git: with power comes responsibility.

As a real-life example I'd like to direct you to a (hobby-level) port on my own Github. I have basically the same work on several branches, which is brought up to date with the remote a few
dozen times a week. Each time, several hundreds of commits are integrated without creating thousands of merge commits over the course of the past year.
Doing this merge work in Subversion would have made the entire endeavor a full-time job as far as branch & merge management goes and thanks to Git I can focus on making actual changes.

For the record devel/mercurial still exists. :)
To be fair, I wanted to learn it when I heard I had to learn Git and never gotten around to mercurial again. I heard a lot of good things about it though, but for some reason it seems to have
lost the marketing war. Just for that reason I should probably learn it, since popularity and quality rarely go hand in hand.
 

obsigna

Aspiring Daemon

Reaction score: 527
Messages: 909

I don't know if this is something that's XCode-specific since I don't use IOS/Mac (I've been sleeping under the proverbial FreeBSD-desktop rock for 15 years now).
Could you point out why this is necessary? Personally I wouldn't do this with Git, but I can't think of a benefit with SVN either (though I haven't touched SVN in the past 5 years)
Are you asking what’s the benefit of having SCM repositories on a dedicated server instead of on the client itself? In case no, please explain.

I always put central SCM repositories on a server. There were times, when I used a CVS server. This is beneficial when you are working in a dev team. This serves even as sort of a backup (not the only one, of course). This is nice if you own more than one computer. For example I regularly use two, a desktop machine and a notebook, and on both I have the full-fledged development environment. When I am in my office, I do development on the desktop, and commit the work to the server. When I am on travel, I use my notebook, and having access to the latest code by the way of the SVN server saved my ass already in some occasions. The SCM repo on a server is specialy useful when it comes to web development. The development machines run an Apache test web server on localhost. So, I do the development and test everything on localhost using a set of target web browsers. Once I am satisfied, I commit the changes, and for deployment, I do an svn update directly from the web-doc directories on the productions servers - of course, public access to the .svn or .git* directories is not allowed on the production machines. So yeah, I see a lot of benefits of having the SCM repositories on the server and working copies on the working or production machines, for me this is the natural order of things, and this has nothing to do with Xcode. However, most probably I misunderstood your question.

To be fair, I've never used Git with the SVN backend in actual work besides migration.
Perhaps another misunderstanding. I used the git svn clone command also only for migrating my most active development projects from the Subversion repository on the server to newly installed Git repositories on the same server. After the migration, both run independently, though. I did this because Xcode >= v10 does not support Subversion anymore. Even Git’s Subversion frontend would not have been very helpful in the given respect, since Xcode does no more support the original Subversion it would not support the svn frontend either. Now, if the actual question is, why I depend my SCM preferences on what is supported in Xcode, this is hard to explain to somebody who never saw how seamless SCM is actually integrated into Xcode. You would need to believe, that I swallow the Git toad for the sake of not loosing Xcode SCM integration, which since Xcode 10 is limited to Git only.

Could you elaborate what you mean with "all this pushing and pulling"? Isn't that the same in SVN?
To update from the remote repository, you'd git pull or svn update. It's more or less the same.
Sending data to the repository is a two-step process (commit & push) in Git though, but that comes with the territory and actually has a lot of really useful benefits.
Subversion: svn commit | svn update
Git: git commit (to the local clone) | git push (to the server) | git pull (to the local repo) | git push (to anywhere) | git pull (from anywhere) | git fetch (from an arbitrary remote) | git fetch, what? Git give me a break. And what the hell is a detached HEAD? I resolved that question using Time Machine, since in Git’s plungers toolbox, I could not find the right one after one hour of searching the web.

However, you’re right, the mere commands git commit/push replace svn commit and git pull replaces svn update. And this is what I meant that the good news is that we may use Git as if it were Subversion (note I did not say using svn commands as the frontend for git repositories), and leave all this sophistication to those who care to bother.

I'm a bit puzzled by this. In the recommended use-case both Git and SVN have a central repository that everyone connects to.
If people don't commit (SVN) or commit/push (Git) their work, it won't be on the remote and that's true for most SCM's that I know.
The difference between a distributed and non-distributed system is that there are more options, but the most important difference is that everyone has the entire repository.
It's basically like having your own copy of the repo just like it is on the Subversion server. Switching between branches doesn't require a connection to the server at all, which wasn't possible
in SVN. When I used SVN, I used to have different "working copies" on my hard drive just to checkout multiple branches. Git does away with all this in a pretty clean way.
Caveat however is that it's possible to keep code on the local branch for longer and this might be what you meant. That has its advantages and drawbacks, but it's a decision made by the
people, not by the system.
Yes, this is the benefit from the point of view of the single developer, however this may turn into a disadvantage for a dev team, when some not so disciplined developers are not that committed to push their changes. The single developer got his sandbox and may stay in there for ever if he likes. Also with Subversion you can work offline, you only need a connection in the very moment of committing and updating, however, it is more likely that the work makes it into the central repository. For example in an Xcode project source file list, I see a tiny M as an indication beneath modified files. This indication goes away once I execute svn commit on projects under Subversion control or git commit on projects under Git control. So, far so good for Subversion and bad for Git, since actually nothing needs to be pushed in order the developer receives his „Commit“-Satisfaction.

It may well be, that it is my personal problem that I am not ready for all this fantastic Git options. I will happily stay with git commit; git push (in one breathe) and git pull. Creating branches and merging was easy for me using subversion, and I understood what actually was going on. I read git-branch(1) and I understood nothing, and so I copied and pasted a command from StackOverflow.
 

Michael-O

Member

Reaction score: 5
Messages: 26

GitHub has had an SVN interface for quite some time.

I would not recommend using it. It is a custom implementation causing sometimes problems with svn(1). It does not use mod_dav_svn.
 

malavon

Active Member

Reaction score: 75
Messages: 111

I'm currently in the process of porting the next version of UE4 which takes up a lot of my spare time, so it took a while before I could revisit.
I might be able to help you out a little with the issues you have, answer some questions and possibly improve your productivity with Git.

I always put central SCM repositories on a server. <snip> So yeah, I see a lot of benefits of having the SCM repositories on the server and working copies on the working or production machines, for me this is the natural order of things, and this has nothing to do with Xcode. However, most probably I misunderstood your question.
I think the disconnect came from me assuming you were working on the FreeBSD project and thus using the FreeBSD SVN server.
What I read from your latest explanation is that the code is in only 2 places (dev systems, local server) whereas I was assuming you have it in 3 places
(dev systems, local server, remote server). If I understood it correctly, then yes, that is the natural order of things.

Like I said earlier, you should always have a central repository somewhere, whether you're using Git or SVN. That single repository is key to cooperation.
Yes, it's possible to use Git in a star-like pattern where every developer connects to every developer but I'm pretty sure such a workflow would quickly
fall under its own weight.

Small tip that might benefit you when using Git to deploy: using shallow checkouts on your production servers will consume less HD space and prevent
unnecessary fragmentation

Subversion: svn commit | svn update
Git: git commit (to the local clone) | git push (to the server) | git pull (to the local repo) | git push (to anywhere) | git pull (from anywhere) | git fetch (from an arbitrary remote) | git fetch, what? Git give me a break. And what the hell is a detached HEAD? I resolved that question using Time Machine, since in Git’s plungers toolbox, I could not find the right one after one hour of searching the web.

However, you’re right, the mere commands git commit/push replace svn commit and git pull replaces svn update. And this is what I meant that the good news is that we may use Git as if it were Subversion (note I did not say using svn commands as the frontend for git repositories), and leave all this sophistication to those who care to bother.
I think I can help you and anyone else who reads this thread through.
Assuming most people use Git with only a single remote (typically called "origin"), then there's no need for most of the distinctions you list above.
It is perfectly safe to not care about multiple remotes if you don't use it. In that regard, yes, Git can be used as SVN because SVN simply didn't have any
support for multiple remotes.

Now the question about detached HEAD is an interesting one because I've heard people ask it before. This one really comes from not understanding the
differences between Git and SVN. It's really well explained in this Atlassian tutorial towards the bottom. To understand it, you will need to understand
how Git works compared to SVN. Once you do, it'll make sense.
If I had a whiteboard here you'd understand it in a heartbeat. A drawing says so much more than words but I'll try.
The message says you were no longer working on a branch but had checked out a specific commit. If you were to add commits here, you'd still be in this
detached state. You could create a new branch from where you were and fix it like that. Or you could simply go back to an existing branch.
Since I'm assuming you didn't mean to branch out, a simple git checkout <branch-you-want-to-be-on> would have done the trick.

I'd like to add my personal experience from the first time I used Git. It was in a professional environment, I had 15+ years of of SCM experience and I had
Git explained to me by a (1-in-a-100) junior. While I had no issue understanding the basics, I didn't get the benefit of Git over anything else.
That all changed when I started getting errors like you did. Now you have to know that I'm the type of person who doesn't do things without understanding
what goes on. So I took a few hours to read up about how it all works and once I did that, it just clicked. From there, I went on to more advanced topics up
to the point that I (again :p) became the person that was teaching people.

Yes, this is the benefit from the point of view of the single developer, however this may turn into a disadvantage for a dev team, when some not so disciplined developers are not that committed to push their changes. The single developer got his sandbox and may stay in there for ever if he likes. Also with Subversion you can work offline, you only need a connection in the very moment of committing and updating, however, it is more likely that the work makes it into the central repository. For example in an Xcode project source file list, I see a tiny M as an indication beneath modified files. This indication goes away once I execute svn commit on projects under Subversion control or git commit on projects under Git control. So, far so good for Subversion and bad for Git, since actually nothing needs to be pushed in order the developer receives his „Commit“-Satisfaction.
I do understand your issue here, but I'm afraid that it's Apple that made your life more difficult. They could have easily added some indication that code
hasn't been pushed to the remote. Maybe they even added in an option somewhere, but like I said I'm not familiar with XCode.
Throughout my years I've seen juniors not commit their code (back on SVN) and I've seen juniors not push their code (on Git). It's really a basic thing to
do and I can't fault any software about this. If people don't send their code to the server, which is the easiest thing ever, I cringe to think what else they
forgot to do.
In a professional setting there are some extra checks (e.g. Jira can warn about changing the status of a ticket when no code is pushed), but it just comes
down to human error if it doesn't happen.

It may well be, that it is my personal problem that I am not ready for all this fantastic Git options. I will happily stay with git commit; git push (in one breathe) and git pull. Creating branches and merging was easy for me using subversion, and I understood what actually was going on. I read git-branch(1) and I understood nothing, and so I copied and pasted a command from StackOverflow.
Well, a man page isn't exactly the best place to find explanations about how the Git branching model works. I would really encourage you to take a step
back and read the documentation instead. If you knew nothing about branching in svn, the man page wouldn't help you either.
The official Git branching documentation starts here, but I really recommend reading more than just that chapter.

I'm not a big fan of StackOverflow as far as software goes, because of the very thing you posted here. I would never ever run a command that I don't
understand. There was a thread on this forum earlier where someone had this nice obfuscated shell command that - once executed - would simple
do an rm -rf /*. It was fun to see, but I'm betting someone executed it without verifying.

Back in the day you first started using CVS, didn't you have to read about how branching worked as well? While my branching experience with CVS was
limited, I surely had to learn how to use SVN branching.
Don't assume because you're an expert at SVN you can use Git without ever learning about it. I have plenty of experience with both and can tell you that
it simply doesn't work this way. You'll just be hating Git more the longer you're (forced to) using it.


To give an extra example about using multiple repositories etc I'd like to add a little part about how I currently use Git in my UE4 port.
What I'm doing there is really advanced stuff that goes a lot further than simple checkin/checkout. Using SVN this would be a massive mess. Using Git,
well, checkout the commands below. It's a testament to Gits power that this is possible.

So I have my main remote (origin) running on my personal GitHub. Epic has its own GitHub account.
In my local development environment I have both remotes set up. Each time Epic makes changes, I integrate these in my local copy and push them to
my Github. Remember when I said in my previous post that everyone has everything, just as if every developer's repository is the server?
That's why we're fetching changes from the remotes. In general, this is done automatically when using git pull but I also use it to see how
much new stuff there is.
It is important to note that nothing changes in my local copy of the code when doing this. That's why I'm not using git pull (which will automatically merge).
git fetch --all

Then the re-integration starts. I use rebasing for my workflow. This has advantages and disadvantages, but I'll leave it to the readers to find this out. I
consider this an advanced git command and it won't make sense how this works unless you actually understand how Git works (differently from SVN).
In this command I'll assume I'm rebasing my master branch on Epic's master branch. I might also have to fix some merge conflicts while running this.
git rebase -i epic/master

The last and final step is sending it all to my GitHub. I have to force push though. Never do this unless you know what the implications are.
git push -f
 
Top