# How to make a FreeBSD Subversion Server for newbies ?



## Spartrekus (Jun 27, 2019)

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


----------



## drhowarddrfine (Jun 27, 2019)

> How to make





> It is a simple way over the pkg command line


What is the purpose of this thread? Or, again, do you just want to hear yourself talk?


----------



## SirDice (Jun 27, 2019)

ChapterÂ 6.Â Server Configuration
		




			Version Control with Subversion


----------



## Spartrekus (Jun 27, 2019)

drhowarddrfine said:


> What is the purpose of this thread? Or, again, do you just want to hear yourself talk?



no no, I am interested by subversion owned by bsd server.

It is quite difficult to install.


----------



## unitrunker (Jun 27, 2019)

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.


----------



## zirias@ (Jun 27, 2019)

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


----------



## ucomp (Jun 27, 2019)

Zirias said:


> Install git   ....
> I really wonder why FreeBSD is sticking with svn


.. and I wonder what you wonder  









						GitHub - freebsd/freebsd-src: FreeBSD src tree (read-only mirror)
					

FreeBSD src tree (read-only mirror). Contribute to freebsd/freebsd-src development by creating an account on GitHub.




					github.com


----------



## zirias@ (Jun 27, 2019)

See the word "mirror"


----------



## ucomp (Jun 28, 2019)

yes but don't they plan to permanently migrate?


this seem to be the details :


			GitWorkflow - FreeBSD Wiki
		

.. I'm too lazy tonight to read or discuss the whole thing but it`s interesting


----------



## Spartrekus (Jun 28, 2019)

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


Subversion takes much less to install than github, and it is lighter than git.


----------



## drhowarddrfine (Jun 28, 2019)

Spartrekus said:


> It is quite difficult to install.


But you said earlier it was easy to install.


Spartrekus said:


> Subversion takes much less to install than github, and it is lighter than git.


So you know how to install it. Again I ask, what is the purpose of this thread? What is your question?


----------



## rigoletto@ (Jun 28, 2019)

Spartrekus said:


> Subversion takes much less to install than github, and it is lighter than git.



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.


----------



## obsigna (Jun 28, 2019)

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.


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


----------



## Spartrekus (Jun 28, 2019)

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.
> ...


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 ?


----------



## unitrunker (Jun 28, 2019)

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?


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.


----------



## zirias@ (Jun 28, 2019)

Spartrekus said:


> Subversion takes much less to install than github, and it is lighter than git.


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.


----------



## SirDice (Jun 28, 2019)

Zirias said:


> In fact, I really wonder why FreeBSD is sticking with svn


For your information: https://wiki.freebsd.org/VCSWhy. This is an interesting read too: https://wiki.freebsd.org/VersionControl


----------



## zirias@ (Jun 28, 2019)

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


----------



## SirDice (Jun 28, 2019)

Spartrekus said:


> no no, I am interested by subversion owned by bsd server.


FreeBSD development is done on devel/phabricator. 






						◉ Diffusion User Guide
					






					secure.phabricator.com


----------



## drhowarddrfine (Jun 28, 2019)

Zirias said:


> Install git and be happy


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.


----------



## ucomp (Jun 28, 2019)

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  ...


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 ...


----------



## zirias@ (Jun 28, 2019)

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.


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.


----------



## shkhln (Jun 28, 2019)

Zirias said:


> In fact, I really wonder why FreeBSD is sticking with svn



PHK doesn't like git.


----------



## Spartrekus (Jun 28, 2019)

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).
> ...


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.


----------



## drhowarddrfine (Jun 28, 2019)

Zirias said:


> Not sure how you come to that conclusion? Git is distributed, but that adds stuff, it doesn't remove anything.


Yes, I  said git is distributed. I didn't say anything about it removing anything.


----------



## Spartrekus (Jun 28, 2019)

Zirias said:


> 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.


----------



## malavon (Jun 28, 2019)

Spartrekus said:


> 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.


----------



## zirias@ (Jun 29, 2019)

drhowarddrfine said:


> Yes, I said git is distributed. I didn't say anything about it removing anything.


That's kind of a silly game, as ...


drhowarddrfine said:


> Not something you want when you have a multitude of developers but one controlling entity. That is where subversion is useful.


this clearly implies a distributed source control would hurt this (very common) scenario, which isn't the case at all.


----------



## Spartrekus (Jun 29, 2019)

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.


----------



## zirias@ (Jun 29, 2019)

Spartrekus said:


> 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.


----------



## Spartrekus (Jun 29, 2019)

Zirias said:


> 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.


----------



## kpedersen (Jun 29, 2019)

I find it to be easier to set up a self contained Svn server with *virtual accounts* than Git.


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


```
$ 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.


----------



## Spartrekus (Jun 29, 2019)

kpedersen said:


> It is a lot easier to set up a self contained Svn server with virtual accounts than Git.
> 
> 
> ```
> ...



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.  ...


----------



## zirias@ (Jun 29, 2019)

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


----------



## drhowarddrfine (Jun 29, 2019)

Zirias said:


> this clearly implies a distributed source control would hurt this (very common) scenario, which isn't the case at all.


That's a different statement than what you said earlier. You said that I said git wasn't distributed. I never said that.


----------



## zirias@ (Jun 29, 2019)

drhowarddrfine said:


> 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


----------



## kpedersen (Jun 29, 2019)

Zirias said:


> 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.


----------



## zirias@ (Jun 29, 2019)

kpedersen said:


> 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.


----------



## Spartrekus (Jun 29, 2019)

Zirias said:


> 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 
	
	



```
rm -rf .ssh
```
 regularly.

More reading: https://www.secureit.com/resources/SSH_Key_Associations_Article Final.pdf


----------



## obsigna (Jun 29, 2019)

Zirias said:


> ...
> 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.“


----------



## ucomp (Jun 29, 2019)

obsigna said:


> 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 ;-)


----------



## ralphbsz (Jun 29, 2019)

Spartrekus said:


> ~/.ssh/authorized_keys  is the best huge security breach ever. Better to do
> 
> 
> 
> ...


DO NOT LISTEN TO THIS ADVICE. IT IS NONSENSE. THIS USER UNDERSTANDS NOTHING ABOUT SECURITY.


----------



## obsigna (Jun 29, 2019)

ucomp said:


> 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.
> 
> ...


----------



## obsigna (Jun 29, 2019)

ucomp said:


> 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.
> 
> ...


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.


----------



## Spartrekus (Jun 29, 2019)

obsigna said:


> In addition, this better relates to the self*-*harm which people are doing by using Git instead of Subversion.


Why did you write this? what is the meaning behind?

Get root, copy the keys, and hack distant.


			https://www.secureit.com/resources/SSH_Key_Associations_Article%20Final.pdf


----------



## xtremae (Jun 29, 2019)

obsigna said:


> 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?


----------



## ucomp (Jun 29, 2019)

obsigna said:


> ...
> 
> 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.


----------



## obsigna (Jun 30, 2019)

ucomp said:


> ... 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.


----------



## obsigna (Jun 30, 2019)

xtremae said:


> 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.


----------



## drhowarddrfine (Jun 30, 2019)

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.


----------



## unitrunker (Jun 30, 2019)

I feel like the forum mods should split this into two discussions - one as a "how to" and another as a "SVN vs. git" discussion.


----------



## Spartrekus (Jun 30, 2019)

unitrunker said:


> I feel like the forum mods should split this into two discussions - one as a "how to" and another as a "SVN vs. git" discussion.


dont worry much. the thread runs out.


----------



## kpedersen (Jun 30, 2019)

unitrunker said:


> and another as a "SVN vs. git".



I personally would rather Vim vs Emacs (I haven't heard this argument for years!)
Or possibly a C/C++ vs <incorrect technology> (Still a popular argument)

Other than avoiding Perforce, I don't think I really have a preference on any VCS. They all have pros and cons (Perforce only has cons .


----------



## ucomp (Jun 30, 2019)

obsigna said:


> .... 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).....


... apparently urged by xCode ?


----------



## obsigna (Jun 30, 2019)

ucomp said:


> ... apparently urged by xCode ?


Yes, Subversion support has been discontinued in Xcode 10. Then I migrated my most active development projects to Git. Later I found out, that I may have several Xcode versions on my development machine side-by-side, and for the time being I leave my other projects in Subversion.


----------



## ucomp (Jun 30, 2019)

obsigna said:


> Yes, Subversion support has been discontinued in Xcode 10. Then I migrated my most active development projects to Git. Later I found out, that I may have several Xcode versions on my development machine side-by-side, and for the time being I leave my other projects in Subversion.



seems that  I'm a clairvoyant ;-)
 as I said: 


ucomp said:


> ...
> I wished that svn stayed in xCode , ....


----------



## ralphbsz (Jun 30, 2019)

kpedersen said:


> Other than avoiding Perforce, I don't think I really have a preference on any VCS. They all have pros and cons (Perforce only has cons .


I would like to respectfully disagree. I used Perforce (a.k.a. P4) for about three years, about 10 years ago. It was excellent. The most important part was that it was powerful (really good merging engine, for getting stuff merged up and down branches), while being easy to use. For really simple workflows (non-branched development with a central repository and only 2-3 active developers), it was as easy to use as CVS, and we had a cheat cheat that translates CVS commands to P4 commands. 

At the time, we compared it to the free offerings (for example CVS, Git, Subversion...), and to commercial offerings (for example ClearCase, BitKeeper, CMVC...), and it was considerably better than any of the competitors. We ran a little test with one of our more gnarly merges against several free offerings, and they all failed horribly, and would have required lots of manual rework. 
One of the best features of it was excellent support: If we needed help with something non-obvious, we called the support group (which was fortunately in our own time zone), and within an hour we had help.

But SCM is a very personal thing, and I can believe that other people had very different experiences. Personally, I'm currently switching to Mercurial for my own home stuff, and quite happy with it,.


----------



## kpedersen (Jun 30, 2019)

ralphbsz said:


> I used Perforce (a.k.a. P4) for about three years, about 10 years ago. It was excellent.



I just remember having to get it running on our build server; the individual workspaces were a real pain to manage. I think I recall the company charging extra for additional seats for each "workspace" that a user had too; including our build bot. It just made it impractical.
At that point the client wasn't open-source either and no development libraries for FreeBSD so we ended up having to scrub the text output for quite a few things. Just yuck.


----------

