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: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
I would be very happy if a decision would be taken in a timely manner. I prefer git over mercurial, but any of them is better than cvs. > Am 14.05.2020 um 17:27 schrieb Martin Husemann : > > On Wed, May 13, 2020 at 09:16:31PM -0700, Greg A. Woods wrote: >> I.e. the final repo DAG should contain all submitted commits, and all >> that history should be visible to those who look for it (just as is the >> case with merges from github "pull requests"). > > This is the case in our setup. In the "draft" phase you can revert, > rewrite, collapse and change a few things, but in the end you have > a line of changesets that on final push are made visible on the tip > of the trunk (still as individual changes). > > Martin
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Wed, May 13, 2020 at 09:16:31PM -0700, Greg A. Woods wrote: > I.e. the final repo DAG should contain all submitted commits, and all > that history should be visible to those who look for it (just as is the > case with merges from github "pull requests"). This is the case in our setup. In the "draft" phase you can revert, rewrite, collapse and change a few things, but in the end you have a line of changesets that on final push are made visible on the tip of the trunk (still as individual changes). Martin
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 22:11:20 -0400, John Franklin wrote:
Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>
> Put another way, it’s nothing more than “please consider the changes
> in branch jqcoder/foo for inclusion in your project.” Any DVCS that
> can handle branches reasonably well can do something like a “pull
> request.” If you like it, `${DVCS} merge jqcoder/foo`. The way GitHub
> handles PRs, the branch lives in their private clone of the
> repository, not the main project’s copy. It prevents the master
> repository from getting polluted with dozens of pull request branches.
Yes, sort of.
Just to be pedantic though -- on githup "clones" are actually just
custom "views" of the same repository, storage-wise; and this gives
github the ability to quickly show all progress in all clones all at
once in one graph view.
My desire here is to see a (clean) history of branch commits be fully
imported into the NetBSD repository, complete with all its _original_
VCS metadata, but perhaps with the visible branch name removed.
I.e. the final repo DAG should contain all submitted commits, and all
that history should be visible to those who look for it (just as is the
case with merges from github "pull requests").
> It should be possible to go both ways. I’ve seen very clean pull
> requests of a few commits that should be merged including the full
> history, and some that were 300+ commits with one-third of the commit
> messages including the words “revert” or “undo” in them. (In some
> cases, the commit message was simply “revert”.) Following the chain
> was fruitless, only comparing the branch to the mainline was of any
> value, and a squash commit is the only way to handle such things.
Well, the point of what Kun was getting at, I think, and what I would
like to see for NetBSD, is that a reviewer should entirely reject an
un-clean commit history. Commit history that shows and documents the
intent and progress of changes is what's desired (and what makes review
easier for some/many reviewers), but of course a lot of false paths and
ugly hacks that are undone and tried again and again doesn't help tell
any real story about the final code or the path actually taken to get to
just that final result. Commit history is exactly that -- a history
meant to be read and remembered by the humans who come afterwards.
--
Greg A. Woods
Kelowna, BC +1 250 762-7675 RoboHack
Planix, Inc. Avoncote Farms
pgpcF6DD4_705.pgp
Description: OpenPGP Digital Signature
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: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On May 13, 2020, at 17:56, Greg A. Woods wrote:
>
> At Wed, 13 May 2020 21:30:29 +0200, Joerg Sonnenberger wrote:
> Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
>>
>> On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote:
>>> At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote:
>>>
>>>> I have no idea what the OP is talking about. Mercurial doesn't have pull
>>>> requests, neither does git BTW. So this is about some specific web UI or
>>>> review tool, but I don't even know which one.
>>>
>>> Consider "pull request" to stand in for _any_ kind of workflow and
>>> mechanism that third parties would use to submit changes along with the
>>> recorded existing metadata for those changes, to the upstream project's
>>> repository.
Put another way, it’s nothing more than “please consider the changes in branch
jqcoder/foo for inclusion in your project.” Any DVCS that can handle branches
reasonably well can do something like a “pull request.” If you like it,
`${DVCS} merge jqcoder/foo`. The way GitHub handles PRs, the branch lives in
their private clone of the repository, not the main project’s copy. It
prevents the master repository from getting polluted with dozens of pull
request branches.
> So thus the question remains: What will NetBSD's workflow be? Will it
> be compatible with merging a set of changes from a third party in much
> the manner of what's typically called a "pull request" in the Git
> (github, gitlab, etc., etc., etc.) world, and especially in a way that
> avoids squashing a branch into a single commit (thus losing commit
> metadata)?
It should be possible to go both ways. I’ve seen very clean pull requests of a
few commits that should be merged including the full history, and some that
were 300+ commits with one-third of the commit messages including the words
“revert” or “undo” in them. (In some cases, the commit message was simply
“revert”.) Following the chain was fruitless, only comparing the branch to the
mainline was of any value, and a squash commit is the only way to handle such
things.
jf
--
John Franklin
frank...@elfie.org
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: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 21:30:29 +0200, Joerg Sonnenberger wrote: Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?) > > On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote: > > At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote: > > > > > I have no idea what the OP is talking about. Mercurial doesn't have pull > > > requests, neither does git BTW. So this is about some specific web UI or > > > review tool, but I don't even know which one. > > > > Consider "pull request" to stand in for _any_ kind of workflow and > > mechanism that third parties would use to submit changes along with the > > recorded existing metadata for those changes, to the upstream project's > > repository. > > The statement still makes no sense at all. Nothing forces you to fold > all incremental steps into a single changeset. Some workflows clearly do force squashing of commits into a single one (even in git-only projects or hg-only projects), else Kun wouldn't have written what he did, and I wouldn't be wondering as well. So thus the question remains: What will NetBSD's workflow be? Will it be compatible with merging a set of changes from a third party in much the manner of what's typically called a "pull request" in the Git (github, gitlab, etc., etc., etc.) world, and especially in a way that avoids squashing a branch into a single commit (thus losing commit metadata)? -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpnDI5pUiRCT.pgp Description: OpenPGP Digital Signature
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Wed, May 13, 2020 at 12:21:50PM -0700, Greg A. Woods wrote: > At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote: > > > I have no idea what the OP is talking about. Mercurial doesn't have pull > > requests, neither does git BTW. So this is about some specific web UI or > > review tool, but I don't even know which one. > > Consider "pull request" to stand in for _any_ kind of workflow and > mechanism that third parties would use to submit changes along with the > recorded existing metadata for those changes, to the upstream project's > repository. The statement still makes no sense at all. Nothing forces you to fold all incremental steps into a single changeset. Joerg
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 14:14:16 +0200, Joerg Sonnenberger wrote: Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?) > > The staging area is a general point of contention, even in the git > world. Interactive commits (commit -i) and incrementally amending > changes pretty much cover the general use cases without all the > cognitive load another level of changes has. Interactive commits that are driven by the tool are pointless as an alternative for my use case of the Git staging area -- they are, by definition, "interactive" i.e. not programmable. The way most Git users use the staging area with Git is in a way that can be considered programmable, and the way many of us actually use the staging area is indeed through other tools that drive Git programmatically, as is the case with the tool called Magit that I use from within Emacs. So, until/unless Magit (in my case) grows support for Mercurial, and/or something even more usable appears in the Emacs world as a front-end for Mercurial with similar capabilities, I'll continue using Magit and Git in order to capture my work and the metadata about it into a change management system. That's just my personal limitation, but I suspect it matches what other Git users, and especially Magit users, would prefer. The question I have is then whether, and how, I can share such changes and the captured metadata about them with the upstream project. That's done trivially with Git on both ends of course, but presumably Git can also push changes to Mercurial in some lossless way as well (or vice versa, Mercurial can pull changes, complete with their metadata, from a Git repository). > I have no idea what the OP is talking about. Mercurial doesn't have pull > requests, neither does git BTW. So this is about some specific web UI or > review tool, but I don't even know which one. Consider "pull request" to stand in for _any_ kind of workflow and mechanism that third parties would use to submit changes along with the recorded existing metadata for those changes, to the upstream project's repository. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpZCTTBhVeGA.pgp Description: OpenPGP Digital Signature
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Wed, 13 May 2020 07:53:28 +0200, Thomas Klausner wrote: Subject: Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?) > > On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote: > > For one, Mercurial has no staging area. That removes one level of > > the three-level hierarchy from my toolset. It’s hard to identify > > exactly when in my workflow this causes issues, but I’ve started to > > notice it. For example, it’s not possible to commit a hunk from my > > editor like I can with git and vim-gitgutter. > > > > I do the same with magit -- the staging area is a supreme benefit! > > I disagree. Anyway, what git does here is "git add --patch" and the hg > eqivalent is "hg record" (which is not enabled by default; just add > "record=" in an "[extensions]" block in your .hgrc to enable it), so > the functionality is available for both tools. Since I won't ever be using Mercurial directly for day-to-day work (unless current circumstance that go far beyond my own control change very drastically), the question then turns to how will the moral equivalent to a pull request look once merged into the trunk/master branch, or whatever it will be called. The point I was trying to make by referring to Kun's essay is that the original commits should still exist in the DAG (even if the original branch name is removed from the master repo). I.e. that no commit metadata from the original submission ever be lost. The failure of CVS and using patches to submit changes is that _all_ of the commit metadata is entirely lost, and the failure of the workflow Kun describes with Mecurial (at Google) is that _most_ of this metadata is still lost. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpigu1kIdsHK.pgp Description: OpenPGP Digital Signature
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
> Am 13.05.2020 um 05:55 schrieb Greg A. Woods : > > At Tue, 28 Apr 2020 08:50:55 +, m...@netbsd.org wrote: > Subject: Re: github.com/NetBSD/src 5 days old? >> >> 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. > > So I've still not found any discussion explaining the reasoning behind > Mercurial vs. anything/everything else. > > For me as I work independently on NetBSD it doesn't really matter what > the back-end is so long as I can use Git for my day-to-day work and to > keep better track of my local changes. (That, btw, is still very much > just a work in progress for me -- I've been unable to use the current > repo on github as it breaks after updates far too often, i.e. whenever > the conversion is unstable somehow.) I seriously had kind-of trouble managing local changes vs. pushed (cvs committed) changes and therefore I don't do much at the very moment. As I'm doing it in spare time (shared with at least 5 time intensive other hobbies), the conflict resolution time almost eats up all slices. This is bad, since I would seriously like to prepare some things to be sent to pkgsrc just like old times :D > However it would seem to me to be better and easier, for me, to be able > to publish those of my changes that I would hope to feed back to the > main NetBSD repository via Git, and in such a way that my original > commit metadata does not get lost or squashed or rewritten in any way. > As-is this has been a major stumbling block for me w.r.t. feeding back > some of my changes and fixes in terms of sending patches, etc. while > NetBSD still uses CVS. Well - most hosters and services support just git meanwhile. Atlasssian dropped mercurial support, public available CI services as Travis or Circle CI do git only - that get's longer and longer. > Not knowing Mercurial myself, nor how it interoperates with Git, I'm > unsure of whether this is possible or not, especially given whatever > workflows the NetBSD core team comes up with. > > However I recently encountered this essay by Jeremy Kun which has > presented some of my less-well formed thoughts in a more concrete way, > and in particular one of his replies to a comment that was posted about > his essay: > > "The Communicative Value of Using Git Well" > > https://jeremykun.com/2020/01/14/the-communicative-value-of-using-git-well/#comment-110432 > >For one, Mercurial has no staging area. That removes one level of >the three-level hierarchy from my toolset. It’s hard to identify >exactly when in my workflow this causes issues, but I’ve started to >notice it. For example, it’s not possible to commit a hunk from my >editor like I can with git and vim-gitgutter. > > I do the same with magit -- the staging area is a supreme benefit! I fully agree to Joerg Sonnenberger here. > I guess that it wouldn't matter if one used Git for day-to-day work and > the back-end was still Mercurial, but that very much begs the question > of just what benefit Mercurial can possibly bring in the long run. > >Mercurial also collapses all changes within a pull request >(changeset) into a single commit. That removes the meaningful >difference between the top level (pull request) and the mid level >(commit) that I find helpful to narrate. There is some ability when >working locally to create a bunch of commits like I would in git, >and then later squash them all using hg histedit. But my reviewers >can’t see the individual commits, nor can they be seen or reverted >individually in the long term project history. > > If this is the case it would also seem to be a major drawback to > Mercurial. There are further comments that suggest this may not be > quite so bad as Kun makes it sound, and indeed that part of his problem > might actually be specific to the workflow that his employer forces, but > there's also some ongoing doubt about this. This is very likely a frontend issue, I don't know what Kun refers to. OTOH - pull requests (or development-branches ...) should have a topic, e.g. 'Upgrading Perl5 to 5.32' which contains the p5 core upgrade, revision bumps of p5-* and some dependency patterns updates based on new core-modules. There will be now reason to revert just one of those commits - all of them or not. If parts of such a PR can be reverted, it's unfortunately assembled. Cheers. -- Jens Rehsack - rehs...@gmail.com signature.asc Description: Message signed with OpenPGP
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote: > For one, Mercurial has no staging area. That removes one level of > the three-level hierarchy from my toolset. It’s hard to identify > exactly when in my workflow this causes issues, but I’ve started to > notice it. For example, it’s not possible to commit a hunk from my > editor like I can with git and vim-gitgutter. > > I do the same with magit -- the staging area is a supreme benefit! The staging area is a general point of contention, even in the git world. Interactive commits (commit -i) and incrementally amending changes pretty much cover the general use cases without all the cognitive load another level of changes has. > Mercurial also collapses all changes within a pull request > (changeset) into a single commit. That removes the meaningful > difference between the top level (pull request) and the mid level > (commit) that I find helpful to narrate. There is some ability when > working locally to create a bunch of commits like I would in git, > and then later squash them all using hg histedit. But my reviewers > can’t see the individual commits, nor can they be seen or reverted > individually in the long term project history. > > If this is the case it would also seem to be a major drawback to > Mercurial. There are further comments that suggest this may not be > quite so bad as Kun makes it sound, and indeed that part of his problem > might actually be specific to the workflow that his employer forces, but > there's also some ongoing doubt about this. I have no idea what the OP is talking about. Mercurial doesn't have pull requests, neither does git BTW. So this is about some specific web UI or review tool, but I don't even know which one. Joerg
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
On Tue, May 12, 2020 at 08:55:05PM -0700, Greg A. Woods wrote: > For one, Mercurial has no staging area. That removes one level of > the three-level hierarchy from my toolset. It’s hard to identify > exactly when in my workflow this causes issues, but I’ve started to > notice it. For example, it’s not possible to commit a hunk from my > editor like I can with git and vim-gitgutter. > > I do the same with magit -- the staging area is a supreme benefit! I disagree. Anyway, what git does here is "git add --patch" and the hg eqivalent is "hg record" (which is not enabled by default; just add "record=" in an "[extensions]" block in your .hgrc to enable it), so the functionality is available for both tools. > Mercurial also collapses all changes within a pull request > (changeset) into a single commit. That's just not true (as the next two comments in the thread clarify). Thomas
Re: ongoing git vs hg (was: github.com/NetBSD/src 5 days old?)
At Tue, 28 Apr 2020 08:50:55 +, m...@netbsd.org wrote: Subject: Re: github.com/NetBSD/src 5 days old? > > 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. So I've still not found any discussion explaining the reasoning behind Mercurial vs. anything/everything else. For me as I work independently on NetBSD it doesn't really matter what the back-end is so long as I can use Git for my day-to-day work and to keep better track of my local changes. (That, btw, is still very much just a work in progress for me -- I've been unable to use the current repo on github as it breaks after updates far too often, i.e. whenever the conversion is unstable somehow.) However it would seem to me to be better and easier, for me, to be able to publish those of my changes that I would hope to feed back to the main NetBSD repository via Git, and in such a way that my original commit metadata does not get lost or squashed or rewritten in any way. As-is this has been a major stumbling block for me w.r.t. feeding back some of my changes and fixes in terms of sending patches, etc. while NetBSD still uses CVS. Not knowing Mercurial myself, nor how it interoperates with Git, I'm unsure of whether this is possible or not, especially given whatever workflows the NetBSD core team comes up with. However I recently encountered this essay by Jeremy Kun which has presented some of my less-well formed thoughts in a more concrete way, and in particular one of his replies to a comment that was posted about his essay: "The Communicative Value of Using Git Well" https://jeremykun.com/2020/01/14/the-communicative-value-of-using-git-well/#comment-110432 For one, Mercurial has no staging area. That removes one level of the three-level hierarchy from my toolset. It’s hard to identify exactly when in my workflow this causes issues, but I’ve started to notice it. For example, it’s not possible to commit a hunk from my editor like I can with git and vim-gitgutter. I do the same with magit -- the staging area is a supreme benefit! I guess that it wouldn't matter if one used Git for day-to-day work and the back-end was still Mercurial, but that very much begs the question of just what benefit Mercurial can possibly bring in the long run. Mercurial also collapses all changes within a pull request (changeset) into a single commit. That removes the meaningful difference between the top level (pull request) and the mid level (commit) that I find helpful to narrate. There is some ability when working locally to create a bunch of commits like I would in git, and then later squash them all using hg histedit. But my reviewers can’t see the individual commits, nor can they be seen or reverted individually in the long term project history. If this is the case it would also seem to be a major drawback to Mercurial. There are further comments that suggest this may not be quite so bad as Kun makes it sound, and indeed that part of his problem might actually be specific to the workflow that his employer forces, but there's also some ongoing doubt about this. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms pgpZVBBmAGt5E.pgp Description: OpenPGP Digital Signature
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.
github.com/NetBSD/src 5 days old?
I switched away from cvsup a while back, but I now see that github NetBSD/src mirror is now 5 days old. Known issue? Thanks, -- Paul Ripke "Great minds discuss ideas, average minds discuss events, small minds discuss people." -- Disputed: Often attributed to Eleanor Roosevelt. 1948.
