How to make a FreeBSD Subversion Server for newbies ?

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.

Ziria, the very best is when SVN is hosted by yourself, on your own FreeBSD machine ;)
FreeBSD the power to serve.
 
Ziria, the very best is when SVN is hosted by yourself, on your own FreeBSD machine ;)
No idea why I'm even saying this (again - it was in other posts before). Setting up a Git "server" is not more difficult than setting up a subversion server.
So for once and for all: anyone, including you Spartrekus, can set up their own Git server on their own hardware running the OS you want. That includes FreeBSD.
No need to install other software than Git. No Microsoft involved either. Just FreeBSD and GPL licensed code.
There you go.

And on the topic of the post: it's also been replied to your specific questions before on this very forum. Either you're sharing your account or you're just deliberately
taking away valuable time from forum members to post on other topics or do something more constructive like writing (free or commercial) software.
Please stop that, it's quite rude.
 
4malavon:

Why SVN?

KIMM principle.
Keep it minimalist and maintainable.

Subversion has just less libraries to be compiled. Easy to compile on a freebsd server with clang only and base.
 
devel/subversion: Depends on 7 libraries, installs at least 13 libraries.
devel/git: Depends on 4 libraries, installs none.

Next time, think and verify before you write.
thank you., thats true.... you are right.

I cannot get svn 1.12 to save the password at all. sirdice mentioned a missing package, but it is into the new 1.12.
I copied .subversion dir, and it does not need a pass.
the newer versions of svn will by default ask for a pass all the time - it mihht seem but I dont check the src code.

I just compiled links2 on a machine with nothing installed, just clang. links2 is awesome, not requirements at all.
 
I find it to be easier to set up a self contained Svn server with virtual accounts than Git.

Code:
$ svnadmin create myrepo (create an empty repo)
$ vi myrepo/conf/svnserve.conf (edit permissions if needed)
$ svnserve -d --foreground -r . (run server)

Code:
$ svn co svn://localhost/myrepo (check out code... you probably want to mkdir trunk)

But most of the perceived difficulty with Git servers is these big heavy "GitHub" like sites that for some mad reason, people want to set up. Just use SSH with Git and it is used in pretty much the same way as CVS+SSH ;)

Hope this helps.
 
It is a lot easier to set up a self contained Svn server with virtual accounts than Git.

Code:
$ svnadmin create myrepo (create an empty repo)
$ vi myrepo/conf/svnserve.conf (edit permissions if needed)
$ svnserve -d --foreground -r . (run server)

Code:
$ svn co svn://localhost/myrepo (check out code... you probably want to mkdir trunk)

Hope this helps.

Thank you very much

You are the best really.

I believe in SVN, maybe we are today two for SVN and millions for GIT. ;)
Two for X11, and millions for Wayland. ...;)
 
virtual accounts? I'd argue this has very little benefit, you can achieve something similar by just editing some ~/.ssh/authorized_keys to configure members' ssh keys. It doesn't scale well with large teams, in which case you'd prefer some http hosted service, which requires additional software in either case.

But ok, if you really find this feature important enough to stick with svn, fine ;)
 
You said that I said git wasn't distributed.
Quote please. Well, you won't find any. We really don't have to play such games here ...

BTW, don't take this personal, I assume you might have misread my words somehow. Still this is a frustrating way to discuss things :eek:
 
It doesn't scale well with large teams, in which case you'd prefer some http hosted service, which requires additional software in either case.

I generally have 3 levels of version control I use:
  • up to 2 users - Git or even CVS over plain SSH
  • under 15 users - SVN + svnserve
  • 15+ users - Scm Manager or heavy GitLab + Git.
Svn just happens to fill that niche of slightly large teams but not quite enough to set up a a heavy Git server. I would very much like to see something like svnserve for git. The Git protocol git:// is a little bit weak and doesn't do authentication.
 
Svn just happens to fill that niche of slightly large teams but not quite enough to set up a a heavy Git server.
I see. Well, it's probably manageable with not more than 15 users, and probably slightly easier than requiring ssh keys for authentication. But then, I'd probably look for some http-hosted git solution with more than 5 users ;) It doesn't have to be the "monster" gitlab, something like gitea looks more lightweight, but in fact, I didn't test that so far.

If the alternative was using svn, which means slow commits and updates and no offline working and no local branches (and I don't say it's a bad system, it's just there are consequences in the centralized design), I'd personally prefer to install a slightly "heavier" solution -- that is, if using some free hosting like github, bitbucket, etc really isn't an option :)

Well, anyways, I see your point.
 
virtual accounts? I'd argue this has very little benefit, you can achieve something similar by just editing some ~/.ssh/authorized_keys to configure members' ssh keys. It doesn't scale well with large teams, in which case you'd prefer some http hosted service, which requires additional software in either case.

But ok, if you really find this feature important enough to stick with svn, fine ;)

It is better to let ssh the way it is for the SVN server.

~/.ssh/authorized_keys is the best huge security breach ever. Better to do
Code:
rm -rf .ssh
regularly.

More reading: https://www.secureit.com/resources/SSH_Key_Associations_Article Final.pdf
 
...
If the alternative was using svn, which means slow commits and updates and no offline working ...

Zirias, please give us a break insisting on everybody needs to abandon Subversion in favour of Git. Could you even imagine, that we got our own heads and perhaps are knowing what we are doing? You don't seem to see the point which drhowarddrfine got, when he emphasized that Git is a distributed SCM vs. Subversion is a centralized one. For example, take any one of the popular projects on GitHub, and count the there called forks (= clones), and find tons of them which got local changes (perhaps valuable ones - who knows) which never made it, and never will make it into the master repository. I said this already somewhere on this forum, and here again, for me as a physical chemist this is nothing else than generation of entropy, i.e. hot air. A centralized SCM inherently urges everybody to have more self-discipline. You know, when the Cat leaves the house, the Rats are dancing on the table. So, from the Cat’s point of view Subversion is great. Those, who don’t like discipline too much, perhaps might like Git more.

In regards to „slow commits“, of course Git is faster if you don’t account for the push. You know, git commit is not the same as svn commit. When comparing git commit && git push with svn commit then my impression is that Subversion does the job faster (at least when using svnserve(8) on the server side).

PS: Zirias, in another respect you’re right. Spartrekus seems to be a Troll, and I adhere to one of the Best Netizen’s Practices, „don’t feed the Troll.“
 
Zirias.....Those, who don’t like discipline too much, perhaps might like Git more.
.....
sorry, Sir obsigna, this is more your personal philosophy than reality although I understand what you mean( and I presume that you will understand what I mean).
In reality you will be "disciplined" by your code reviewers in a BSD-git project if you intend to do "undisciplined things"( whatever that should be).
And that is not a bad process of disciplining, it is very productive and more than interesting , of course with "disciplined" devs. :)

there will never be 1 line of unreviewed code in a BSD- git-Project, it's the opposite: it`s mandatory to review and if necessary discuss every line of code ...

so its funny as it is:
I reviewed your comment, disciplined you Ha Ha and the next time you'll find a bug in one of my comments and will discipline me 😂
same in git, but more based on facts than in forums ;-)
 
sorry, Sir obsigna, this is more your personal philosophy than reality although I understand what you mean( and I presume that you will understand what I mean).
In reality you will be "disciplined" by your code reviewers in a BSD-git project if you intend to do "undisciplined things"( whatever that should be).
And that is not a bad process of disciplining, it is very productive and more than interesting , of course with "disciplined" devs. :)

there will never be 1 line of unreviewed code in a BSD- git-Project, it's the opposite: it`s mandatory to review and if necessary discuss every line of code ...

so its funny as it is:
I reviewed your comment, disciplined you Ha Ha and the next time you'll find a bug in one of my comments and will discipline me 😂
same in git, but more based on facts than in forums ;-)
 
sorry, Sir obsigna, this is more your personal philosophy than reality although I understand what you mean( and I presume that you will understand what I mean).
In reality you will be "disciplined" by your code reviewers in a BSD-git project if you intend to do "undisciplined things"( whatever that should be).
And that is not a bad process of disciplining, it is very productive and more than interesting , of course with "disciplined" devs. :)

there will never be 1 line of unreviewed code in a BSD- git-Project, it's the opposite: it`s mandatory to review and if necessary discuss every line of code ...

so its funny as it is:
I reviewed your comment, disciplined you Ha Ha and the next time you'll find a bug in one of my comments and will discipline me 😂
same in git, but more based on facts than in forums ;-)
Are you elaborating about the difference between „be more disciplined“ = „disziplinierter sein“ vs. „being more disciplined“ = „härter diszipliniert (bestraft) werden“? In case not, please explain. I used and meant the first form in the first version of my post.

However, I am not a native English speaker, and it really may happen, that my phrases are wrong, incomprehensible and/or misleading, not to mention all the spelling and grammar errors. Although, sometimes usually in my dreams, somebody is insinuating to me that according to the Relativity Theory of Albert Einstein, my English is the correct one and everybody else is speaking wrong. In any case, waking-up, takes me back from relativity to reality, and I would happily accept somebody pointing me to errors in my use of the language, as long as the meanings of my phrases are kept intact.

Now, because other non-native English speaker may grasp better what I meant, I replaced „be more disciplined“ by „have more self-discipline“. In addition, this better relates to the self-harm which people are doing by using Git instead of Subversion.
 
In addition, this better relates to the self-harm which people are doing by using Git instead of Subversion.
Does your advice include people who contribute to upstream projects that use git? Should we stop harming ourselves and not contribute to those?
 
...

However, I am not a native English speaker....

Although I was born in The U.S , I guess it`s possible your English could be better than mine :)

Your contributions here are always technically top, so everything is good with you as an expert and English-speaker, sure.

But this time I really disagree because I met (at git) extremely disciplined (auf äusserste Genauigkeit bedachte) BSD hardcore professionals who could not be more professional. And they have no problems to work with git. Before I send a PR to them I think ten times what I have coded because I know they will hit me if I do something weird . 😂

maybe I am the stupid who misinterprets something because of the lack of knowledge of English terms :) but I guess we just have a different experience with BSD- git projects.
 
... just have a different experience with BSD- git projects.
No, just a misunderstanding. I don’t have any experience with Git-based BSD projects, however, I am sure that the people behind them are mere professionals, so the experience must be good. Yet the philosophy is a Subversion (centralized SCM) one, because sooner or later all valid/accepted modifications end-up in the main repository.

In addition, I am talking about the Git workflow from the Git user's point of view, and just my personal experience with it is less than not satisfactory. I was urged to setup a Git-repository on my server for my most active development projects, one of which is visible on GitHub as well (https://github.com/cyclaero/ContentCGI), so people should think twice before calling me a Git-noob. I wrote in another thread on this forums, „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.“

Example, I set up the Git-Integration Manager Workflow as it is laid out in the Git documentation. The idea of choosing this one was inspired by my successful use of the Subversion’s Vendor Branches Workflow, because both seemed to serve a similar purpose, namely having a common base repository (name it vendor or master) and several derivates which got some added features. The idea was, I maintain the common code in the vendor/master and only the additions in the derivates. With Git this ended up in a pushing/pulling orgy, after each change to the master.

People may tell me that Git is perfect, only my workflow does not fit. Maybe, however, according to the Relativity Theory, I claim, that my workflow is perfect, but only Git does not serve well my purposes.

I guess, what I want to say is, that Git is not the solution of all our SCM problems, and therefore I vote in, once people advise to abandon Subversion in favor of Git without even having a closer look on the given purpose. Once somebody got a question about Subversion on this forums, like in this thread, you can be 100 % sure, that the first or second answer is, „Do it with Git and all your problems are gone." My take on this is, craftsman choose the tool from their toolbox which fits best the purpose, and not the other way around, e.g. trying to do everything with a fancy cordless drill/driver, only because the manual screw drivers are so very outdated.
 
Does your advice include people who contribute to upstream projects that use git? Should we stop harming ourselves and not contribute to those?
No. What I am saying is, don’t use Git if you don’t need to, otherwise you might be hurt. In this respect, contributing to upstream projects is mostly painless as far as commit/push/pull is concerned. The painful stuff is done by the project's admins behind the scenes.
 
To be clear, obsigna is making my point very clear about distributed versus centralized version control. A large project such as FreeBSD needs a centralized control system and cannot and should not be distributed among thousands. That is how you lose control.
 
Back
Top