7 ms·

FreeBSD src repository has transitioned from Subversion to Git

123 points by cnst 6y ago

peanut_worm 6y ago
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
- alkonaut 6y ago
  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.
  - CraigJPerry 6y ago
    >> 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.
    - jlouis 6y ago
      The biggest hassle with svn is adminstrative overhead. You need to give developers access. Git completely works around this hurdle.
      - oblio 6y ago
        You still need to give developers access with git. All the companies I've worked for have a blessed git repo which definitely has access control in place.
    - alkonaut 6y ago
      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.
    - theamk 6y ago
      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.
- zadokshi 6y ago
  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)
  - studius 6y ago
    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?
    - oblio 6y ago
      > 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.
      - panpanna 6y ago
        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
    - zorpner 6y ago
      > No central server to setup or required, period. Someone should let every single person and organization that uses git know about this!
      - corty 6y ago
        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.
- pulse7 6y ago
  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.
  - SEJeff 6y ago
    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.
    - adrianmsmith 6y ago
      > 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”.
      - SEJeff 6y ago
        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.
        alblue 6y ago
        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.
- hannob 6y ago
  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.
- kergonath 6y ago
  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.
  - coldpie 6y ago
    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.
    - User23 6y ago
      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.
      - cnst 6y ago
        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.
- dunce2020 6y ago
  I've only ever really used git as a locally hosted SVN.
- climb_stealth 6y ago
  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.
darthrupert 6y ago
Welcome to 2010s, FreeBSD!
- Avamander 6y ago
  Maybe getting rid of annoying to use mailing lists and git-email will be next? Who knows.
  - cnst 6y ago
    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.
    - sofixa 6y ago
      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.
    - Avamander 6y ago
      > 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.
the_only_law 6y ago
Now can we get some of the other BSDs to trash CVS?
- Gualdrapo 6y ago
  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 https://marc.info/?l=openbsd-misc&m=157819616927844&w=2
  - the_only_law 6y ago
    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.
  - colejohnson66 6y ago
    That reply could’ve been worded so much better. The fact that they went with the insult approach is quite off putting.
    - xxpor 6y ago
      Theo makes Linus look like Mr. Rogers
- cnst 6y ago
  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/ http://wiki.netbsd.org/github/
- HugoDaniel 6y ago
  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?
cnst 6y ago
Prior discussion from a week ago: https://news.ycombinator.com/item?id=25460544 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 https://wiki.freebsd.org/git
Freaky 6y ago
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.
- cnst 6y ago
  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.
  - Freaky 6y ago
    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 :)
- xxpor 6y ago
  git name-rev?
  - Freaky 6y ago
    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.

123 points by cnst 6y ago

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

alkonaut 6y ago
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.
- CraigJPerry 6y ago
  >> 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.
  - jlouis 6y ago
    The biggest hassle with svn is adminstrative overhead. You need to give developers access. Git completely works around this hurdle.
    - oblio 6y ago
      You still need to give developers access with git. All the companies I've worked for have a blessed git repo which definitely has access control in place.
  - alkonaut 6y ago
    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.
  - theamk 6y ago
    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.
zadokshi 6y ago
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)
- studius 6y ago
  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?
  - oblio 6y ago
    > 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.
    - panpanna 6y ago
      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
  - zorpner 6y ago
    > No central server to setup or required, period. Someone should let every single person and organization that uses git know about this!
    - corty 6y ago
      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.
pulse7 6y ago
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.
- SEJeff 6y ago
  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.
  - adrianmsmith 6y ago
    > 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”.
    - SEJeff 6y ago
      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.
      - alblue 6y ago
        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.
hannob 6y ago
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.
kergonath 6y ago
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.
- coldpie 6y ago
  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.
  - User23 6y ago
    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.
    - cnst 6y ago
      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.
dunce2020 6y ago
I've only ever really used git as a locally hosted SVN.
climb_stealth 6y ago
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.

darthrupert 6y ago

Welcome to 2010s, FreeBSD!

Avamander 6y ago
Maybe getting rid of annoying to use mailing lists and git-email will be next? Who knows.
- cnst 6y ago
  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.
  - sofixa 6y ago
    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.
  - Avamander 6y ago
    > 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.

the_only_law 6y ago

Now can we get some of the other BSDs to trash CVS?

Gualdrapo 6y ago
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 https://marc.info/?l=openbsd-misc&m=157819616927844&w=2
- the_only_law 6y ago
  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.
- colejohnson66 6y ago
  That reply could’ve been worded so much better. The fact that they went with the insult approach is quite off putting.
  - xxpor 6y ago
    Theo makes Linus look like Mr. Rogers
cnst 6y ago
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/ http://wiki.netbsd.org/github/
HugoDaniel 6y ago
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?

cnst 6y ago

Prior discussion from a week ago: https://news.ycombinator.com/item?id=25460544 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 https://wiki.freebsd.org/git

Freaky 6y ago

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.

cnst 6y ago
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.
- Freaky 6y ago
  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 :)
xxpor 6y ago
git name-rev?
- Freaky 6y ago
  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.