Re: github.com/NetBSD/src 5 days old?
On 23.05.2020 02:08, matthew sporleder wrote: > On Fri, May 22, 2020 at 5:57 PM Greg A. Woods wrote: >> >> At Thu, 21 May 2020 15:11:41 -0400, Andrew Cagney >> wrote: >> Subject: Re: github.com/NetBSD/src 5 days old? >>> >>> The details are all found here: >>> https://mail-index.netbsd.org/tech-repository/2020/02/17/msg000685.html >> >> That just says what might happen (and what could/should happen at the >> same time), not why (nor how the decision was arrived at). >> >>>> I've never found anything there explaining the actual rationale for Hg. >> >> -- > > Joerg is the one doing all of the work and he wants to land on hg. > > Every other "justification" or benchmark or whatever is pretty much a > lie. Especially now, five years later, when git has gotten better and > better at big repos. > NetBSD also got better with large git repos (thanks to the work of Andrew Doran). One year ago it took ages to commit something locally or to get "git status". Today it's usable. > Matt > > p.s. this whole thing reached a head (Core statement on version > control systems) in Jan 2015 > https://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html > signature.asc Description: OpenPGP digital signature
Re: github.com/NetBSD/src 5 days old?
On Fri, May 22, 2020 at 5:57 PM Greg A. Woods wrote: > > At Thu, 21 May 2020 15:11:41 -0400, Andrew Cagney > wrote: > Subject: Re: github.com/NetBSD/src 5 days old? > > > > The details are all found here: > > https://mail-index.netbsd.org/tech-repository/2020/02/17/msg000685.html > > That just says what might happen (and what could/should happen at the > same time), not why (nor how the decision was arrived at). > > > > I've never found anything there explaining the actual rationale for Hg. > > -- Joerg is the one doing all of the work and he wants to land on hg. Every other "justification" or benchmark or whatever is pretty much a lie. Especially now, five years later, when git has gotten better and better at big repos. Matt p.s. this whole thing reached a head (Core statement on version control systems) in Jan 2015 https://mail-index.netbsd.org/tech-repository/2015/01/04/msg000497.html
Re: github.com/NetBSD/src 5 days old?
At Thu, 21 May 2020 15:11:41 -0400, Andrew Cagney wrote: Subject: Re: github.com/NetBSD/src 5 days old? > > The details are all found here: > https://mail-index.netbsd.org/tech-repository/2020/02/17/msg000685.html That just says what might happen (and what could/should happen at the same time), not why (nor how the decision was arrived at). > > I've never found anything there explaining the actual rationale for Hg. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpxR3MT6eps4.pgp Description: OpenPGP Digital Signature
Re: github.com/NetBSD/src 5 days old?
On Mon, 27 Apr 2020 at 23:25, Greg A. Woods wrote: > > At Mon, 27 Apr 2020 21:32:11 +0200, Thomas Klausner wrote: > Subject: Re: github.com/NetBSD/src 5 days old? > > > > This is an old discussion. If you are interested in this, read the > > archives of the tech-repository mailing list. > > > > https://mail-index.netbsd.org/tech-repository/tindex.html > > Perhaps you could point to a specific thread or message? The details are all found here: https://mail-index.netbsd.org/tech-repository/2020/02/17/msg000685.html > I've never found anything there explaining the actual rationale for Hg. > > -- > Greg A. Woods > > Kelowna, BC +1 250 762-7675 RoboHack > Planix, Inc. Avoncote Farms
Re: github.com/NetBSD/src 5 days old?
On 18/05/2020 14:03, matthew sporleder wrote: If you want small and fast you can use shallow clone and, although you get the entire tree's bundle, it is small and fast. You can then use --sparse to build a "sparse" (kernel only or whatever) limited checkout (aka working dir) -- (new git feature-- https://git-scm.com/docs/git-sparse-checkout / https://git-scm.com/docs/git-read-tree#_sparse_checkout ) / I don't know about mercurial's version of this Its also not worth getting too hung up on small systems being able to check out the source code. Given the memory hog that is GCC these days chances are if you can't check out the source tree you probably can't compile it anyway as GCC will need more memory than your system has. Mike
Re: github.com/NetBSD/src 5 days old?
On Sun, May 17, 2020 at 8:08 PM Constantine A. Murenin wrote: > > On Thu, 14 May 2020 at 09:23, Hauke Fath > wrote: >> >> [re-directing to tech-repository, which was created precisely to keep >> debates like this one off the other lists...] >> >> On Thu, 14 May 2020 14:47:02 +0200, Jens Rehsack wrote: >> > I doubt that you'll find a modern solution running fine on any 4M computer. >> > Network filesystems, cross compilers etc. where invented to support >> > machines >> > which can't provide all required resources for a job on their own. >> >> Unfortunately, the VCS equivalent to your list would be a client >> connecting to a beefy local DVCS instance, which to the best of my >> knowledge has not been invented, yet. > > > Actually, it has already been invented. GitHub has links to download the > checkout as a zip archive from any branch. > > E.g., https://github.com/NetBSD/src/archive/netbsd-9.zip has the checkout > from `netbsd-9`. > > I've just tried how it works, and am getting 5MB/s on my 12.6MB/s connection > through the WiFi in the office, so, it seems to be working good enough. I > believe they archive it on the go, as a stream, because there's no file size > upfront when you first download it; I've tried downloading it a second time > right after completing the first one, and I did get the size then (Length: > 548765520 (523M) [application/zip]), so, they are smart enough to cache it at > least for some time. > > Of course, the biggest issue is that there's no way to ignore any specific > parts of the tree, so, you're stuck with downloading a 0.5GB archive of a > 2.4GB checkout. I'm still of the opinion that it might be a good idea to > split the `src` repository into several sub-repositories like syssrc, gnusrc > and src, as per > http://mail-index.netbsd.org/tech-repository/2020/02/21/msg000698.html. Or > maybe at least provide such a setup as an option, especially to just get the > kernel? > > Cheers, > Constantine. This is a built-in git feature: https://git-scm.com/book/en/v2/Git-Tools-Bundling (hg archive is the same, I think) If you want small and fast you can use shallow clone and, although you get the entire tree's bundle, it is small and fast. You can then use --sparse to build a "sparse" (kernel only or whatever) limited checkout (aka working dir) -- (new git feature-- https://git-scm.com/docs/git-sparse-checkout / https://git-scm.com/docs/git-read-tree#_sparse_checkout ) / I don't know about mercurial's version of this
Re: github.com/NetBSD/src 5 days old?
On Thu, 14 May 2020 at 09:23, Hauke Fath wrote: > [re-directing to tech-repository, which was created precisely to keep > debates like this one off the other lists...] > > On Thu, 14 May 2020 14:47:02 +0200, Jens Rehsack wrote: > > I doubt that you'll find a modern solution running fine on any 4M > computer. > > Network filesystems, cross compilers etc. where invented to support > machines > > which can't provide all required resources for a job on their own. > > Unfortunately, the VCS equivalent to your list would be a client > connecting to a beefy local DVCS instance, which to the best of my > knowledge has not been invented, yet. > Actually, it has already been invented. GitHub has links to download the checkout as a zip archive from any branch. E.g., https://github.com/NetBSD/src/archive/netbsd-9.zip has the checkout from `netbsd-9`. I've just tried how it works, and am getting 5MB/s on my 12.6MB/s connection through the WiFi in the office, so, it seems to be working good enough. I believe they archive it on the go, as a stream, because there's no file size upfront when you first download it; I've tried downloading it a second time right after completing the first one, and I did get the size then (Length: 548765520 (523M) [application/zip]), so, they are smart enough to cache it at least for some time. Of course, the biggest issue is that there's no way to ignore any specific parts of the tree, so, you're stuck with downloading a 0.5GB archive of a 2.4GB checkout. I'm still of the opinion that it might be a good idea to split the `src` repository into several sub-repositories like syssrc, gnusrc and src, as per http://mail-index.netbsd.org/tech-repository/2020/02/21/msg000698.html. Or maybe at least provide such a setup as an option, especially to just get the kernel? Cheers, Constantine.
Re: github.com/NetBSD/src 5 days old?
On May 14, 2020, at 09:07, Hauke Fath wrote: > > [re-directing to tech-repository, which was created precisely to keep > debates like this one off the other lists...] My apologies. I’ll continue this thread on tech-repository. jf -- John Franklin frank...@elfie.org
Re: github.com/NetBSD/src 5 days old?
[re-directing to tech-repository, which was created precisely to keep debates like this one off the other lists...] On Thu, 14 May 2020 14:47:02 +0200, Jens Rehsack wrote: > I doubt that you'll find a modern solution running fine on any 4M computer. > Network filesystems, cross compilers etc. where invented to support machines > which can't provide all required resources for a job on their own. Unfortunately, the VCS equivalent to your list would be a client connecting to a beefy local DVCS instance, which to the best of my knowledge has not been invented, yet. Cheerio, Hauke -- Hauke Fath Grabengasse 57 64372 Ober-Ramstadt Germany
Re: github.com/NetBSD/src 5 days old?
On May 14, 2020, at 09:26, Joerg Sonnenberger wrote: > > On Wed, May 13, 2020 at 10:11:14PM -0400, John Franklin wrote: >> There are scalability issues with Mercurial, too. I cloned NetBSD src >> on a 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the >> GitHub project and from anonhg.netbsd.org. > > You are comparing Apples and Oranges. The clonebundles on anonhg are > created with very large windows and zstd compression and the necessary > buffering of that is the primary memory use. I used to provide bzip2 > bundles as fallback, but disk space constrains made that temporarily > undesirable. I.e. this is not about scaling at all. I’m comparing cloning with cloning using the same VM. From the contributor’s POV, it's as apples-to-apples as it gets. Even the commands are the same: “$VCS clone $URL” As configured, Mercurial takes 3x the memory, 4x the time, and fails to clone at all without a minimum of 3GB of RAM+swap. The driving factor behind the resource requirement is the amount of history the project has. Which is to say, how well these two tools *scale* with the size of the repository. If server-side changes can reduce that, and all the server needs is a bigger disk, then get a bigger disk. jf -- John Franklin frank...@elfie.org
Re: github.com/NetBSD/src 5 days old?
On Wed, May 13, 2020 at 10:11:14PM -0400, John Franklin wrote: > There are scalability issues with Mercurial, too. I cloned NetBSD src > on a 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the > GitHub project and from anonhg.netbsd.org. You are comparing Apples and Oranges. The clonebundles on anonhg are created with very large windows and zstd compression and the necessary buffering of that is the primary memory use. I used to provide bzip2 bundles as fallback, but disk space constrains made that temporarily undesirable. I.e. this is not about scaling at all. Joerg
Re: github.com/NetBSD/src 5 days old?
> Am 14.05.2020 um 04:52 schrieb matthew sporleder : > > > >> On May 13, 2020, at 10:11 PM, John Franklin wrote: >> >> On Apr 30, 2020, at 21:28, bch wrote: >>> >>> I thought the plan to move to HG hasn't been finalised yet, am I missing >>> something? Plus, why HG and not Fossil, if the end-result consumption is >>> via Git anyways? >>> >>> [...] >> >> There are scalability issues with Mercurial, too. I cloned NetBSD src on a >> 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the GitHub >> project and from anonhg.netbsd.org. >> >> [...] > > This argument does not work. I went through the same goalpost moving exercise > years ago and martin@ even got some efficiency patches into git as a result, > but the super low memory shallow clone is not even good enough. I think the argument works very well - at least to stay at CVS forever >:-) I doubt that you'll find a modern solution running fine on any 4M computer. Network filesystems, cross compilers etc. where invented to support machines which can't provide all required resources for a job on their own. Cheers -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: github.com/NetBSD/src 5 days old?
> On May 13, 2020, at 10:11 PM, John Franklin wrote: > > On Apr 30, 2020, at 21:28, bch wrote: >> >> I thought the plan to move to HG hasn't been finalised yet, am I missing >> something? Plus, why HG and not Fossil, if the end-result consumption is >> via Git anyways? >> >> Last I heard fossil had scaling issues due to the large number of artifacts >> that needed to be tracked. I may be able to trawl notes and find some >> particulars, or Joerg may be able to comment from memory on the technical >> aspects. >> >> >> I was really hopeful for fossil as a solution as it seems really sane for >> many reasons: >> 1) good user interface(s) >> 2) good, novel ticket handling >> 3) sane architecture >> 4) portable C implementation >> 5) BSD license >> >> I think in the end though Joerg reckoned the scalability issue was too much. > > There are scalability issues with Mercurial, too. I cloned NetBSD src on a > 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the GitHub project > and from anonhg.netbsd.org. > > Git consumed 675MB of memory at its peak, and took 4m38s. > > Cloning with hg from anonhg.netbsd.org consumes all RAM and all swap before > the OOM killer takes it out. > > Upping the memory to 2GB RAM (still 1GB swap) gets further along, to the > point where hg forks into $(CPU_COUNT) processes for “updating to bookmark @ > on branch trunk” before the OOM killer takes it out. > > Finally, 2GB RAM and 1GB swap, and enabling vm.overcommit_memory was enough > to let hg finish in 17m52s. > > jf > -- > John Franklin > frank...@elfie.org This argument does not work. I went through the same goalpost moving exercise years ago and martin@ even got some efficiency patches into git as a result, but the super low memory shallow clone is not even good enough. >
Re: github.com/NetBSD/src 5 days old?
On Apr 30, 2020, at 21:28, bch wrote: > > I thought the plan to move to HG hasn't been finalised yet, am I missing > something? Plus, why HG and not Fossil, if the end-result consumption is via > Git anyways? > > Last I heard fossil had scaling issues due to the large number of artifacts > that needed to be tracked. I may be able to trawl notes and find some > particulars, or Joerg may be able to comment from memory on the technical > aspects. > > > I was really hopeful for fossil as a solution as it seems really sane for > many reasons: > 1) good user interface(s) > 2) good, novel ticket handling > 3) sane architecture > 4) portable C implementation > 5) BSD license > > I think in the end though Joerg reckoned the scalability issue was too much. There are scalability issues with Mercurial, too. I cloned NetBSD src on a 1GB RAM, 1GB swap, 4 CPU VM (Debian Buster) using git from the GitHub project and from anonhg.netbsd.org. Git consumed 675MB of memory at its peak, and took 4m38s. Cloning with hg from anonhg.netbsd.org consumes all RAM and all swap before the OOM killer takes it out. Upping the memory to 2GB RAM (still 1GB swap) gets further along, to the point where hg forks into $(CPU_COUNT) processes for “updating to bookmark @ on branch trunk” before the OOM killer takes it out. Finally, 2GB RAM and 1GB swap, and enabling vm.overcommit_memory was enough to let hg finish in 17m52s. jf -- John Franklin frank...@elfie.org
Re: github.com/NetBSD/src 5 days old?
On Thu, Apr 30, 2020 at 17:44 Constantine A. Murenin wrote: > On Sun, 26 Apr 2020 at 12:20, wrote: > >> On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: >> > I switched away from cvsup a while back, but I now see that github >> > NetBSD/src mirror is now 5 days old. Known issue? >> >> Yes, I believe joerg and spz are changing the conversion from >> cvs->??->git to hg->git, to match what will be done once we stop using >> CVS. >> > > What's wrong with "??"? I think it's pretty well-known that Fossil has > been the intermediary repository in NetBSD's conversion from CVS to Git > since 2011, and it would seem that https://src.fossil.netbsd.org/ is > still up-to-date, FWIIW, whereas GitHub's src is 7 days behind. > > I thought the plan to move to HG hasn't been finalised yet, am I missing > something? Plus, why HG and not Fossil, if the end-result consumption is > via Git anyways? > Last I heard fossil had scaling issues due to the large number of artifacts that needed to be tracked. I may be able to trawl notes and find some particulars, or Joerg may be able to comment from memory on the technical aspects. I was really hopeful for fossil as a solution as it seems really sane for many reasons: 1) good user interface(s) 2) good, novel ticket handling 3) sane architecture 4) portable C implementation 5) BSD license I think in the end though Joerg reckoned the scalability issue was too much. -bch > > C. >
Re: github.com/NetBSD/src 5 days old?
On Fri, May 01, 2020 at 04:09:38AM +, Thomas Mueller wrote: > Mercurial has a problem which may be resolved in a future release, if it > hasn't already: dependency on the deprecated Python 2.7. The information you read is outdated. The pkgsrc package already builds hg against python 3.7. Not all extensions might work with that python version yet, but the base mercurial does. Thomas
Re: github.com/NetBSD/src 5 days old?
from "Constantine A. Murenin" : > On Sun, 26 Apr 2020 at 12:20, wrote: > > On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: > > > I switched away from cvsup a while back, but I now see that github > > > NetBSD/src mirror is now 5 days old. Known issue? > > Yes, I believe joerg and spz are changing the conversion from > > cvs->??->git to hg->git, to match what will be done once we stop using > CVS. > What's wrong with "??"? I think it's pretty well-known that Fossil has > been the intermediary repository in NetBSD's conversion from CVS to Git > since 2011, and it would seem that https://src.fossil.netbsd.org/ is still > up-to-date, FWIIW, whereas GitHub's src is 7 days behind. > I thought the plan to move to HG hasn't been finalised yet, am I missing > something? Plus, why HG and not Fossil, if the end-result consumption is > via Git anyways? I was going to send this message even if not in response to Constantin Murenin's message. I was led to Mercurial website (www.mercurial-scm.org) when reading about plans for Toybox, which is like a lesser BusyBox. Mercurial has a problem which may be resolved in a future release, if it hasn't already: dependency on the deprecated Python 2.7. So I don't think NetBSD should rush the switch to hg until hg is ready to build with Python >= 3.6. There is no more upstream support for Python 2.x or 2.7, meaning any security vulnerabilities will not be fixed. Tom
Re: github.com/NetBSD/src 5 days old?
On Sun, 26 Apr 2020 at 12:20, wrote: > On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: > > I switched away from cvsup a while back, but I now see that github > > NetBSD/src mirror is now 5 days old. Known issue? > > Yes, I believe joerg and spz are changing the conversion from > cvs->??->git to hg->git, to match what will be done once we stop using > CVS. > What's wrong with "??"? I think it's pretty well-known that Fossil has been the intermediary repository in NetBSD's conversion from CVS to Git since 2011, and it would seem that https://src.fossil.netbsd.org/ is still up-to-date, FWIIW, whereas GitHub's src is 7 days behind. I thought the plan to move to HG hasn't been finalised yet, am I missing something? Plus, why HG and not Fossil, if the end-result consumption is via Git anyways? C.
Re: github.com/NetBSD/src 5 days old?
> Am 28.04.2020 um 10:50 schrieb m...@netbsd.org : > > On Tue, Apr 28, 2020 at 08:30:43AM +0200, Marc Balmer wrote: >> >> >>> Am 28.04.2020 um 08:29 schrieb Andreas Gustafsson : >>> >>> m...@netbsd.org wrote: Yes, I believe joerg and spz are changing the conversion from cvs->??->git to hg->git, to match what will be done once we stop using CVS. >>> >>> Has there been a formal decision choosing hg over git? >> >> I am also interested in this. >> >> > > This feels like a protest. Since it's addressing me, I'd like to point > out I'm just letting people know why the conversion is down, and don't > get any more of a say over things than others. No, that was not to be understood as a protest, and addressing you personally was by mistake - I hit reply-to-all and did not check the adresses. Well, this time it is not by mistake, as I intended to reply to you ;) > As a reminder, hg/git offer far better interoperability (than CVS). > Much of my own NetBSD work is done on Git, and even if I don't stop > doing this, I would be happier if the backend was Mercurial. > > The CVS->??->git conversion loses information on the parents of branch > merges, so we carry a growing graft file, and it has to be adjusted > whenever there's a forced push. > > Having Mercurial at the back would eliminate ~all forced pushes and have > real merge commits. Exporting the commits would require a lot less > threats and custom scripts on current-users, because pushing is > distinct from committing. Thanks for your explanations.
Re: github.com/NetBSD/src 5 days old?
On Tue, Apr 28, 2020 at 08:30:43AM +0200, Marc Balmer wrote: > > > > Am 28.04.2020 um 08:29 schrieb Andreas Gustafsson : > > > > m...@netbsd.org wrote: > >> Yes, I believe joerg and spz are changing the conversion from > >> cvs->??->git to hg->git, to match what will be done once we stop using > >> CVS. > > > > Has there been a formal decision choosing hg over git? > > I am also interested in this. > > This feels like a protest. Since it's addressing me, I'd like to point out I'm just letting people know why the conversion is down, and don't get any more of a say over things than others. As a reminder, hg/git offer far better interoperability (than CVS). Much of my own NetBSD work is done on Git, and even if I don't stop doing this, I would be happier if the backend was Mercurial. The CVS->??->git conversion loses information on the parents of branch merges, so we carry a growing graft file, and it has to be adjusted whenever there's a forced push. Having Mercurial at the back would eliminate ~all forced pushes and have real merge commits. Exporting the commits would require a lot less threats and custom scripts on current-users, because pushing is distinct from committing.
Re: github.com/NetBSD/src 5 days old?
> Am 28.04.2020 um 08:29 schrieb Andreas Gustafsson : > > m...@netbsd.org wrote: >> Yes, I believe joerg and spz are changing the conversion from >> cvs->??->git to hg->git, to match what will be done once we stop using >> CVS. > > Has there been a formal decision choosing hg over git? I am also interested in this.
Re: github.com/NetBSD/src 5 days old?
m...@netbsd.org wrote: > Yes, I believe joerg and spz are changing the conversion from > cvs->??->git to hg->git, to match what will be done once we stop using > CVS. Has there been a formal decision choosing hg over git? -- Andreas Gustafsson, g...@gson.org
Re: github.com/NetBSD/src 5 days old?
> This is an old discussion. If you are interested in this, read the > archives of the tech-repository mailing list. > https://mail-index.netbsd.org/tech-repository/tindex.html > Short version: we're migrating to hg, it goes slowly, but progress is made. > Cheers, > Thomas (Klausner) That URL you gave was for a discussion on merging src and xsrc trees, not about switching from CVS to hg. Any time estimate on the switch to hg? Tom
Re: github.com/NetBSD/src 5 days old?
At Mon, 27 Apr 2020 21:32:11 +0200, Thomas Klausner wrote: Subject: Re: github.com/NetBSD/src 5 days old? > > This is an old discussion. If you are interested in this, read the > archives of the tech-repository mailing list. > > https://mail-index.netbsd.org/tech-repository/tindex.html Perhaps you could point to a specific thread or message? I've never found anything there explaining the actual rationale for Hg. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpjjXGdbbeaJ.pgp Description: OpenPGP Digital Signature
Re: github.com/NetBSD/src 5 days old?
On Mon, Apr 27, 2020 at 07:24:30PM +, Thomas Mueller wrote: > > > Then what will be the primary way to track NetBSD src and pkgsrc trees? > > > > Now it's CVS, mirrored to git. What will replace CVS, will it be git, > > > hg, or something else, and will it be in the base system, or will it have > > > to be built or pkg_add'ed from pkgsrc? > > > > Is it a matter of CVS being less secure? I see that OpenBSD, the great > > > security-minded OS, still uses CVS, mirrored on Github. > > > Hi Thomas, > > > The main motivation to move away from CVS is that it's lacking in > > features. The plan so far is to move to Mercurial, and not have it in > > base. "Bootstrapping" is still possible using tarballs. > > > While I would hesitate to connect to a malicious CVS server, I don't see > > a reason to suspect CVS is significantly worse than Git-over-SSH, for > > example. A lot of the security in CVS relies on the SSH implementation. > > Git is much more widely used than Mercurial, as far as I can see. > > I have never been to a repository where Mercurial was the only or primary VCS. > > I've built and installed git from ports (FreeBSD) and pkgsrc (NetBSD), but > never Mercurial. > > If a Mercurial repository/archive is bootstrapped from a tarball, how is it > updated? > > FreeBSD switched from cvsup and csup to svn in summer 2012 due to a security > breach. > > The full svn is not in FreeBSD base system; base system has an optional > svnlite, which I decline in favor of building the devel/subversion port, > which I have done in both FreeBSD (ports) and NetBSD (pkgsrc). This is an old discussion. If you are interested in this, read the archives of the tech-repository mailing list. https://mail-index.netbsd.org/tech-repository/tindex.html Short version: we're migrating to hg, it goes slowly, but progress is made. Cheers, Thomas
Re: github.com/NetBSD/src 5 days old?
> > Then what will be the primary way to track NetBSD src and pkgsrc trees? > > Now it's CVS, mirrored to git. What will replace CVS, will it be git, hg, > > or something else, and will it be in the base system, or will it have to be > > built or pkg_add'ed from pkgsrc? > > Is it a matter of CVS being less secure? I see that OpenBSD, the great > > security-minded OS, still uses CVS, mirrored on Github. > Hi Thomas, > The main motivation to move away from CVS is that it's lacking in > features. The plan so far is to move to Mercurial, and not have it in > base. "Bootstrapping" is still possible using tarballs. > While I would hesitate to connect to a malicious CVS server, I don't see > a reason to suspect CVS is significantly worse than Git-over-SSH, for > example. A lot of the security in CVS relies on the SSH implementation. Git is much more widely used than Mercurial, as far as I can see. I have never been to a repository where Mercurial was the only or primary VCS. I've built and installed git from ports (FreeBSD) and pkgsrc (NetBSD), but never Mercurial. If a Mercurial repository/archive is bootstrapped from a tarball, how is it updated? FreeBSD switched from cvsup and csup to svn in summer 2012 due to a security breach. The full svn is not in FreeBSD base system; base system has an optional svnlite, which I decline in favor of building the devel/subversion port, which I have done in both FreeBSD (ports) and NetBSD (pkgsrc). Tom
Re: github.com/NetBSD/src 5 days old?
On Sun, Apr 26, 2020 at 11:26:38PM +, Thomas Mueller wrote: > On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: > > I switched away from cvsup a while back, but I now see that github > > NetBSD/src mirror is now 5 days old. Known issue? > > m...@netbsd.org responded: > > > Yes, I believe joerg and spz are changing the conversion from > > cvs->??->git to hg->git, to match what will be done once we stop using CVS. > > Then what will be the primary way to track NetBSD src and pkgsrc trees? > > Now it's CVS, mirrored to git. What will replace CVS, will it be git, hg, or > something else, and will it be in the base system, or will it have to be > built or pkg_add'ed from pkgsrc? > > Is it a matter of CVS being less secure? I see that OpenBSD, the great > security-minded OS, still uses CVS, mirrored on Github. Hi Thomas, The main motivation to move away from CVS is that it's lacking in features. The plan so far is to move to Mercurial, and not have it in base. "Bootstrapping" is still possible using tarballs. While I would hesitate to connect to a malicious CVS server, I don't see a reason to suspect CVS is significantly worse than Git-over-SSH, for example. A lot of the security in CVS relies on the SSH implementation.
Re: github.com/NetBSD/src 5 days old?
On Sun, Apr 26, 2020 at 05:19:48PM +, m...@netbsd.org wrote: > On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: > > I switched away from cvsup a while back, but I now see that github > > NetBSD/src mirror is now 5 days old. Known issue? > > Yes, I believe joerg and spz are changing the conversion from > cvs->??->git to hg->git, to match what will be done once we stop using > CVS. Ah, cool. I'll sit back and watch and wait, I'm in no rush. Thanks! -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
Re: github.com/NetBSD/src 5 days old?
On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: > I switched away from cvsup a while back, but I now see that github > NetBSD/src mirror is now 5 days old. Known issue? m...@netbsd.org responded: > Yes, I believe joerg and spz are changing the conversion from > cvs->??->git to hg->git, to match what will be done once we stop using CVS. Then what will be the primary way to track NetBSD src and pkgsrc trees? Now it's CVS, mirrored to git. What will replace CVS, will it be git, hg, or something else, and will it be in the base system, or will it have to be built or pkg_add'ed from pkgsrc? Is it a matter of CVS being less secure? I see that OpenBSD, the great security-minded OS, still uses CVS, mirrored on Github. Tom
Re: github.com/NetBSD/src 5 days old?
On Sun, Apr 26, 2020 at 02:30:48PM +1000, Paul Ripke wrote: > I switched away from cvsup a while back, but I now see that github > NetBSD/src mirror is now 5 days old. Known issue? Yes, I believe joerg and spz are changing the conversion from cvs->??->git to hg->git, to match what will be done once we stop using CVS.
