date:20200617


Good Morning all,

Last night I took a try and wanted to clone the src Mercurial repository.

Shortly before putting the children to bed I issued the following command:

mpeterma@x220Mk2$ hg clone https://anonhg.NetBSD.org/src
Zielverzeichnis: src

The actual transfer of the change sets via the network only seemed to 
take about half an hour. What happened afterwards seemed to use up the 
CPU very much and never came to an end on the same evening. This morning 
- about 11 hours later - the process still seems to be very busy. The 
computer literally boils, a Python process hangs on 100% and consumes 2 
GB of RAM. And there is still no end in sight:


applying clone bundle from 
https://anonhg.NetBSD.org/_bundles/src/77d2a2ece3a06d837da45acd0fda80086ab4113c.zstd.hg

Füge Änderungssätze hinzu
Füge Manifeste hinzu 


Füge Dateiänderungen hinzu

I have now stopped the attempt. Cloning the comparable repository via 
Git took about as long as it took me to write this email.


After this experience, I actually only have one question about SCM for 
NetBSD: What are other requirements besides the subjective perception of 
usability that the NetBSD project places on its core SCM? Especially 
with regard to the performance data for the typical use cases. For me, 
NetBSD is the slimmest of the BSD Unix-like operating systems, which is 
particularly suitable for less powerful computers due to its excellent 
support of different architectures. One of the advantages of NetBSD for 
me has always been that the largest possible part of the developer 
workflow can also run on less well-equipped computers. My first Intel PC 
was a 386DX20 from Compaq, which I got in 1995 from a friend, whom I 
helped as an apprentice to build his house. I had no money for something 
better and still had my first experience with Linux on this device, 
since all essential components of the development system (kernel, base, 
compiler, debugger) were roughly synchronous with regard to your 
requirements. That seems to be shifting more and more these days. The 
product (kernel, base) also runs on slow computers, with the rest more 
and more compromises are permitted. If it brings a really overwhelming 
benefit, that's okay too. But in the area of SCM, where apparently 
there is great subjectivity, there are different tastes, and there is a 
clear preference in the entire open source community, such factors 
should also be taken into account. For me, Mercurial's performance is 
unacceptable. What are your experiences with it? Or maybe I just have a 
configuration problem? It shouldn't be on the computer - Thinkpad X220 
with i5 and 8 GB RAM.


Kind regards
Matthias

Re: cvs better than git?

2020-06-17 Thread Jay Patel

Maybe use http://gameoftrees.org/ and/or https://github.com/vlang/gitly

On Thu, 18 Jun 2020 at 9:25 am Mayuresh wrote:
>  On Wed, Jun 17, 2020 at 09:11:04AM -0700, Michael Cheponis wrote:
> Perhaps, if there were a commitment to stick with gitless, the confusion
> and pain that git sometimes creates could be eliminated.

Thanks for the pointers.

I think as a first step we may like to have gitless in pkgsrc so that the
community here gets to tinker with it. We'll be able to judge things
better after a while. Or is it in wip already?

Mayuresh

[https://api.criptext.com/email/open/%3C1592452601671.842009%40criptext.com%3E]

Re: cvs better than git?

On Wed, Jun 17, 2020 at 09:11:04AM -0700, Michael Cheponis wrote:
> Perhaps, if there were a commitment to stick with gitless, the confusion
> and pain that git sometimes creates could be eliminated.

Thanks for the pointers.

I think as a first step we may like to have gitless in pkgsrc so that the
community here gets to tinker with it. We'll be able to judge things
better after a while. Or is it in wip already?

Mayuresh.

Re: cvs better than git?

On Wed, Jun 17, 2020 at 03:42:44PM +0530, Mayuresh wrote:
> For pkgsrc I prefer the git mirror, as I don't have to push anything
> anyway and a few hours of latency doesn't matter to me.

Don't know whether it's relevant to say on this thread. May be it is.

When I use pkgsrc git mirror, after every few days I get this error when I
pull: "fatal: refusing to merge unrelated histories"

I do not know what *I* am doing wrong that leads to this. I do not even
change anything, leave alone branch or commit.

I do not know what is the `correct' way to fix this.

I do the simple. Delete pkgsrc and start over with a fresh checkout again.

Mayuresh

Boot error-messages

2020-06-17 Thread Todd Gruhn

Here is dmesg:

[ 1.00] Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001,
2002, 2003, 2004, 2005,
[ 1.00] 2006, 2007, 2008, 2009, 2010, 2011, 2012, 2013,
2014, 2015, 2016, 2017,
[ 1.00] 2018, 2019, 2020 The NetBSD Foundation, Inc.  All
rights reserved.
[ 1.00] Copyright (c) 1982, 1986, 1989, 1991, 1993
[ 1.00] The Regents of the University of California.  All
rights reserved.

[ 1.00] NetBSD 9.0_STABLE (MY-GENERIC) #0: Sat May  9 12:16:18 UTC 2020
[ 1.00]
tgr...@gandalf.gruhn-net.net:/usr/src/sys/arch/amd64/compile/MY-GENERIC
[ 1.00] total memory = 65467 MB
[ 1.00] avail memory = 63548 MB
[ 1.00] cpu_rng: RDSEED
[ 1.00] rnd: seeded with 256 bits
[ 1.00] timecounter: Timecounters tick every 10.000 msec
[ 1.00] running cgd selftest aes-xts-256 aes-xts-512 done
[ 1.00] timecounter: Timecounter "i8254" frequency 1193182 Hz
quality 100
[ 1.03] Gigabyte Technology Co., Ltd. Z390 GAMING X (Default string)
[ 1.03] mainbus0 (root)
[ 1.03] ACPI: RSDP 0x000F05B0 24 (v02 ALASKA)
[ 1.03] ACPI: XSDT 0x3E36C0A8 CC (v01 ALASKA A M I
   01072009 AMI  00010013)
[ 1.03] ACPI: FACP 0x3E3ACD80 000114 (v06 ALASKA A M I
   01072009 AMI  00010013)
[ 1.03] ACPI: DSDT 0x3E36C208 040B71 (v02 ALASKA A M I
   01072009 INTL 20160527)
[ 1.03] ACPI: FACS 0x3E407080 40
[ 1.03] ACPI: APIC 0x3E3ACE98 A0 (v04 ALASKA A M I
   01072009 AMI  00010013)
[ 1.03] ACPI: FPDT 0x3E3ACF38 44 (v01 ALASKA A M I
   01072009 AMI  00010013)
[ 1.03] ACPI: FIDT 0x3E3ACF80 9C (v01 ALASKA A M I
   01072009 AMI  00010013)
[ 1.03] ACPI: MCFG 0x3E3AD020 3C (v01 ALASKA A M I
   01072009 MSFT 0097)
[ 1.03] ACPI: SSDT 0x3E3AD060 000204 (v01 ALASKA A M I
   1000 INTL 20160527)
[ 1.03] ACPI: SSDT 0x3E3AD268 0017D5 (v02 ALASKA A M I
   3000 INTL 20160527)
[ 1.03] ACPI: SSDT 0x3E3AEA40 008056 (v01 ALASKA A M I
   0001 INTL 20160527)
[ 1.03] ACPI: SSDT 0x3E3B6A98 0031C7 (v02 ALASKA A M I
   3000 INTL 20160527)
[ 1.03] ACPI: SSDT 0x3E3B9C60 002358 (v02 ALASKA A M I
   1000 INTL 20160527)
[ 1.03] ACPI: HPET 0x3E3BBFB8 38 (v01 ALASKA A M I
   0002  0113)
[ 1.03] ACPI: SSDT 0x3E3BBFF0 000F9E (v02 ALASKA A M I
   1000 INTL 20160527)
[ 1.03] ACPI: SSDT 0x3E3BCF90 002D1B (v02 ALASKA A M I
    INTL 20160527)
[ 1.03] ACPI: UEFI 0x3E3BFCB0 42 (v01 ALASKA A M I
   0002  0113)
[ 1.03] ACPI: LPIT 0x3E3BFCF8 5C (v01 ALASKA A M I
   0002  0113)
[ 1.03] ACPI: SSDT 0x3E3BFD58 0027DE (v02 ALASKA A M I
   1000 INTL 20160527)
[ 1.03] ACPI: SSDT 0x3E3C2538 000FFE (v02 ALASKA A M I
    INTL 20160527)
[ 1.03] ACPI: DBGP 0x3E3C3538 34 (v01 ALASKA A M I
   0002  0113)
[ 1.03] ACPI: DBG2 0x3E3C3570 54 (v00 ALASKA A M I
   0002  0113)
[ 1.03] ACPI: DMAR 0x3E3C35C8 70 (v01 ALASKA A M I
   0002  0113)
[ 1.03] ACPI: WSMT 0x3E3C3638 28 (v01 ALASKA A M I
   01072009 AMI  00010013)
[ 1.03] ACPI: 10 ACPI AML tables successfully acquired and loaded
[ 1.03] ioapic0 at mainbus0 apid 2: pa 0xfec0, version
0x20, 120 pins
[ 1.03] cpu0 at mainbus0 apid 0
[ 1.03] cpu0: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, id 0x906ea
[ 1.03] cpu0: package 0, core 0, smt 0
[ 1.03] cpu1 at mainbus0 apid 2
[ 1.03] cpu1: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, id 0x906ea
[ 1.03] cpu1: package 0, core 1, smt 0
[ 1.03] cpu2 at mainbus0 apid 4
[ 1.03] cpu2: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, id 0x906ea
[ 1.03] cpu2: package 0, core 2, smt 0
[ 1.03] cpu3 at mainbus0 apid 6
[ 1.03] cpu3: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, id 0x906ea
[ 1.03] cpu3: package 0, core 3, smt 0
[ 1.03] cpu4 at mainbus0 apid 8
[ 1.03] cpu4: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, id 0x906ea
[ 1.03] cpu4: package 0, core 4, smt 0
[ 1.03] cpu5 at mainbus0 apid 10
[ 1.03] cpu5: Intel(R) Core(TM) i5-9400F CPU @ 2.90GHz, id 0x906ea
[ 1.03] cpu5: package 0, core 5, smt 0
[ 1.03] acpi0 at mainbus0: Intel ACPICA 20190405
[ 1.03] acpi0: X/RSDT: OemId , AslId

[ 1.03] acpi0: MCFG: segment 0, bus 0-255, address 0xe000
[ 1.03] ACPI: Dynamic OEM Table Load:
[ 1.03] ACPI: SSDT 0xFECE00B86008 000400 (v02 PmRef
Cpu0Cst  3001 INTL 20160527)
[ 1.03] ACPI: Dynamic OEM Table Load:
[ 1.03] ACPI: SSDT 0xFECE00B86808

Re: cvs better than git?


On 2020-06-18 00:06, Andreas Krey wrote:

On Wed, 17 Jun 2020 16:08:17 +, Jeffrey Walton wrote:
...

All those upvotes DO NOT indicate a good question. They indicate a
broken design.


They indicate a unixy design - it is *much* more simple and especially
open than, say, subversion.


Even the simplest of tasks are difficult to impossible
with Git.


Er, sorry. It is subversion where the answer to 'how do I do X'
usually is 'you should have done Y earlier' (and where cvs makes
you not even get the idea to ask the question in the first place).

None of the questions you quoted has 'you can't' as an answer, and most
have an answer that is shorter than the stackoverflow url of the question.


My position is, avoid Git if possible. It is a time sink that takes
time away from real work.


You mean unlike svn where you need a weird explanation ('mixed revision') why
'svn log .' doesn't show the commit you just made with 'svn commit filename'? 
:-)

Granted, there are two groups of users: Those that wants to know about and deal
with version control as little as possible (and in extremis just leave their
workspace, and let others do the commits), and those that *use* git because
there are lots of ways it can help that simply don't exist in other vcses.

To the latter, git is a godsent, to the former gitless is probably a good idea,
and the pertinent xkcd rings true.


This is very subjective, not to mention very different based on past 
experience, usage patterns and what not.


For me, I have no problem at all understanding what CVS or SVN does. I 
have used about 10 other version control systems in my life so far as well.


And for me, none of them come close to the obscurity and brokenness of 
git. I have had several git fanatics throw their hands up in despair 
when trying to figure out what has broken when I managed to get git into 
some strange state, and eventually capitulate and just tell me to wipe 
it all and start over.


In combination with tools to do code reviews and management of a central 
repository (using gerrit in my case) has only made it even worse.


So no. I totally do not agree with your characterizations. In fact, I 
would rather say that if you don't understand what CVS or SNV does, then 
that probably reflects more on you than anything else. And if you think 
you know how git works, and does things, then you clearly have a bright 
future in consulting, since so many people seem to have problems with it.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: cvs better than git?

2020-06-17 Thread Andreas Krey

On Wed, 17 Jun 2020 16:08:17 +, Jeffrey Walton wrote:
...
> All those upvotes DO NOT indicate a good question. They indicate a
> broken design.

They indicate a unixy design - it is *much* more simple and especially
open than, say, subversion.

> Even the simplest of tasks are difficult to impossible
> with Git.

Er, sorry. It is subversion where the answer to 'how do I do X'
usually is 'you should have done Y earlier' (and where cvs makes
you not even get the idea to ask the question in the first place).

None of the questions you quoted has 'you can't' as an answer, and most
have an answer that is shorter than the stackoverflow url of the question.

> My position is, avoid Git if possible. It is a time sink that takes
> time away from real work.

You mean unlike svn where you need a weird explanation ('mixed revision') why
'svn log .' doesn't show the commit you just made with 'svn commit filename'? 
:-)

Granted, there are two groups of users: Those that wants to know about and deal
with version control as little as possible (and in extremis just leave their
workspace, and let others do the commits), and those that *use* git because
there are lots of ways it can help that simply don't exist in other vcses.

To the latter, git is a godsent, to the former gitless is probably a good idea,
and the pertinent xkcd rings true.

- Andreas

-- 
"Totally trivial. Famous last words."
From: Linus Torvalds 
Date: Fri, 22 Jan 2010 07:29:21 -0800

Re: cvs better than git?

2020-06-17 Thread Sad Clouds

On Wed, 17 Jun 2020 16:08:17 -0400
Jeffrey Walton  wrote:

> My position is, avoid Git if possible. It is a time sink that takes
> time away from real work. Ignore the Fan Boi's when they ask for Git.
> The request often shows nativity or lack of experience with the tool.
> 
> Jeff

Over the years, I worked on different projects and even though I work
for the same company, we keep switching from one VCS to another.

First we used Subversion, which was OK.

Then people decided Subversion was crap, so they setup Git and Github.
This was just awful, especially the Github workflow, never in my life
before I had to jump through so many pointless hoops in order to commit
a single line fix.

Then we switched to Mercurial. There was no Github nonsense so that was
a relief, however it still sucked compared to the simplicity of
Subversion. There is talk now of switching from Mercurial to Git. And
the cycle continues...

OK I don't spend months meditating over Git manuals, so I don't feel the
force and will never become that Git Jedi Master that everybody else
claims to be these days. There is more to life, I want VCS to be as
simple as possible and to get out of the way, so I can focus on real
work at hand.

Re: cvs better than git?

2020-06-17 Thread Jeffrey Walton

On Wed, Jun 17, 2020 at 3:56 PM Michael Cheponis
 wrote:
>
> Where I work, we are forced into using git.  So, I've made peace using it.  
> Yes, it sucks.  Yes, it's glitter on ...something.  But there it is.  And I 
> personally use gitless, and find it's a clear model that works.
> ...
>
> If something's not broken otherwise, why change?   That's legitimate, too.

Take a look at these (from page 1 of
https://stackoverflow.com/questions?sort=votes):

* 
https://stackoverflow.com/questions/927358/how-do-i-undo-the-most-recent-local-commits-in-git
* 
https://stackoverflow.com/questions/2003505/how-do-i-delete-a-git-branch-locally-and-remotely
* 
https://stackoverflow.com/questions/292357/difference-between-git-pull-and-git-fetch
* https://stackoverflow.com/questions/348170/how-do-i-undo-git-add-before-commit
* https://stackoverflow.com/questions/6591213/how-do-i-rename-a-local-git-branch
* 
https://stackoverflow.com/questions/179123/how-to-modify-existing-unpushed-commit-messages

All those upvotes DO NOT indicate a good question. They indicate a
broken design. Even the simplest of tasks are difficult to impossible
with Git.

My position is, avoid Git if possible. It is a time sink that takes
time away from real work. Ignore the Fan Boi's when they ask for Git.
The request often shows nativity or lack of experience with the tool.

Jeff

Re: cvs better than git?

2020-06-17 Thread Michael Cheponis

Where I work, we are forced into using git.  So, I've made peace using it.
Yes, it sucks.  Yes, it's glitter on ...something.  But there it is.  And I
personally use gitless, and find it's a clear model that works.

BSD is important partly because it is NOT part of the linux monoculture.  I
understand.

I guess the real question is: is something broken?  For pkgsrc-wip, for a
bunch of reasons, they decided on git.

If something's not broken otherwise, why change?   That's legitimate, too.

On Wed, Jun 17, 2020 at 12:03 PM Sad Clouds 
wrote:

> On Wed, 17 Jun 2020 09:11:04 -0700
> Michael Cheponis  wrote:
>
> > If you want a thirty-minutes summary presentation, watch "What’s
> > Wrong With Git?" from Git Merge 2017
> > .
> >
> > The end result of this work is Gitless,  a simple version control
> > system built on top of Git.
>
> OK I get it - you can't polish a turd, but you can roll it in glitter.
>

Re: cvs better than git?

2020-06-17 Thread Sad Clouds

On Wed, 17 Jun 2020 09:11:04 -0700
Michael Cheponis  wrote:

> If you want a thirty-minutes summary presentation, watch "What’s
> Wrong With Git?" from Git Merge 2017
> .
> 
> The end result of this work is Gitless,  a simple version control
> system built on top of Git.

OK I get it - you can't polish a turd, but you can roll it in glitter.

Re: cvs better than git?

2020-06-17 Thread Aaron B.

On Wed, 17 Jun 2020 09:11:04 -0700
Michael Cheponis  wrote:

> 1) As much as folks (like me, Johnny) don't like it:  git is THE most
> widely-used rcs in the world, by far;  I consider it just a kind of
> annotated tar file.

This argument doesn't move me at all. Linux is the most widely used
unix-like OS, by far; the fact I am reading NetBSD mailing lists should
say the rest. :)

-- 
Aaron B.

Re: cvs better than git?

2020-06-17 Thread Michael Cheponis

Two points:

1) As much as folks (like me, Johnny) don't like it:  git is THE most
widely-used rcs in the world, by far;  I consider it just a kind of
annotated tar file.

2) git complexity (and user confusion) comes about due to the lack of
conceptual integrity of the design / command structure.  I believe it is
this problem which annoys most.

To work on this problem, MIT researchers published two papers:

   - Purposes, Concepts, Misfits, and a Redesign of Git

   S. P. De Rosso and D. Jackson. In *Proceedings of the 2016 ACM SIGPLAN
   International Conference on Object-Oriented Programming, Systems,
   Languages, and Applications (OOPSLA 2016)*
   - What's Wrong with Git? A Conceptual Design Analysis

   S. Perez De Rosso and D. Jackson. In *Proceedings of the 2013 ACM
   International Symposium on New Ideas, New Paradigms, and Reflections on
   Programming & Software (Onward! 2013)*

If you want a thirty-minutes summary presentation, watch "What’s Wrong With
Git?" from Git Merge 2017 .

The end result of this work is Gitless,  a simple version control system
built on top of Git.

https://gitless.com/

Perhaps, if there were a commitment to stick with gitless, the confusion
and pain that git sometimes creates could be eliminated.

On Wed, Jun 17, 2020 at 6:35 AM mayur...@kathe.in  wrote:

> On Wednesday, June 17, 2020 05:58 PM IST, Johnny Billquist <
> b...@update.uu.se> wrote:
>
> > On 2020-06-17 14:24, Mayuresh wrote:
> > > On Wed, Jun 17, 2020 at 02:07:46PM +0200, Johnny Billquist wrote:
> > >> I could go on about my objects, and the possible risks and issues,
> but I
> > >> think if this rant isn't enough to start you thinking, I doubt any
> more text
> > >> from me will change anything.
> > >
> > > Risk management is important. Given we do that, utilizing such
> services to
> > > our benefit isn't so bad - for example as a mirror rather than primary
> > > storage.
> > >
> > > I mean I'd not completely hold myself back from using such services,
> if I
> > > can benefit from them, as long as I am not being critically dependent
> on
> > > them.
> >
> > What is the benefit then? Now I'm being curious...
> >
> > I mean, if we would be having the primary repository our self, and just
> > have them be a mirror. Just a simple way of adding resources? Is the
> > load of people checking the code out that big? How much can we save
> > there then? Or what other benefits do you see?
>
> do you think high-quality, performant hardware and high-volume, quality
> network connectivity turns out to be as low-cost as "free" (service from
> github)?
> i second that idea of having a budget git repository on hardware owned by
> "the netbsd foundation" which is mirrored by github and takes care of all
> the load of all developers checking in/out their code.
> the project could save big-time on costs, have a safe primary repository
> of all the code, while reaping all the benefits of a large corporation
> offering free high-performance services to be at the developer-facing end

Re: cvs better than git?

On Wednesday, June 17, 2020 05:58 PM IST, Johnny Billquist  
wrote:

> On 2020-06-17 14:24, Mayuresh wrote:
> > On Wed, Jun 17, 2020 at 02:07:46PM +0200, Johnny Billquist wrote:
> >> I could go on about my objects, and the possible risks and issues, but I
> >> think if this rant isn't enough to start you thinking, I doubt any more 
> >> text
> >> from me will change anything.
> >
> > Risk management is important. Given we do that, utilizing such services to
> > our benefit isn't so bad - for example as a mirror rather than primary
> > storage.
> >
> > I mean I'd not completely hold myself back from using such services, if I
> > can benefit from them, as long as I am not being critically dependent on
> > them.
>
> What is the benefit then? Now I'm being curious...
>
> I mean, if we would be having the primary repository our self, and just
> have them be a mirror. Just a simple way of adding resources? Is the 
> load of people checking the code out that big? How much can we save
> there then? Or what other benefits do you see?

do you think high-quality, performant hardware and high-volume, quality network 
connectivity turns out to be as low-cost as "free" (service from github)?
i second that idea of having a budget git repository on hardware owned by "the 
netbsd foundation" which is mirrored by github and takes care of all the load 
of all developers checking in/out their code.
the project could save big-time on costs, have a safe primary repository of all 
the code, while reaping all the benefits of a large corporation offering free 
high-performance services to be at the developer-facing end.

Re: cvs better than git?

On Wed, Jun 17, 2020 at 02:28:27PM +0200, Johnny Billquist wrote:
> I mean, if we would be having the primary repository our self, and just have
> them be a mirror. Just a simple way of adding resources? Is the load of
> people checking the code out that big? How much can we save there then? Or
> what other benefits do you see?

Mirrors also serve as a backup.

Besides, I do think mirrors help and improve the experience as they are
also geographically distributed.

Quantification of that? No I don't have data to put it more objectively.

Mayuresh

Re: cvs better than git?


On 2020-06-17 14:24, Mayuresh wrote:

On Wed, Jun 17, 2020 at 02:07:46PM +0200, Johnny Billquist wrote:

I could go on about my objects, and the possible risks and issues, but I
think if this rant isn't enough to start you thinking, I doubt any more text
from me will change anything.


Risk management is important. Given we do that, utilizing such services to
our benefit isn't so bad - for example as a mirror rather than primary
storage.

I mean I'd not completely hold myself back from using such services, if I
can benefit from them, as long as I am not being critically dependent on
them.


What is the benefit then? Now I'm being curious...

I mean, if we would be having the primary repository our self, and just 
have them be a mirror. Just a simple way of adding resources? Is the 
load of people checking the code out that big? How much can we save 
there then? Or what other benefits do you see?


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: cvs better than git?

On Wed, Jun 17, 2020 at 02:07:46PM +0200, Johnny Billquist wrote:
> I could go on about my objects, and the possible risks and issues, but I
> think if this rant isn't enough to start you thinking, I doubt any more text
> from me will change anything.

Risk management is important. Given we do that, utilizing such services to
our benefit isn't so bad - for example as a mirror rather than primary
storage.

I mean I'd not completely hold myself back from using such services, if I
can benefit from them, as long as I am not being critically dependent on
them.

Mayuresh

Re: cvs better than git?


Hello,

Am 17.06.2020 um 14:07 schrieb Johnny Billquist:
My point is that you don't want to expose yourself to the risk. It's not 
about them not being able to take the code and do what they want. But 
how would you deal with, if all the code repository is outsourced, and 
they suddenly decide to stop their service, or start charging for it, or 
add a requirement that you have to include some stuff of their in your 
code? If you've offloaded all that work and infrastructure, you are 
pretty much at the mercy of whatever they decide to do. Start paying, or 
adding adware or extra software is one thing, and ugly enough, but what 
if they decide to shut down? What do you do then? You're going to have 
to hunt around for the next service available, and use whatever they 
offer. Which means a lot of work, possibly need to change tools, and so 
on. Well, that might also sortof be a case even if you are staying with 
one provider. If they decide to deprecate whatever tool/interface you 
are using, you will have to switch at their mercy. It's not your 
decision, or under your control. Neither the choice of tool, nor the 
timeline.


And this also goes into potential review and change of code. You have to 
trust them that nothing is inserted, changed, or lost. And any tools for 
automation are also dependent on what the hosting service offer or allow.


There are all kind of risks. Arguments like "I don't think they would do 
that" are sortof gambles. How much are you willing to bet on it? NetBSD 
have been using one system for close to 30 years. How many of the 
current hosting services do you expect to offer something stable for a 
comparable time?
Trying to recollect, I think SourceForce was what I was thinking of 
before, which did ugly things to projects, making a lot of them suddenly 
migrate away.


And honestly, any hosting service today is in the end commercial. If 
their business goes away, so will the service. And NetBSD might then 
just become a collateral victim.


I could go on about my objects, and the possible risks and issues, but I 
think if this rant isn't enough to start you thinking, I doubt any more 
text from me will change anything.


   Johnny



Just one more question for my understanding: the selection of the tool 
is not synonymous with the use of external service providers who host 
the repository with the help of this tool. There are many alternatives 
here and that in the case of git the choice has to fall on github, 
hasn't anyone said? By the way - hosting Git repositories with e.g. 
Gitea is not so terribly complicated that I would hire a full-time 
employee for it. Given the case that the hardware of at least one 
central mirror can be financed through sponsorship funds, there would be 
no reason not to use github as a read-only distributor for the masses as 
before. And if there should ever be a problem, you can simply replicate 
the read-only mirror elsewhere - if need be, also on your own 
infrastructure.


Kind regards
Matthias

Re: cvs better than git?


On 2020-06-17 13:45, Mayuresh wrote:

On Wed, Jun 17, 2020 at 01:36:33PM +0200, Johnny Billquist wrote:

Anyone who thinks something else is simply deluding themselves.


Obviously the hosts do whatever they do, and I agree it's no free lunch.
But they [can] do what they do even if they don't host us as the code is
open source anyway. So why not let them host anyway [may be as a mirror,
like pkgsrc is, so that we aren't totally dependent.]

PS: I am not arguing in favor of github or anything. Just curious what the
big deal is for an open source project.


My point is that you don't want to expose yourself to the risk. It's not 
about them not being able to take the code and do what they want. But 
how would you deal with, if all the code repository is outsourced, and 
they suddenly decide to stop their service, or start charging for it, or 
add a requirement that you have to include some stuff of their in your 
code? If you've offloaded all that work and infrastructure, you are 
pretty much at the mercy of whatever they decide to do. Start paying, or 
adding adware or extra software is one thing, and ugly enough, but what 
if they decide to shut down? What do you do then? You're going to have 
to hunt around for the next service available, and use whatever they 
offer. Which means a lot of work, possibly need to change tools, and so 
on. Well, that might also sortof be a case even if you are staying with 
one provider. If they decide to deprecate whatever tool/interface you 
are using, you will have to switch at their mercy. It's not your 
decision, or under your control. Neither the choice of tool, nor the 
timeline.


And this also goes into potential review and change of code. You have to 
trust them that nothing is inserted, changed, or lost. And any tools for 
automation are also dependent on what the hosting service offer or allow.


There are all kind of risks. Arguments like "I don't think they would do 
that" are sortof gambles. How much are you willing to bet on it? NetBSD 
have been using one system for close to 30 years. How many of the 
current hosting services do you expect to offer something stable for a 
comparable time?
Trying to recollect, I think SourceForce was what I was thinking of 
before, which did ugly things to projects, making a lot of them suddenly 
migrate away.


And honestly, any hosting service today is in the end commercial. If 
their business goes away, so will the service. And NetBSD might then 
just become a collateral victim.


I could go on about my objects, and the possible risks and issues, but I 
think if this rant isn't enough to start you thinking, I doubt any more 
text from me will change anything.


  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: cvs better than git?

On Wed, Jun 17, 2020 at 01:36:33PM +0200, Johnny Billquist wrote:
> Anyone who thinks something else is simply deluding themselves.

Obviously the hosts do whatever they do, and I agree it's no free lunch.
But they [can] do what they do even if they don't host us as the code is
open source anyway. So why not let them host anyway [may be as a mirror,
like pkgsrc is, so that we aren't totally dependent.]

PS: I am not arguing in favor of github or anything. Just curious what the
big deal is for an open source project.

Mayuresh

Re: cvs better than git?

On Wednesday, June 17, 2020 05:07 PM IST, Johnny Billquist  
wrote:

> On 2020-06-17 13:35, mayur...@kathe.in wrote:
> > there are _over_ 2 million organizations hosting their repositories at 
> > github.
> > microsoft just can't expect to get away with being fickle. you understand 
> > what i mean?
>
> I understand what you mean. I don't understand how you can believe it,
> though.

change is the only constant in this universe, and incidentally, microsoft has 
changed for the better.

Re: cvs better than git?

On Wednesday, June 17, 2020 05:06 PM IST, Johnny Billquist  
wrote:

> On 2020-06-17 12:37, mayur...@kathe.in wrote:
> >
> > reasons! i am thinking along the lines of "hg" being more modern that 
> > 'cvs', but _is_not_ "git".
> > but then again, _wip_ does use "git", so what's the problem with using 
> > "git" across the board?
> > for a project which is as financially constrained as "netbsd", it would 
> > make "a lot of sense" to out-source as much of the infrastructure to free 
> > services as possible.
> > also, as i'd written in previously, if countries are going to ban access to 
> > "github" because of some reason, there's no guarantee that they would not 
> > also ban access to "netbsd" repositories, even if they are using 'cvs' or 
> > "hg", and if github is being compelled to ban access to certain countries 
> > due to US government regulations, those same regulations would apply to the 
> > "netbsd foundation" too and hence lead to enactment of bans from certain 
> > countries by the foundation to "netbsd" repositories.
> > i wonder where the actual problem is, but something does smell fishy.
>
> By the way. When it comes to outsourcing the software repository, I can
> really sum up my objections in just one word:
>
> TANSTAAFL.
>
> Anyone who thinks something else is simply deluding themselves.

there is indeed no such thing as a free lunch.
when you host your repository of "open source" _non-commercial_ software, you 
really don't mind microsoft using it to build better commercial software 
development tools for their customers by analyzing the source repositories 
using "machine learning" techniques. no one is losing anything, in fact, unless 
you are a super secret code repository, you are benefiting from the eco-system.

Re: cvs better than git?


On 2020-06-17 13:35, mayur...@kathe.in wrote:

there are _over_ 2 million organizations hosting their repositories at github.
microsoft just can't expect to get away with being fickle. you understand what 
i mean?


I understand what you mean. I don't understand how you can believe it, 
though.


  Johnny



--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: cvs better than git?


On 2020-06-17 12:37, mayur...@kathe.in wrote:


reasons! i am thinking along the lines of "hg" being more modern that 'cvs', but _is_not_ 
"git".
but then again, _wip_ does use "git", so what's the problem with using "git" 
across the board?
for a project which is as financially constrained as "netbsd", it would make "a lot 
of sense" to out-source as much of the infrastructure to free services as possible.
also, as i'd written in previously, if countries are going to ban access to "github" because of some reason, there's no 
guarantee that they would not also ban access to "netbsd" repositories, even if they are using 'cvs' or "hg", 
and if github is being compelled to ban access to certain countries due to US government regulations, those same regulations 
would apply to the "netbsd foundation" too and hence lead to enactment of bans from certain countries by the foundation 
to "netbsd" repositories.
i wonder where the actual problem is, but something does smell fishy.


By the way. When it comes to outsourcing the software repository, I can 
really sum up my objections in just one word:


TANSTAAFL.

Anyone who thinks something else is simply deluding themselves.

  Johnny

--
Johnny Billquist  || "I'm on a bus
  ||  on a psychedelic trip
email: b...@softjar.se ||  Reading murder books
pdp is alive! ||  tryin' to stay hip" - B. Idol

Re: cvs better than git?

On Wednesday, June 17, 2020 04:57 PM IST, Johnny Billquist  
wrote:

> On 2020-06-17 12:37, mayur...@kathe.in wrote:
> > On Wednesday, June 17, 2020 03:42 PM IST, Mayuresh  wrote:
> >
> >> On Wed, Jun 17, 2020 at 11:51:48AM +0200, Matthias Petermann wrote:
> >>> Will downstream projects such as pkgsrc and pkgsrc-wip also adopt
> >>> Mercurial and use them as their official SCM? That would be great.
> >>
> >> wip adopted git after a lot of deliberation.. Hope we don't change it
> >> again... wip is the layer with largest count of people with push access
> >> and unless there is some really good reason changing again is unnecessary.
> >> [snip]
> >> I am unsure about reasons behind NetBSD's inclination towards hg instead
> >> of git.
> >
> > reasons! i am thinking along the lines of "hg" being more modern that 
> > 'cvs', but _is_not_ "git".
> > but then again, _wip_ does use "git", so what's the problem with using 
> > "git" across the board?
> > for a project which is as financially constrained as "netbsd", it would 
> > make "a lot of sense" to out-source as much of the infrastructure to free 
> > services as possible.
> > also, as i'd written in previously, if countries are going to ban access to 
> > "github" because of some reason, there's no guarantee that they would not 
> > also ban access to "netbsd" repositories, even if they are using 'cvs' or 
> > "hg", and if github is being compelled to ban access to certain countries 
> > due to US government regulations, those same regulations would apply to the 
> > "netbsd foundation" too and hence lead to enactment of bans from certain 
> > countries by the foundation to "netbsd" repositories.
> > i wonder where the actual problem is, but something does smell fishy.
>
> I know I'm in a very small minority here, but personally I hate git. I
> sortof suspect I will not like hg either, and when the switch happens,
> it might just mean I'll stop using NetBSD. The whole idea of local
> repositories and then trying to sync with a central one is just an added
> layer of problems, in my experience, with no added value. I don't know
> how many times I've seen local git getting so messed up the easy
> solution was just to wipe it all and start over again. A very
> windows-like mentality, which I'm sure more people today are perfectly
> fine with, but I'm not.
>
> However, I'm certainly not going to try to convince people to not move
> towards it. I just felt like ranting over a tool that is so broken in my
> view, but which it seems the whole world have gone crazy about. :-)
>
> But I see a clear problem with outsourcing the whole repository. There
> is much more to it that government regulations, even if that sometimes
> can also be an issue. But these kind of services can suddenly just go
> away, or change terms and conditions in a way that makes them not viable
> anymore. I have a really hard time understanding why anyone would want
> to put themselves at the mercy of something so fickle unless there is
> some other very compelling reason to do it.
>
> Seems like people think the only problem would be governments, for which
> the exact place or entity handling it matters less. And yes, with that I
> do agree. If it was only a concern with governments, then I would also
> not see any added value by running the infrastructure on my own. But for
> me, that is not the main reason, or even much of a reason at all.
>
> Which previous, initially free and open revision control repository was
> it which then ended up changing their terms and conditions so that
> everyone more or less had to move away immediately? I do remember that
> it did happen once already...

there are _over_ 2 million organizations hosting their repositories at github.
microsoft just can't expect to get away with being fickle. you understand what 
i mean?

Re: cvs better than git?

On 2020-06-17 12:37, mayur...@kathe.in wrote:

On Wednesday, June 17, 2020 03:42 PM IST, Mayuresh wrote:

On Wed, Jun 17, 2020 at 11:51:48AM +0200, Matthias Petermann wrote:

Will downstream projects such as pkgsrc and pkgsrc-wip also adopt
Mercurial and use them as their official SCM? That would be great.

wip adopted git after a lot of deliberation.. Hope we don't change it
again... wip is the layer with largest count of people with push access
and unless there is some really good reason changing again is unnecessary.
[snip]
I am unsure about reasons behind NetBSD's inclination towards hg instead
of git.

reasons! i am thinking along the lines of "hg" being more modern that 'cvs', but _is_not_
"git".
but then again, _wip_ does use "git", so what's the problem with using "git"
across the board?
for a project which is as financially constrained as "netbsd", it would make "a lot
of sense" to out-source as much of the infrastructure to free services as possible.
also, as i'd written in previously, if countries are going to ban access to "github" because of some reason, there's no
guarantee that they would not also ban access to "netbsd" repositories, even if they are using 'cvs' or "hg",
and if github is being compelled to ban access to certain countries due to US government regulations, those same regulations
would apply to the "netbsd foundation" too and hence lead to enactment of bans from certain countries by the foundation
to "netbsd" repositories.
i wonder where the actual problem is, but something does smell fishy.

I know I'm in a very small minority here, but personally I hate git. I
sortof suspect I will not like hg either, and when the switch happens,
it might just mean I'll stop using NetBSD. The whole idea of local
repositories and then trying to sync with a central one is just an added
layer of problems, in my experience, with no added value. I don't know
how many times I've seen local git getting so messed up the easy
solution was just to wipe it all and start over again. A very
windows-like mentality, which I'm sure more people today are perfectly
fine with, but I'm not.

However, I'm certainly not going to try to convince people to not move
towards it. I just felt like ranting over a tool that is so broken in my
view, but which it seems the whole world have gone crazy about. :-)

But I see a clear problem with outsourcing the whole repository. There
is much more to it that government regulations, even if that sometimes
can also be an issue. But these kind of services can suddenly just go
away, or change terms and conditions in a way that makes them not viable
anymore. I have a really hard time understanding why anyone would want
to put themselves at the mercy of something so fickle unless there is
some other very compelling reason to do it.

Seems like people think the only problem would be governments, for which
the exact place or entity handling it matters less. And yes, with that I
do agree. If it was only a concern with governments, then I would also
not see any added value by running the infrastructure on my own. But for
me, that is not the main reason, or even much of a reason at all.

Which previous, initially free and open revision control repository was
it which then ended up changing their terms and conditions so that
everyone more or less had to move away immediately? I do remember that
it did happen once already...

Johnny

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

Re: cvs better than git?

On Wed, Jun 17, 2020 at 01:13:21PM +0200, mayur...@kathe.in wrote:
> that's the primary reason why i stated that "something does smell fishy"
> about the core motives behind netbsd not being moved to github.

Well, the mirrors such as of pkgsrc are on github.

Own infra and github mirror vs github infra and own backup - there may be
differences but not to the extent of making it look fishy, at least to me.

Mayuresh

Re: cvs better than git?

On Wednesday, June 17, 2020 04:33 PM IST, Matthias Petermann 
 wrote:

> Hello,
>
> Am 17.06.2020 um 12:37 schrieb mayur...@kathe.in:
>
> >
> > reasons! i am thinking along the lines of "hg" being more modern that 
> > 'cvs', but _is_not_ "git".
> > but then again, _wip_ does use "git", so what's the problem with using 
> > "git" across the board?
> > for a project which is as financially constrained as "netbsd", it would 
> > make "a lot of sense" to out-source as much of the infrastructure to free 
> > services as possible.
> > also, as i'd written in previously, if countries are going to ban access to 
> > "github" because of some reason, there's no guarantee that they would not 
> > also ban access to "netbsd" repositories, even if they are using 'cvs' or 
> > "hg", and if github is being compelled to ban access to certain countries 
> > due to US government regulations, those same regulations would apply to the 
> > "netbsd foundation" too and hence lead to enactment of bans from certain 
> > countries by the foundation to "netbsd" repositories.
> > i wonder where the actual problem is, but something does smell fishy.
> >
>
> I see it a little differently. Regardless of geoblocking etc., in my 
> view it makes sense to invest in your own basic infrastructure. And if
> only as a scaled-down backup environment. Even customers who move their
> entire IT to cloud data centers do this. This is exactly how you secure
> your negotiating position in the event of contract changes, price
> increases or even termination of the services without notice. Caution
> should be exercised here, especially when it comes to free services, 
> because where there is no formal contract, the service can be
> discontinued or regulated at any time.
>
> But I also think that this discussion is not absolutely necessary. In
> the Git world in particular, it is very easy to set up automatic mirrors
> of upstream repositories and to keep them up to date. For example, I do
> it for all the open source libraries that are important to me, on which
> the solutions I create for customers depend. The NetBSD project could
> run its own replicas at any time, even without a "fat" and
> maintenance-intensive infrastructure. But then at least everything would
> be available for an emergency to get back on your feet quickly.

investing in minimal infrastructure for backups is fine, but i believe the 
resources (financial and human) required for initiating and maintaining a 
full-blown private versioning system must be wild.
as far as i know, even the "illumos" developers are using github as their 
primary infrastructure solution.
that's the primary reason why i stated that "something does smell fishy" about 
the core motives behind netbsd not being moved to github.

Re: cvs better than git?

Hello,

Am 17.06.2020 um 12:37 schrieb mayur...@kathe.in:

I see it a little differently. Regardless of geoblocking etc., in my
view it makes sense to invest in your own basic infrastructure. And if
only as a scaled-down backup environment. Even customers who move their
entire IT to cloud data centers do this. This is exactly how you secure
your negotiating position in the event of contract changes, price
increases or even termination of the services without notice. Caution
should be exercised here, especially when it comes to free services,
because where there is no formal contract, the service can be
discontinued or regulated at any time.

But I also think that this discussion is not absolutely necessary. In
the Git world in particular, it is very easy to set up automatic mirrors
of upstream repositories and to keep them up to date. For example, I do
it for all the open source libraries that are important to me, on which
the solutions I create for customers depend. The NetBSD project could
run its own replicas at any time, even without a "fat" and
maintenance-intensive infrastructure. But then at least everything would
be available for an emergency to get back on your feet quickly.

Kind regards
Matthias

Re: cvs better than git?

2020-06-17 Thread Jaromír Doleček

No. Neither Python nor mercurial/hg will be included in base.

Jaromir

Le mer. 17 juin 2020 à 12:56, Vitaly Shevtsov  a écrit :
>
> If NetBSD ever switchs to hg, does it mean that python will be
> included in base image because hg is written in Python?
>
> On Wed, Jun 17, 2020 at 3:38 PM mayur...@kathe.in  wrote:
> >
> > On Wednesday, June 17, 2020 03:42 PM IST, Mayuresh  wrote:
> >
> > > On Wed, Jun 17, 2020 at 11:51:48AM +0200, Matthias Petermann wrote:
> > > > Will downstream projects such as pkgsrc and pkgsrc-wip also adopt
> > > > Mercurial and use them as their official SCM? That would be great.
> > >
> > > wip adopted git after a lot of deliberation.. Hope we don't change it
> > > again... wip is the layer with largest count of people with push access
> > > and unless there is some really good reason changing again is unnecessary.
> > > [snip]
> > > I am unsure about reasons behind NetBSD's inclination towards hg instead
> > > of git.
> >
> > reasons! i am thinking along the lines of "hg" being more modern that 
> > 'cvs', but _is_not_ "git".
> > but then again, _wip_ does use "git", so what's the problem with using 
> > "git" across the board?
> > for a project which is as financially constrained as "netbsd", it would 
> > make "a lot of sense" to out-source as much of the infrastructure to free 
> > services as possible.
> > also, as i'd written in previously, if countries are going to ban access to 
> > "github" because of some reason, there's no guarantee that they would not 
> > also ban access to "netbsd" repositories, even if they are using 'cvs' or 
> > "hg", and if github is being compelled to ban access to certain countries 
> > due to US government regulations, those same regulations would apply to the 
> > "netbsd foundation" too and hence lead to enactment of bans from certain 
> > countries by the foundation to "netbsd" repositories.
> > i wonder where the actual problem is, but something does smell fishy.
> >

Re: cvs better than git?

2020-06-17 Thread Vitaly Shevtsov

If NetBSD ever switchs to hg, does it mean that python will be
included in base image because hg is written in Python?

On Wed, Jun 17, 2020 at 3:38 PM mayur...@kathe.in  wrote:
>
> On Wednesday, June 17, 2020 03:42 PM IST, Mayuresh  wrote:
>
> > On Wed, Jun 17, 2020 at 11:51:48AM +0200, Matthias Petermann wrote:
> > > Will downstream projects such as pkgsrc and pkgsrc-wip also adopt
> > > Mercurial and use them as their official SCM? That would be great.
> >
> > wip adopted git after a lot of deliberation.. Hope we don't change it
> > again... wip is the layer with largest count of people with push access
> > and unless there is some really good reason changing again is unnecessary.
> > [snip]
> > I am unsure about reasons behind NetBSD's inclination towards hg instead
> > of git.
>
> reasons! i am thinking along the lines of "hg" being more modern that 'cvs', 
> but _is_not_ "git".
> but then again, _wip_ does use "git", so what's the problem with using "git" 
> across the board?
> for a project which is as financially constrained as "netbsd", it would make 
> "a lot of sense" to out-source as much of the infrastructure to free services 
> as possible.
> also, as i'd written in previously, if countries are going to ban access to 
> "github" because of some reason, there's no guarantee that they would not 
> also ban access to "netbsd" repositories, even if they are using 'cvs' or 
> "hg", and if github is being compelled to ban access to certain countries due 
> to US government regulations, those same regulations would apply to the 
> "netbsd foundation" too and hence lead to enactment of bans from certain 
> countries by the foundation to "netbsd" repositories.
> i wonder where the actual problem is, but something does smell fishy.
>

Re: cvs better than git?

On Wednesday, June 17, 2020 03:42 PM IST, Mayuresh  wrote:

> On Wed, Jun 17, 2020 at 11:51:48AM +0200, Matthias Petermann wrote:
> > Will downstream projects such as pkgsrc and pkgsrc-wip also adopt
> > Mercurial and use them as their official SCM? That would be great.
>
> wip adopted git after a lot of deliberation.. Hope we don't change it
> again... wip is the layer with largest count of people with push access
> and unless there is some really good reason changing again is unnecessary.
> [snip]
> I am unsure about reasons behind NetBSD's inclination towards hg instead
> of git.

reasons! i am thinking along the lines of "hg" being more modern that 'cvs', 
but _is_not_ "git".
but then again, _wip_ does use "git", so what's the problem with using "git" 
across the board?
for a project which is as financially constrained as "netbsd", it would make "a 
lot of sense" to out-source as much of the infrastructure to free services as 
possible.
also, as i'd written in previously, if countries are going to ban access to 
"github" because of some reason, there's no guarantee that they would not also 
ban access to "netbsd" repositories, even if they are using 'cvs' or "hg", and 
if github is being compelled to ban access to certain countries due to US 
government regulations, those same regulations would apply to the "netbsd 
foundation" too and hence lead to enactment of bans from certain countries by 
the foundation to "netbsd" repositories.
i wonder where the actual problem is, but something does smell fishy.

Re: cvs better than git?

On Wed, Jun 17, 2020 at 11:51:48AM +0200, Matthias Petermann wrote:
> Will downstream projects such as pkgsrc and pkgsrc-wip also adopt
> Mercurial and use them as their official SCM? That would be great.

wip adopted git after a lot of deliberation.. Hope we don't change it
again... wip is the layer with largest count of people with push access
and unless there is some really good reason changing again is unnecessary.

[I recollect having argued against the CVS->git change once, but have come
to terms with git now. I'd argue to not change again from git->hg please!]

For pkgsrc I prefer the git mirror, as I don't have to push anything
anyway and a few hours of latency doesn't matter to me.

I rarely tinker with the base or kernel.

My personal experience is mercurial is good but very slow compared to git.
git is fast, widely adopted. Only time I faced problems with git was in a
very exotic situation where I was trying to run it on an encfs file system
and on NetBSD some low level calls used by git caused issues. But that's
too niche to worry about.

As of I studied last Hg was to adopt rust and was expected to reduce the
speed gap. Not sure about the status.

I am unsure about reasons behind NetBSD's inclination towards hg instead
of git.

Mayuresh

Re: cvs better than git?


Hello together,

I understand that migrating the source code of a project as big as 
NetBSD is a challenge that doesn't happen every day. And I am sure that 
the people who are dealing with it would have done it long ago if it 
were easy. I also want to believe that the choice of the next SCM tool 
was made taking all relevant facts into consideration. I had read an 
article a while ago that considered fossil, among other things. This 
seems to have been approached with great objectivity, which I think is 
very good.


On the other hand, I agree that since the beginning of the 
considerations (one can find recordings older than 10 years), all tools 
have developed further and that Git has now become widely accepted. Much 
of what was previously considered a disadvantage of Git has now been 
eliminated or moved into the background. I personally have nothing 
against Mercurial and have used it for a while. I can remember times 
when Mercurial was much more intuitive to use than Git. I also used 
Subversion at work, and sometimes fossil for small-scale 
"self-contained" projects. Ultimately, I was drawn to Git. For me, the 
mix of


* Speed even on slower computers
* the now mature user experience
* The good selection of tools for management and self-hosting

was crucial. But I'm also not afraid of another change.

Is there an official statement about the future SCM somewhere on the 
NetBSD site? A quick Google search brought me some interesting results:


* https://www.netbsd.org/developers/mercurial/
* http://www.netbsd.org/~dholland/notes/hg-migration/usage.html

This really looks very well thought out and shows that the choice of the 
tool alone is not enough, but that the process around it is what matters 
most. If it is certain that Mercurial will be the future SCM for NetBSD, 
I would like to use it as soon as possible in my NetBSD-related work to 
gain new experience. Will downstream projects such as pkgsrc and 
pkgsrc-wip also adopt Mercurial and use them as their official SCM? That 
would be great.


Many Greetings
Matthias

Am 17.06.2020 um 10:46 schrieb Martin Husemann:

On Wed, Jun 17, 2020 at 10:40:36AM +0200, mayur...@kathe.in wrote:

i am not an expert at version control systems to understand this by myself.
would like to understand why 'cvs' is preferred over "git" under netbsd.


It is not prefered. Just moving from one system to another is an
enormous task with something as big as the NetBSD repository - and when
the repository was created, many of todays alternatives did not yet
exist.

We will be moving from cvs to mercurial some time real soon, and from
there other formats (like git) are easily (and instantly) available.

Of course you can (for read-only access) use the git mirror now already
(with a small delay of a few hours caused by the transformation process).

Martin

Re: cvs better than git?

On Wednesday, June 17, 2020 02:40 PM IST, Nikita Gillmann  wrote:

>
> On 2020-06-17 10:55, mayur...@kathe.in wrote:
> > On Wednesday, June 17, 2020 02:16 PM IST, Martin Husemann 
> >  wrote:
> >
> >> On Wed, Jun 17, 2020 at 10:40:36AM +0200, mayur...@kathe.in wrote:
> >>> i am not an expert at version control systems to understand this by 
> >>> myself.
> >>> would like to understand why 'cvs' is preferred over "git" under netbsd.
> >> It is not prefered. Just moving from one system to another is an
> >> enormous task with something as big as the NetBSD repository - and when
> >> the repository was created, many of todays alternatives did not yet
> >> exist.
> >>
> >> We will be moving from cvs to mercurial some time real soon, and from
> >> there other formats (like git) are easily (and instantly) available.
> >>
> >> Of course you can (for read-only access) use the git mirror now already
> >> (with a small delay of a few hours caused by the transformation process).
> > thank you for the detailed and pertinent response.
> > i can understand why netbsd started off with 'cvs' and has stuck with it 
> > for so long, but now that something like "git" is available then why not 
> > move to it instead of "mercurial"? that way the project can move the source 
> > repository to github and lessen one of the loads of managing the 
> > infrastructure for the source code management system, or is moving to 
> > github not considered safe because of the service's ownership by microsoft?
> >
> I seem to remember that moving to GitHub is not an option because of
> infrastructure and security requirements,
>
> and outsorcing it to Github comes with additional issues like GH being
> blocked in some countries.
>
> mercurial is as old as git, but git has an (visibly) higher usage rate
> in open source projects today.
>
> mercurial -> git migration would takes less time if CVS->mercurial is
> done once properly.

that was a great response, also i read-up about mercurial and it seems just as 
modern, but my suggestion lies more directed at reducing infrastructure 
acquisition and management costs which can best be handled by outsourcing to a 
service like "github", but what i can't seem to figure out is that the 
anticipation of blockage of access by certain countries due to US trade bans 
seems to be mandated by the government, so if microsoft is being made to block 
iran by the government, wouldn't "the netbsd foundation" too be compelled to 
follow suit? i mean netbsd isn't allowed to export certain cryptographic 
components due to government regulations to be followed by all US 
organizations, isn't it?
also, if countries like china are blocking most US services like facebook and 
twitter and sometimes also github, wouldn't they also target netbsd's 
infrastructure? (given it's US origins).

Re: cvs better than git?

2020-06-17 Thread Nikita Gillmann



On 2020-06-17 10:55, mayur...@kathe.in wrote:
> On Wednesday, June 17, 2020 02:16 PM IST, Martin Husemann 
>  wrote: 
>  
>> On Wed, Jun 17, 2020 at 10:40:36AM +0200, mayur...@kathe.in wrote:
>>> i am not an expert at version control systems to understand this by myself.
>>> would like to understand why 'cvs' is preferred over "git" under netbsd.
>> It is not prefered. Just moving from one system to another is an
>> enormous task with something as big as the NetBSD repository - and when
>> the repository was created, many of todays alternatives did not yet
>> exist.
>>
>> We will be moving from cvs to mercurial some time real soon, and from
>> there other formats (like git) are easily (and instantly) available.
>>
>> Of course you can (for read-only access) use the git mirror now already
>> (with a small delay of a few hours caused by the transformation process).
> thank you for the detailed and pertinent response.
> i can understand why netbsd started off with 'cvs' and has stuck with it for 
> so long, but now that something like "git" is available then why not move to 
> it instead of "mercurial"? that way the project can move the source 
> repository to github and lessen one of the loads of managing the 
> infrastructure for the source code management system, or is moving to github 
> not considered safe because of the service's ownership by microsoft?
>
I seem to remember that moving to GitHub is not an option because of
infrastructure and security requirements,

and outsorcing it to Github comes with additional issues like GH being
blocked in some countries.

mercurial is as old as git, but git has an (visibly) higher usage rate
in open source projects today.

mercurial -> git migration would takes less time if CVS->mercurial is
done once properly.

Re: cvs better than git?

On Wednesday, June 17, 2020 02:16 PM IST, Martin Husemann  
wrote:

> On Wed, Jun 17, 2020 at 10:40:36AM +0200, mayur...@kathe.in wrote:
> > i am not an expert at version control systems to understand this by myself.
> > would like to understand why 'cvs' is preferred over "git" under netbsd.
>
> It is not prefered. Just moving from one system to another is an
> enormous task with something as big as the NetBSD repository - and when
> the repository was created, many of todays alternatives did not yet
> exist.
>
> We will be moving from cvs to mercurial some time real soon, and from
> there other formats (like git) are easily (and instantly) available.
>
> Of course you can (for read-only access) use the git mirror now already
> (with a small delay of a few hours caused by the transformation process).

thank you for the detailed and pertinent response.
i can understand why netbsd started off with 'cvs' and has stuck with it for so 
long, but now that something like "git" is available then why not move to it 
instead of "mercurial"? that way the project can move the source repository to 
github and lessen one of the loads of managing the infrastructure for the 
source code management system, or is moving to github not considered safe 
because of the service's ownership by microsoft?

Re: cvs better than git?

2020-06-17 Thread Benny Siegert

Please read the archives of the tech-repository list. This has been
discussed to death.

mayur...@kathe.in  schrieb am Mi., 17. Juni 2020, 10:40:

> i am not an expert at version control systems to understand this by myself.
> would like to understand why 'cvs' is preferred over "git" under netbsd.
>
>

Re: cvs better than git?

2020-06-17 Thread Martin Husemann

On Wed, Jun 17, 2020 at 10:40:36AM +0200, mayur...@kathe.in wrote:
> i am not an expert at version control systems to understand this by myself.
> would like to understand why 'cvs' is preferred over "git" under netbsd.

It is not prefered. Just moving from one system to another is an
enormous task with something as big as the NetBSD repository - and when
the repository was created, many of todays alternatives did not yet
exist.

We will be moving from cvs to mercurial some time real soon, and from
there other formats (like git) are easily (and instantly) available.

Of course you can (for read-only access) use the git mirror now already
(with a small delay of a few hours caused by the transformation process).

Martin

cvs better than git?