FreeBSD src repository has transitioned from Subversion to Git(cgit.freebsd.org)
cgit.freebsd.org
FreeBSD src repository has transitioned from Subversion to Git
https://cgit.freebsd.org/src/commit/?id=5ef5f51d2bef80b0ede9b10ad5b0e9440b60518c
5 comments
I use SVN at my job and I gotta say I kind of prefer it to Git. Feels much lighter and the commands make a lot more sense to me
That is until you start branching and merging a lot. If you just develop on trunk and basically only do update and commit, then of course svn is more ergonomic. The problem is all the drawbacks of trunk based development: difficult code reviews, no gating so trunk build can break.
>> until you start branching and merging a lot
SVN has 3 way merge too so this isn’t the issue it was in other VCS’s
>> The problem is all the drawbacks of trunk based development
Those were all addressed reasonably well by about 2014, e.g. upsource (my preference by far) or crucible. TeamCity’s merge after private build feature etc.
Ironically these days i see a big push to use git in a way that would work pretty well in svn too.
The biggest hassle with svn was long lived branches. Back then we encouraged devs to branch and then somehow smoosh it all back together (painful). Then we said ok do it more frequently in atomic commits (i liked that model) then DVCS took off largely in the open source world and now major dev houses (well i guess except google with p4 - but they do provide a git interface) all have come along for the ride.
Ironically with products like Stash/Bitbucket and Github Enterprise, we’re back to an SVN like model.
SVN has 3 way merge too so this isn’t the issue it was in other VCS’s
>> The problem is all the drawbacks of trunk based development
Those were all addressed reasonably well by about 2014, e.g. upsource (my preference by far) or crucible. TeamCity’s merge after private build feature etc.
Ironically these days i see a big push to use git in a way that would work pretty well in svn too.
The biggest hassle with svn was long lived branches. Back then we encouraged devs to branch and then somehow smoosh it all back together (painful). Then we said ok do it more frequently in atomic commits (i liked that model) then DVCS took off largely in the open source world and now major dev houses (well i guess except google with p4 - but they do provide a git interface) all have come along for the ride.
Ironically with products like Stash/Bitbucket and Github Enterprise, we’re back to an SVN like model.
The merge tracking that was tacked onto svn just isn’t reliable. Adding it as metadata isn’t a good enough solution. Shared medium/long lived branches such as version maintenance branches or shared dev branches invariably get merges “both ways” meaning the information of what’s merged where is sprinkled everywhere.
But I’d go even further and say: svn isn’t even a good choice for a basic feature branch workflow. Not that it’s impossible, but the added “convenience” of svn is much smaller than the gains of git.
I don’t think the “D” in dvcs is important. As you point out, most people use git with a blessed central repo because that’s what we want.
But I’d go even further and say: svn isn’t even a good choice for a basic feature branch workflow. Not that it’s impossible, but the added “convenience” of svn is much smaller than the gains of git.
I don’t think the “D” in dvcs is important. As you point out, most people use git with a blessed central repo because that’s what we want.
I have used both SVN and GitHub Enterprise for work, and they are nothing alike.
For SVN, we mostly had long-lived "release" branches. Things like pre-merge code reviews were very hard. If you wanted to send some incomplete code, you sent an email with . tar.gz file attached.
With GHE, everyone makes branches all the time. It works great for code sharing or review. And there are unique advantages too, like an ability to run a distributed set of tests on arbitrary unmerged fork/branch, which rely on branches being very cheap.
For SVN, we mostly had long-lived "release" branches. Things like pre-merge code reviews were very hard. If you wanted to send some incomplete code, you sent an email with . tar.gz file attached.
With GHE, everyone makes branches all the time. It works great for code sharing or review. And there are unique advantages too, like an ability to run a distributed set of tests on arbitrary unmerged fork/branch, which rely on branches being very cheap.
Yep, SVN is simpler and easier for single developer / simplistic projects. GIT is much easier for larger multi developer concurrent development.
I like being able to commit while I am on a plane. (Not that this happens everyday, it’s more about the orinciple)
I like being able to commit while I am on a plane. (Not that this happens everyday, it’s more about the orinciple)
Git is actually simpler, here's why:
No central server to setup or required, period.
Whether it's doing it on your own or sharing with 100 random strangers, you don't have to setup an account for them.
Yes, SVN can handle patching, so you could email those patches also, but it's based on client-server, so someone has to setup the server and add new accounts.
Googlers have used it internally a lot as a client when their central server wasn't that, even though git itself struggled with the scale, which is why they hadn't changed over to it exclusively even server-side. If it was that complex, why would they do that?
No central server to setup or required, period.
Whether it's doing it on your own or sharing with 100 random strangers, you don't have to setup an account for them.
Yes, SVN can handle patching, so you could email those patches also, but it's based on client-server, so someone has to setup the server and add new accounts.
Googlers have used it internally a lot as a client when their central server wasn't that, even though git itself struggled with the scale, which is why they hadn't changed over to it exclusively even server-side. If it was that complex, why would they do that?
> Git is actually simpler, here's why:
> No central server to setup or required, period.
I've never seen a company work like this, though.
> No central server to setup or required, period.
I've never seen a company work like this, though.
Oh, you would be surprised how common this is.
If you don't need access control, it's the easiest way to get started with source control for small teams
If you don't need access control, it's the easiest way to get started with source control for small teams
> No central server to setup or required, period.
Someone should let every single person and organization that uses git know about this!
Someone should let every single person and organization that uses git know about this!
Maybe, maybe not.
As a developer I love that git gives me the ability to create my own repo anywhere on any machine, just with git installed. Repos can be synced and patches exchanged in numerous ways and any decentral copy is a full backup of everything.
But as someone having worked in larger companies, there are huuge red flags with this that you wouldn't want the wrong people in your company to know about. Fully functional repos anywhere means central control is impossible. You can't just limit access in any meaningful way, you can't control info leaks, if someone can carry out a git clone on an USB stick. And full repo with history means that you always know everything about the work performance of all colleagues, past and present.
As a developer I love that git gives me the ability to create my own repo anywhere on any machine, just with git installed. Repos can be synced and patches exchanged in numerous ways and any decentral copy is a full backup of everything.
But as someone having worked in larger companies, there are huuge red flags with this that you wouldn't want the wrong people in your company to know about. Fully functional repos anywhere means central control is impossible. You can't just limit access in any meaningful way, you can't control info leaks, if someone can carry out a git clone on an USB stick. And full repo with history means that you always know everything about the work performance of all colleagues, past and present.
> central control is impossible.
It's possible and we use it at work. Most major source control servers that support git also support user and role-based control over PR merges, force commits, etc.
There's little difference between a user that has a copy of the source as SVN and that of git, other than the git client itself allows the user to manage their commits on their local computer.
It's possible and we use it at work. Most major source control servers that support git also support user and role-based control over PR merges, force commits, etc.
There's little difference between a user that has a copy of the source as SVN and that of git, other than the git client itself allows the user to manage their commits on their local computer.
> no central server required
same with svn if that's your preferred workflow.
> you dont have to set up an account for them
of course not. they could just make a merge request.
Honestly I like both git and svn but I find this distinction to be contrived. I use svn in a decentralised manner daily with no problems
same with svn if that's your preferred workflow.
> you dont have to set up an account for them
of course not. they could just make a merge request.
Honestly I like both git and svn but I find this distinction to be contrived. I use svn in a decentralised manner daily with no problems
What makes Subversion easier for single developer projects?
I only remember having to manage a server being annoying. If you're not pushing anywhere, isn't the Git workflow essentially identical, minus the server management chores?
I only remember having to manage a server being annoying. If you're not pushing anywhere, isn't the Git workflow essentially identical, minus the server management chores?
so commit on a local repo and merge upstream later. imcrementally if prefered. i don't see the problem here.
SVN is also better at handling (large) repos with (large) binary files than GIT. So if you decide to store your scanned business documents in a version control system SVN is a better solution than GIT. So I use GIT for software projects and SVN for business documents.
Indeed. Subversion stores history on a per-file basis and not a per-project basis. This is one of the precious few areas where Subversion does best git.
> Subversion stores history on a per-file basis and not a per-project basis.
I think you may be getting confused with CVS, where if you commit multiple files each will get its own version number like “1.34”.
Subversion creates commits across the whole repository. All files and directories you want to check in get a single revision number like “123”.
I think you may be getting confused with CVS, where if you commit multiple files each will get its own version number like “1.34”.
Subversion creates commits across the whole repository. All files and directories you want to check in get a single revision number like “123”.
No, I mean in the on disk format, the history is stored per-file. This is why svn blame is massively faster than git blame, because git blame has to go through history for all files to find the right bits whereas svn does not.
The svn file format vs the git pack format are very very different on-disk.
The svn file format vs the git pack format are very very different on-disk.
That only works when your SVN server is in the same computer as you; the fact that SVN has to reach out to get additional data for the history is what kills it.
With git on the other hand, all the file storage is local to you machine regardless of which other remote git servers you may be using.
In addition, git blame doesn’t have to go through all history; the logical git storage model is object based on hash, so it’s really a set of queries for the contents of hash values that is used. Yes, it walks through commits, but at the lightweight metadata of trees which are akin to navigating a file system.
With git on the other hand, all the file storage is local to you machine regardless of which other remote git servers you may be using.
In addition, git blame doesn’t have to go through all history; the logical git storage model is object based on hash, so it’s really a set of queries for the contents of hash values that is used. Yes, it walks through commits, but at the lightweight metadata of trees which are akin to navigating a file system.
I used to think like that, but have eventually given up.
SVN is easier to learn and much more intuitive to use. But even if you're not a power user you get to its limits quickly. (E.g. svn afair does not support bisecting by itself, though there are external tools.) Given the world uses git you inevitably will have to learn git if you do anything with software.
SVN is easier to learn and much more intuitive to use. But even if you're not a power user you get to its limits quickly. (E.g. svn afair does not support bisecting by itself, though there are external tools.) Given the world uses git you inevitably will have to learn git if you do anything with software.
I prefer git’s model but you’re right; git commands don’t make any sense. Simple things (push, pull, commit, etc) are simple enough but it gets very quickly quite difficult to use without looking up a similar case on Stack Overflow.
They do make a lot of sense if you understand the underlying model (read gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7)). Its UI could be better, but it's good enough and some tools just require training to use effectively.
It takes about an hour to read and understand that documentation and I highly recommend doing so. And once you do git becomes far more intuitive. The key concepts to understand are commits and refs. To a first approximation a branch is just a variable ref and a tag is a constant ref. A commit is a node in a generally sparse upside down tree and refs are pointers to said nodes. Once one realizes that then pretty much everything makes sense. For example the difference between rebase and merge is how they affect the structure of the commit tree.
To add to that: learn how to use git-reflog. It's the most fantastic thing ever, let's you have a complete control over the local revision history to undo anything you want.
I think Git is a real pleasure to use. Personally, with git-reflog, I think it's really difficult to mess up in a git repo (but, of course, if there's a will, there's a way).
I've worked with SVN on several repos and projects, and it's the VCS I like the least. It's not intuitive at all, less shell-scriptable than CVS (how do you `cvs diff -r1.{1,2} file.c` in SVN?), less portable and takes more time to setup (e.g., effectively less UNIX). I think the ViewVC interface is also one of the worst out of any other option out there, be that CVSweb or gitweb, both of which have a better usability, in my opinion. SVN repository is also a 100% monolith, unlike CVS and even unlike Git (in Git, you can't ignore individual files like in CVS, but you still can ignore unrelated branches for a checkout, for example, without the need to renumber the whole thing, which is a requirement in SVN if you want to get rid of any branch). Basically, my personal opinion, is that the monolithic and inflexible SVN is just broken by design for any distributed and large project the size of a BSD. It's still puzzling to me why it was chosen over Git back in 2008, the same year that DragonFly did select Git as replacement for CVS. If anything, with DragonFly project being smaller, they had less of a need for Git than did FreeBSD.
I think Git is a real pleasure to use. Personally, with git-reflog, I think it's really difficult to mess up in a git repo (but, of course, if there's a will, there's a way).
I've worked with SVN on several repos and projects, and it's the VCS I like the least. It's not intuitive at all, less shell-scriptable than CVS (how do you `cvs diff -r1.{1,2} file.c` in SVN?), less portable and takes more time to setup (e.g., effectively less UNIX). I think the ViewVC interface is also one of the worst out of any other option out there, be that CVSweb or gitweb, both of which have a better usability, in my opinion. SVN repository is also a 100% monolith, unlike CVS and even unlike Git (in Git, you can't ignore individual files like in CVS, but you still can ignore unrelated branches for a checkout, for example, without the need to renumber the whole thing, which is a requirement in SVN if you want to get rid of any branch). Basically, my personal opinion, is that the monolithic and inflexible SVN is just broken by design for any distributed and large project the size of a BSD. It's still puzzling to me why it was chosen over Git back in 2008, the same year that DragonFly did select Git as replacement for CVS. If anything, with DragonFly project being smaller, they had less of a need for Git than did FreeBSD.
It is actually even simpler, a commit is a complete file tree with some message, other metadata and hashs of its parent commits.
A commit without parent is the initial commit.
A merge commit is simply a commit that has more than one parent commits.
In reality, you can put whatever content on whatever commits as long as these rule don't break.
The git is just the program that you used to merge the file tree, while you can disgrace with it with '--no-commit' and modified the merged file tree as you want.
A merge commit is simply a commit that has more than one parent commits.
In reality, you can put whatever content on whatever commits as long as these rule don't break.
The git is just the program that you used to merge the file tree, while you can disgrace with it with '--no-commit' and modified the merged file tree as you want.
You’re right, but missing the point. I know what commits and refs are. Every time someone says that the syntax is unnecessarily complicated, a lot of well-intentioned people react as if we did not know a thing about git. Some commands and manipulations are just very unintuitive and cumbersome.
I wonder if that's actually true. Nothing is stopping you or anyone else from releasing an entirely compatible new set of porcelain commands, and yet nobody has done so and gotten any traction. Also what do you mean by intuitive? Intuitive to someone who is trying to keep using CVS but with git, or intuitive to someone who actually understands the Git data model? Since it sounds like you're in the latter group, what would your ideal porcelain look like?
I know the model. And I have read the documentation, as well as the git book, and now a fair number of Stack Overflow (and similar websites) pages. I actually use git fairly often, and for day-to-day use it’s fine.
The problem is for more complex manipulations I do maybe every 6 months. The logic behind difference between commands and options is really not obvious, and some commands are very asymmetric (doing something can be simple and take one command; undoing it might take a completely different command with several options and complex references).
The concept is great and it works very well; the UI is terrible.
The problem is for more complex manipulations I do maybe every 6 months. The logic behind difference between commands and options is really not obvious, and some commands are very asymmetric (doing something can be simple and take one command; undoing it might take a completely different command with several options and complex references).
The concept is great and it works very well; the UI is terrible.
IMO the best part about SVN is that you can use git-svn to run it through git locally.
If only that was a thing for Perforce. There are some scripts but not really with proper streams support. Sigh.
If only that was a thing for Perforce. There are some scripts but not really with proper streams support. Sigh.
I've only ever really used git as a locally hosted SVN.
As the maintainer of FreshBSD.org, git gives me headaches regarding what to do with branch naming.
SVN and even CVS include branch information on each commit, but git couldn't care less - it's up to you to infer it by unspecified means if you really care.
It's telling that the conversion metadata includes tags indicating the SVN path identifying the branches a given commit was made from - because this otherwise wouldn't be available. In principle I can just use that, but I still need a reliable solution for new commits.
Not convinced I'll find one.
SVN and even CVS include branch information on each commit, but git couldn't care less - it's up to you to infer it by unspecified means if you really care.
It's telling that the conversion metadata includes tags indicating the SVN path identifying the branches a given commit was made from - because this otherwise wouldn't be available. In principle I can just use that, but I still need a reliable solution for new commits.
Not convinced I'll find one.
Isn't the reason for the problem is that multiple branches and tags may have any given commit? Same as in CVS? It seems like the problem is the UI that assumes that only a single branch may have any given commit.
---
BTW, whilst at it, any chance you can fix search by user-id? Currently freshbsd.org/search?project=freebsd&committer=phk doesn't produce the expected results.
---
BTW, whilst at it, any chance you can fix search by user-id? Currently freshbsd.org/search?project=freebsd&committer=phk doesn't produce the expected results.
No. The problem is that to git, a branch is just a reference to the commit currently at the tip of that branch - the rest of the commit graph is completely anonymous sans its position in that graph.
Where in SVN it's implicit in the paths a commit touches and in CVS it's a specific field in the RCS metadata for a commit, in Git it's a big graph problem it isn't overly interested in solving.
And yes, people keep asking about the legacy username thing - I'll get to it :)
Where in SVN it's implicit in the paths a commit touches and in CVS it's a specific field in the RCS metadata for a commit, in Git it's a big graph problem it isn't overly interested in solving.
And yes, people keep asking about the legacy username thing - I'll get to it :)
git name-rev?
Only handles a single symbolic name per commit, and doesn't necessarily pick one that's meaningful in that sense. It's what I'm trying to get away from.
e.g. projects/aio_writev has 8 commits, but if name-rev is allowed to name that branch, it'll gleefully use it to name thousands of commits to main as well.
e.g. projects/aio_writev has 8 commits, but if name-rev is allowed to name that branch, it'll gleefully use it to name thousands of commits to main as well.
Welcome to 2010s, FreeBSD!
Maybe getting rid of annoying to use mailing lists and git-email will be next? Who knows.
What's wrong with mailing lists? Is there anything better for general discussion than the mailing lists?
The problem with forums is that you can't really trust them. They're generally not archived well, UI is poor, editing of old messages can easily get abused (probably the reasons HN removes your ability to edit old messages shortly after posting).
Mailing lists are much less prone to censorship, are better for archival and preservation of knowledge (both for your own local archival, as well as the distributed global archiving of complete archives), interoperable, convenient and easy to use.
---
I mean, just take a look at GitHub issues. It's a total mess. Things get locked and deleted. Links get broken. Attracts thousands of useless comments on popular issues; never any sort of a summary for how the problem is resolved (if at all), the root cause of any issue, or why it won't be fixed. Any time I get a GitHub Issue as a hit, it's usually a total waste of time trying to make sense of it; much more so than the mailing list posts, which often have threading, less spam, and are easier to navigate. Yes, a special interface is a good thing in theory. But it's been a complete mess in practice.
The problem with forums is that you can't really trust them. They're generally not archived well, UI is poor, editing of old messages can easily get abused (probably the reasons HN removes your ability to edit old messages shortly after posting).
Mailing lists are much less prone to censorship, are better for archival and preservation of knowledge (both for your own local archival, as well as the distributed global archiving of complete archives), interoperable, convenient and easy to use.
---
I mean, just take a look at GitHub issues. It's a total mess. Things get locked and deleted. Links get broken. Attracts thousands of useless comments on popular issues; never any sort of a summary for how the problem is resolved (if at all), the root cause of any issue, or why it won't be fixed. Any time I get a GitHub Issue as a hit, it's usually a total waste of time trying to make sense of it; much more so than the mailing list posts, which often have threading, less spam, and are easier to navigate. Yes, a special interface is a good thing in theory. But it's been a complete mess in practice.
> What's wrong with mailing lists?
Inaccessible.
Terribly indexed.
Awful formatting tools.
Encourages un-followable discussion branching.
Increasingly broken with modern mailing security mechanisms.
> The problem with forums is that you can't really trust them. They're generally not archived well, UI is poor [...] Links get broken. [...] Attracts thousands of useless comments on popular issues; [...] They're generally not archived well.
All this also applies to mailing lists.
> Things get locked and deleted.
This deserves a longer reply. List archives get lost as well, if they were available at all. I do agree that deletion rights given to maintainers is a stupid idea, it's very prone to misuse. But mailing lists also have that, maintainers can simply block e-mails reaching the list. At least with deletion people subscribed to new issues will always get them (in the case of GitHub).
> Editing of old messages can easily get abused (probably the reasons HN removes your ability to edit old messages shortly after posting).
Forum config problem.
> Mailing lists are much less prone to censorship
[citation required] Pretty sure they all have some moderation tools or it'd get totally out of hand either due to spam or by malicious actors.
> never any sort of a summary for how the problem is resolved (if at all), the root cause of any issue, or why it won't be fixed.
That's not specific to the tech used for discussion.
> But it's been a complete mess in practice.
But still less of a mess than mailing lists and that's what matters.
Inaccessible.
Terribly indexed.
Awful formatting tools.
Encourages un-followable discussion branching.
Increasingly broken with modern mailing security mechanisms.
> The problem with forums is that you can't really trust them. They're generally not archived well, UI is poor [...] Links get broken. [...] Attracts thousands of useless comments on popular issues; [...] They're generally not archived well.
All this also applies to mailing lists.
> Things get locked and deleted.
This deserves a longer reply. List archives get lost as well, if they were available at all. I do agree that deletion rights given to maintainers is a stupid idea, it's very prone to misuse. But mailing lists also have that, maintainers can simply block e-mails reaching the list. At least with deletion people subscribed to new issues will always get them (in the case of GitHub).
> Editing of old messages can easily get abused (probably the reasons HN removes your ability to edit old messages shortly after posting).
Forum config problem.
> Mailing lists are much less prone to censorship
[citation required] Pretty sure they all have some moderation tools or it'd get totally out of hand either due to spam or by malicious actors.
> never any sort of a summary for how the problem is resolved (if at all), the root cause of any issue, or why it won't be fixed.
That's not specific to the tech used for discussion.
> But it's been a complete mess in practice.
But still less of a mess than mailing lists and that's what matters.
Which exact projects do you have in mind? Because none of the issues you identify seem to apply to the BSDs. We don't really have the notion of "maintainers", either, so, I'm guessing your comments aren't as a BSD user per se?
The BSDs have excellent archives of the mailing lists; FreeBSD, NetBSD and DragonFly have their own websites with complete or near-complete archives, including full threading and sub-threading support; all BSDs are also archived on marc.info, and plentiful of other sources, some of which do come and go; but archives themselves are downloadable in bulk from the underlying projects, so, archiving is generally a non-issue.
What formatting tools? Why would I need any formatting tools to hack the kernel? That's only a benefit that none are available.
Security mechanisms? How's GitHub any better? Anyone can make any account and pretend to be anyone. Or do you suggest GitHub introduce Account Verification, so that someone at Microsoft-owned GitHub could then decide whether or not you're an OSS contributor worthy of a Blue Checkmark to accompany your name? I think we did have people pretend to be de Raadt or Dillon over the years, but it's generally not really an issue; often just the April 1 jokes; very easy to verify based on headers.
> Forum config problem.
OK, now we're talking! So, how about all those forums fix their "forum config" problems, and then maybe we'll talk? Mailing lists are by far superior to what GitHub or any other popular forums actually do offer as of today. GitHub Issues, for example, doesn't even support threading within an Issue; unlike the mailing lists since decades ago. There's absolutely no archiving of GitHub Issues being done anywhere that I'm aware of, apart from user-initiated archive.today. So, even in such basic aspects, mailing lists are already superior. Not to mention that we have contributors from across the globe, whereas Microsoft disables (without notice) GitHub accounts of anyone who's a citizen or a visitor of the geographic places and peninsulas you aren't supposed to visit or originate from -- covering dozens of millions of global citizens, denying them access to code for no good reason.
The BSDs have excellent archives of the mailing lists; FreeBSD, NetBSD and DragonFly have their own websites with complete or near-complete archives, including full threading and sub-threading support; all BSDs are also archived on marc.info, and plentiful of other sources, some of which do come and go; but archives themselves are downloadable in bulk from the underlying projects, so, archiving is generally a non-issue.
What formatting tools? Why would I need any formatting tools to hack the kernel? That's only a benefit that none are available.
Security mechanisms? How's GitHub any better? Anyone can make any account and pretend to be anyone. Or do you suggest GitHub introduce Account Verification, so that someone at Microsoft-owned GitHub could then decide whether or not you're an OSS contributor worthy of a Blue Checkmark to accompany your name? I think we did have people pretend to be de Raadt or Dillon over the years, but it's generally not really an issue; often just the April 1 jokes; very easy to verify based on headers.
> Forum config problem.
OK, now we're talking! So, how about all those forums fix their "forum config" problems, and then maybe we'll talk? Mailing lists are by far superior to what GitHub or any other popular forums actually do offer as of today. GitHub Issues, for example, doesn't even support threading within an Issue; unlike the mailing lists since decades ago. There's absolutely no archiving of GitHub Issues being done anywhere that I'm aware of, apart from user-initiated archive.today. So, even in such basic aspects, mailing lists are already superior. Not to mention that we have contributors from across the globe, whereas Microsoft disables (without notice) GitHub accounts of anyone who's a citizen or a visitor of the geographic places and peninsulas you aren't supposed to visit or originate from -- covering dozens of millions of global citizens, denying them access to code for no good reason.
> Because none of the issues you identify seem to apply to the BSDs.
A lot of those issues are fundamental to mailing lists and e-mails. They do apply.
> What formatting tools? Why would I need any formatting tools to hack the kernel?
Having text formatting tools is really useful when communicating things. If you don't need it, okay, that doesn't negate its usefulness for others.
> Security mechanisms?
DKIM/DMARC/SPF. The rest of your paragraph is tangential, applies to the entire world and all tech where identities come to play, with a few smaller exceptions.
> So, how about all those forums fix their "forum config" problems, and then maybe we'll talk?
You do realize that's an absolutely ridiculous demand, it's up to the project to have a configuration they like.
> GitHub Issues, for example, doesn't even support threading within an Issue; unlike the mailing lists since decades ago.
That's a feature, not a bug.
> So, even in such basic aspects, mailing lists are already superior
Yet in so many others it lags so much behind. In all the aspects you very conveniently did not address in your last comment.
> Microsoft disables (without notice) GitHub accounts of anyone who's a citizen or a visitor of the geographic places
There are more options out there in addition to GitHub.
> Mailing lists are by far superior to what GitHub or any other popular forums actually do offer as of today.
That's a very absolute statement. Just calling it "superior" would've been a stretch, "far superior" is borderline delusional.
A lot of those issues are fundamental to mailing lists and e-mails. They do apply.
> What formatting tools? Why would I need any formatting tools to hack the kernel?
Having text formatting tools is really useful when communicating things. If you don't need it, okay, that doesn't negate its usefulness for others.
> Security mechanisms?
DKIM/DMARC/SPF. The rest of your paragraph is tangential, applies to the entire world and all tech where identities come to play, with a few smaller exceptions.
> So, how about all those forums fix their "forum config" problems, and then maybe we'll talk?
You do realize that's an absolutely ridiculous demand, it's up to the project to have a configuration they like.
> GitHub Issues, for example, doesn't even support threading within an Issue; unlike the mailing lists since decades ago.
That's a feature, not a bug.
> So, even in such basic aspects, mailing lists are already superior
Yet in so many others it lags so much behind. In all the aspects you very conveniently did not address in your last comment.
> Microsoft disables (without notice) GitHub accounts of anyone who's a citizen or a visitor of the geographic places
There are more options out there in addition to GitHub.
> Mailing lists are by far superior to what GitHub or any other popular forums actually do offer as of today.
That's a very absolute statement. Just calling it "superior" would've been a stretch, "far superior" is borderline delusional.
So, you haven't provided a single strong argument for how forums are superior, deferred proper functionality to a "forum config" that doesn't even exist anywhere, dismissed subthreading as a "bug" even though it's clearly been a very useful feature for decades, and then sprinkled the whole thing with "security" concerns that aren't even solved by the forums, and which noone really cares about anyways? Solid arguments to commence a change!
> it's up to the project to have a configuration they like
Exactly. Our mailing lists are far, far superior, than any alternative forum setups I've ever seen. I do insist it's not just "superior" to most forums, but indeed "far superior".
> Having text formatting tools is really useful when communicating things.
Then why do you even visit HN? There's no formatting tools available here, is there?
> it's up to the project to have a configuration they like
Exactly. Our mailing lists are far, far superior, than any alternative forum setups I've ever seen. I do insist it's not just "superior" to most forums, but indeed "far superior".
> Having text formatting tools is really useful when communicating things.
Then why do you even visit HN? There's no formatting tools available here, is there?
> So, you haven't provided a single strong argument for how forums are superior
I did, and actually you did too, but you also conveniently ignored those points. Which lets me know they hit the target very well.
> Our mailing lists are far, far superior, than any alternative forum setups I've ever seen.
Taking into account the last time you checked out a forum setup, then your arguments are understandable. If you take phpBB then of course it's going to be comparing shit with shit, but that's not really what we're discussing.
> Then why do you even visit HN? There's no formatting tools available here, is there?
How is HN related to to this discussion? It would be useful if it too had some formatting tools. Was this supposed to be a "gotcha"-moment? Because it failed miserably.
> I do insist it's [...] but indeed "far superior".
All that I can say here is that you have made up your mind and you have made your decision in the past.
Thankfully more and more projects abandon mailing lists and convert to something more accessible, more usable, they're also doing far better, with far more new people joining. Hm, in a sense people can be thankful even, it acts as a signal for people, if the dead hand of the past is there and doesn't want to let go.
If you wish continue as you have for the past few decades, do so, I can't force you to reconsider. But don't come crying when you lack new people contributing and maintaining.
I did, and actually you did too, but you also conveniently ignored those points. Which lets me know they hit the target very well.
> Our mailing lists are far, far superior, than any alternative forum setups I've ever seen.
Taking into account the last time you checked out a forum setup, then your arguments are understandable. If you take phpBB then of course it's going to be comparing shit with shit, but that's not really what we're discussing.
> Then why do you even visit HN? There's no formatting tools available here, is there?
How is HN related to to this discussion? It would be useful if it too had some formatting tools. Was this supposed to be a "gotcha"-moment? Because it failed miserably.
> I do insist it's [...] but indeed "far superior".
All that I can say here is that you have made up your mind and you have made your decision in the past.
Thankfully more and more projects abandon mailing lists and convert to something more accessible, more usable, they're also doing far better, with far more new people joining. Hm, in a sense people can be thankful even, it acts as a signal for people, if the dead hand of the past is there and doesn't want to let go.
If you wish continue as you have for the past few decades, do so, I can't force you to reconsider. But don't come crying when you lack new people contributing and maintaining.
Mailing lists are terrible to search through and navigate, at the very least. GitHub and Gitlab also implement some nice features such as auto-suggest ( to check if the subject has already been discussed) and smart linking.
Now can we get some of the other BSDs to trash CVS?
Don't think that's gonna happen with OpenBSD. At least not any time soon.
[1] https://marc.info/?l=openbsd-misc&m=157819616927844&w=2
[1] https://marc.info/?l=openbsd-misc&m=157819616927844&w=2
Wow this entire thread is just unreal to me. I’ve mostly interacted NetBSD and DragonflyBSD people who were mostly helpful and polite even of you asked what was considered a stupid question.
That reply could’ve been worded so much better. The fact that they went with the insult approach is quite off putting.
Theo makes Linus look like Mr. Rogers
Which ones? DragonFly BSD has transitioned from CVS directly into Git back in 2008.
OpenBSD probably has no plans to transition.
NetBSD has been testing Fossil, Git, Mercurial, for about over a decade now, yet somehow as of 2020 the sight is currently set on Mercurial (even though the current Git export is done through Fossil, continuously since at least 2011); whilst CVS still remains the only official master repo. http://wiki.netbsd.org/github/
OpenBSD probably has no plans to transition.
NetBSD has been testing Fossil, Git, Mercurial, for about over a decade now, yet somehow as of 2020 the sight is currently set on Mercurial (even though the current Git export is done through Fossil, continuously since at least 2011); whilst CVS still remains the only official master repo. http://wiki.netbsd.org/github/
Why? What are you missing from their current CVS usage that you think might be improved with git? Can you provide examples on their CVS usage that are proper arguments to why is it outdated or should be transitioned from?
Admittedly not really. It’s mildly annoying that CVS clients tend to be rather different across operating systems, whereas the standard git client is pretty consistent wherever I am, though.
https://news.ycombinator.com/item?id=25460544
I'm glad it's finally been done!
Looks like GitHub still has the old export as of 2020-12-24T15:30Z, but 5ef5f51d2 dated 2020-12-23T04:27:27Z marks the start of Git history for FreeBSD src!
https://wiki.freebsd.org/git