SCM

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SCM

Австин Ким
Hi,

As someone completely new to OpenBSD the one immediate first impression that most peculiarly sticks out like a sore thumb to me is the Project’s use of CVS for source code management.  In the class I’m taking (the one for whose class project I just recently downloaded OpenBSD/macppc for the first time to install on IBM PowerPC 970/970MP-based Apple G5 hardware), we all use git for SCM which I think is typical at most universities nowadays (at least in the U. S.).  I am curious why the Project continues to use CVS and/or if developers have in the past considered migrating the codebase to a distributed SCM system like Mercurial which IMHO might make branching and merging easier on developers, especially more recent developers coming out of universities.  Is it because the Project prefers using a centralized versus distributed SCM system?  Or is it just because that’s just the way it has always been done and why change that?  And would migration to something like hg be a possibility in the future that might possibly lower the psychological barrier of entry for newer developers?  (And btw this is meant as a sincere question with no intention to start a contentious debate; really just asking out of curiosity because seeing CVS diffs in the mailing lists was what visually jumped out most prominently to me for the first time; I’m sure after spending more time with OpenBSD it could be something I could just get used to.)

Thanks for all the wonderful responses to my previous post which really helped me gain a better understanding of the Project!

All the best,
Austin

“If you want to change the future, start living as if you’re already there.”  —Lynn Conway

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Raul Miller
Both git and OpenBSD run on patches.

That said, OpenBSD has a cultural restriction of requiring people to
inspect the patches before incorporating them. Adopting git would be a
step away from that practice.

Does that help make sense of the current situation?

--
Raul

On Mon, Jul 22, 2019 at 11:04 AM Австин Ким <[hidden email]> wrote:

>
> Hi,
>
> As someone completely new to OpenBSD the one immediate first impression that most peculiarly sticks out like a sore thumb to me is the Project’s use of CVS for source code management.  In the class I’m taking (the one for whose class project I just recently downloaded OpenBSD/macppc for the first time to install on IBM PowerPC 970/970MP-based Apple G5 hardware), we all use git for SCM which I think is typical at most universities nowadays (at least in the U. S.).  I am curious why the Project continues to use CVS and/or if developers have in the past considered migrating the codebase to a distributed SCM system like Mercurial which IMHO might make branching and merging easier on developers, especially more recent developers coming out of universities.  Is it because the Project prefers using a centralized versus distributed SCM system?  Or is it just because that’s just the way it has always been done and why change that?  And would migration to something like hg be a possibility in the future that might possibly lower the psychological barrier of entry for newer developers?  (And btw this is meant as a sincere question with no intention to start a contentious debate; really just asking out of curiosity because seeing CVS diffs in the mailing lists was what visually jumped out most prominently to me for the first time; I’m sure after spending more time with OpenBSD it could be something I could just get used to.)
>
> Thanks for all the wonderful responses to my previous post which really helped me gain a better understanding of the Project!
>
> All the best,
> Austin
>
> “If you want to change the future, start living as if you’re already there.”  —Lynn Conway
>

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Andrew Luke Nesbit-2
On 22/07/2019 16:13, Raul Miller wrote:
> Both git and OpenBSD run on patches.
>
> That said, OpenBSD has a cultural restriction of requiring people to
> inspect the patches before incorporating them. Adopting git would be a
> step away from that practice.
>
> Does that help make sense of the current situation?

Raul, Австин, I hope you don't mind me jumping in.

Raul's answer raises fascinating questions about the nature of software
development and SCM.

Using _any_ SCM system and having meaningful discussion among developers
before integrating changes is much more important than the choice of
actual SCM system.

Andrew
--
OpenPGP key: EB28 0338 28B7 19DA DAB0  B193 D21D 996E 883B E5B9

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Ingo Schwarze
In reply to this post by Австин Ким
Avstin Kim wrote on Mon, Jul 22, 2019 at 10:58:50AM -0400:

> CVS for source code management.

That's kind of a frequently asked question.

Some of us (including myself) actually prefer CVS over git for tasks
where it is suffiecient because KISS.

Other developers prefer git for various reasons.

> I am curious why the Project continues to use CVS

The most important reasons are:

 (1) Switching from CVS to git is extremely hard.  Even with the
     best tools available, and even when you improve them further,
     it is hard, almost impossible, to avoid destroying part of the
     history during the conversion of the repository.  OpenBSD
     values correctness very highly, and it also highly values the
     abilty to audit code, including forensic auditing of code
     history to determine, once bugs are found, how they were able
     to happen.  So correctness and completeness of history matters.

 (2) Git is fragile and easy to misuse with surprising consequences.
     Well, admittedly, some aspects of CVS are also fragile, but
     the number of traps is smaller and developers are already
     used to the quirks of CVS, while the more numerous quirks
     of git would likely cause surprise and disruption.

 (3) Not all developers are convinced switching is even desirable,
     and never change a system that is working well unless there
     are strong reasons to change it.  I admit, though, that for
     very large commits, in particular for Perl updates and for
     sweeping infrastructure changes in the ports tree, there
     would be undeniable benefits from switching to git.

 (4) Almost all developers prefer working on actual quality and
     functionality of the system over spending time and effort on
     infrastructure around it, unless the latter is really
     important to make progress with the former.

> if developers have in the past considered migrating the codebase
> to a distributed SCM system

You can safely bet that they did.

Actually, switching to git has been considered very seriously
multiple times in the past and may or may not happen one day.

However, it requires rewriting git from scratch because the reference
implementation of git is not free software.  It comes infected with
a viral license.

That's another reason why switching implies a large effort and an
inevitable distraction from other, arguably more important OpenBSD
development.

Admittedly, the implementation of CVS we currently use isn't free
software either, it's GPLv1.  But we do not introduce any new
non-free software into the tree if there is any way to avoid that.

> Mercurial

Not free software either (same viral license), never used it
personally, and never heard any developer propose it.

> make branching and merging easier on developers,

Branching and merging ist strictly prohibited in the OpenBSD
repository.  Our development process simply neither needs nor allows
use of these features (except in a trivial way for -stable branches,
which novice developers never work on in the first place), so that's
not an argument at all.

Yours,
  Ingo

P.S.
Regarding what Raul Miller said:
Git does not require a particular development process but can support
a wide variety of different processes.  In particular, you can
require review of patches before push, and you can ban sending out
patchsets and require individual OKs for each indivual patch.  So
what you said does not qualify an an argument against using git.

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Stefan Sperling-5
In reply to this post by Австин Ким
On Mon, Jul 22, 2019 at 10:58:50AM -0400, Австин Ким wrote:

> Hi,
>
> As someone completely new to OpenBSD the one immediate first impression that most peculiarly sticks out like a sore thumb to me is the Project’s use of CVS for source code management.  In the class I’m taking (the one for whose class project I just recently downloaded OpenBSD/macppc for the first time to install on IBM PowerPC 970/970MP-based Apple G5 hardware), we all use git for SCM which I think is typical at most universities nowadays (at least in the U. S.).  I am curious why the Project continues to use CVS and/or if developers have in the past considered migrating the codebase to a distributed SCM system like Mercurial which IMHO might make branching and merging easier on developers, especially more recent developers coming out of universities.  Is it because the Project prefers using a centralized versus distributed SCM system?  Or is it just because that’s just the way it has always been done and why change that?  And would migration to something like hg be a possibility in the future that might possibly lower the psychological barrier of entry for newer developers?  (And btw this is meant as a sincere question with no intention to start a contentious debate; really just asking out of curiosity because seeing CVS diffs in the mailing lists was what visually jumped out most prominently to me for the first time; I’m sure after spending more time with OpenBSD it could be something I could just get used to.)
>
> Thanks for all the wonderful responses to my previous post which really helped me gain a better understanding of the Project!
>
> All the best,
> Austin
>
> “If you want to change the future, start living as if you’re already there.”  —Lynn Conway
>

CVS is good enough for the project for various reasons:

- CVS runs on old platforms with very low resources
- CVS scales reasonably well enough to the size of the source tree
- CVS allows updating individual subdirectories or files; this feature is
  used by machines building snapshots 24/7 across several CPU architectures
  from a single source tree
- CVS allows developers and users to update their source trees to -current
- CVS allows bad commits to be reverted
- CVS can cherry-pick commits to -stable branches
- Theo would know how to quickly fix a broken CVS repository if needed
- Assuming the version control system should be part of base (I would
  say it should): CVS is GPLv2 and has been in base since the beginning
  but new GPL software is not allowed in base. The only well-known system
  with a BSD licence would be fossil which doesn't scale to the size of
  the source tree.

Finding another version control system that satisfies all the above
without demanding changes in the environment and processes presently
surrounding CVS would not be trivial. Migrating to a different system
would be very time-intensive and costly in any case as it would disrupt
active developers, build machines, mirrors, and the release process.

That said, OpenBSD developers aren't only using CVS. Many are using some
complementary version control system locally to keep track of their own
changes. They then mail out patches which get committed to CVS and synced
back to their private version control systems in some way. There are various
workflows developers have come up with to manage their changes: some simply
save diffs generated with CVS; some use hg, git, fossil, etc.

If your university class prefers using git, I'd recommend the repository at
https://github.com/openbsd/src. This should be good enough for educational
purposes, even though, officially, it is not supported and could break at
any given moment.

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Juan Francisco Cantero Hurtado
In reply to this post by Ingo Schwarze
On Mon, Jul 22, 2019 at 05:48:13PM +0200, Ingo Schwarze wrote:

> Avstin Kim wrote on Mon, Jul 22, 2019 at 10:58:50AM -0400:
>
> > CVS for source code management.
>
> That's kind of a frequently asked question.
>
> Some of us (including myself) actually prefer CVS over git for tasks
> where it is suffiecient because KISS.
>
> Other developers prefer git for various reasons.
>
> > I am curious why the Project continues to use CVS
>
> The most important reasons are:
>
>  (1) Switching from CVS to git is extremely hard.  Even with the
>      best tools available, and even when you improve them further,
>      it is hard, almost impossible, to avoid destroying part of the
>      history during the conversion of the repository.  OpenBSD
>      values correctness very highly, and it also highly values the
>      abilty to audit code, including forensic auditing of code
>      history to determine, once bugs are found, how they were able
>      to happen.  So correctness and completeness of history matters.
>
>  (2) Git is fragile and easy to misuse with surprising consequences.
>      Well, admittedly, some aspects of CVS are also fragile, but
>      the number of traps is smaller and developers are already
>      used to the quirks of CVS, while the more numerous quirks
>      of git would likely cause surprise and disruption.
>
>  (3) Not all developers are convinced switching is even desirable,
>      and never change a system that is working well unless there
>      are strong reasons to change it.  I admit, though, that for
>      very large commits, in particular for Perl updates and for
>      sweeping infrastructure changes in the ports tree, there
>      would be undeniable benefits from switching to git.
>
>  (4) Almost all developers prefer working on actual quality and
>      functionality of the system over spending time and effort on
>      infrastructure around it, unless the latter is really
>      important to make progress with the former.
>
> > if developers have in the past considered migrating the codebase
> > to a distributed SCM system
>
> You can safely bet that they did.
>
> Actually, switching to git has been considered very seriously
> multiple times in the past and may or may not happen one day.
>
> However, it requires rewriting git from scratch because the reference
> implementation of git is not free software.  It comes infected with
> a viral license.
>
> That's another reason why switching implies a large effort and an
> inevitable distraction from other, arguably more important OpenBSD
> development.
>
> Admittedly, the implementation of CVS we currently use isn't free
> software either, it's GPLv1.  But we do not introduce any new
> non-free software into the tree if there is any way to avoid that.
>
> > Mercurial
>
> Not free software either (same viral license), never used it
> personally, and never heard any developer propose it.

Mercurial would require python in base and maybe someday it will require
also Rust.

https://www.mercurial-scm.org/wiki/OxidationPlan

>
> > make branching and merging easier on developers,
>
> Branching and merging ist strictly prohibited in the OpenBSD
> repository.  Our development process simply neither needs nor allows
> use of these features (except in a trivial way for -stable branches,
> which novice developers never work on in the first place), so that's
> not an argument at all.
>
> Yours,
>   Ingo
>
> P.S.
> Regarding what Raul Miller said:
> Git does not require a particular development process but can support
> a wide variety of different processes.  In particular, you can
> require review of patches before push, and you can ban sending out
> patchsets and require individual OKs for each indivual patch.  So
> what you said does not qualify an an argument against using git.
>

--
Juan Francisco Cantero Hurtado http://juanfra.info

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Nathan Hartman
In reply to this post by Ingo Schwarze
On Mon, Jul 22, 2019 at 11:49 AM Ingo Schwarze <[hidden email]> wrote:

> Avstin Kim wrote on Mon, Jul 22, 2019 at 10:58:50AM -0400:
>
> > CVS for source code management.
>
> That's kind of a frequently asked question.
>
> Some of us (including myself) actually prefer CVS over git for tasks
> where it is suffiecient because KISS.
>

I always assumed that the OpenBSD devs have audited the heck out of
CVS for security issues and are sticking to it for that reason.

KISS is a very valid reason though.

If the project ever did decide to switch, the closest cousin of CVS
is SVN, not hg, git, fossil, etc. Apache license...
Reply | Threaded
Open this post in threaded view
|

Re: SCM

Stuart Longland
In reply to this post by Ingo Schwarze
On 23/7/19 1:48 am, Ingo Schwarze wrote:
>> Mercurial
> Not free software either (same viral license), never used it
> personally, and never heard any developer propose it.

I believe Mozilla use it heavily.  I tried it and frankly, I prefer git.

There's also bazaar (used by Canonical), which is aptly named.

git does have some nice features for instance being able to 'bisect'
change sets when you strike a bug, and 'rebase' for migrating a
patch-set to another branch; but given how OpenBSD development appears
to operate, some of these features probably don't bring much to justify
the distraction of switching.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Stuart Longland
In reply to this post by Nathan Hartman
On 23/7/19 6:25 am, Nathan Hartman wrote:
> I always assumed that the OpenBSD devs have audited the heck out of
> CVS for security issues and are sticking to it for that reason.
>
> KISS is a very valid reason though.

Security as a by-product of the KISS principle perhaps?

When I see the security track record of OpenBSD, it's hard to argue
there's no point in their KISS approach.  Especially when you consider
the house of horrors that Linux is slowly morphing into.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Janne Johansson-3
In reply to this post by Австин Ким
Den mån 22 juli 2019 kl 17:05 skrev Австин Ким <[hidden email]>:

> Hi,
>
> As someone completely new to OpenBSD the one immediate first impression
> that most peculiarly sticks out like a sore thumb to me is the Project’s
> use of CVS for source code management.   I am curious why the Project
> continues to use CVS and/or if developers have in the past considered
> migrating the codebase to a distributed SCM system like Mercurial which
> IMHO might make branching and merging easier on developers, especially more
> recent developers coming out of universities.  Is it because the Project
> prefers using a centralized versus distributed SCM system?  Or is it just
> because that’s just the way it has always been done and why change that?
> And would migration to something like hg be a possibility in the future
> that might possibly lower the psychological barrier of entry for newer
> developers?  (And btw this is meant as a sincere question with no intention
> to start a contentious debate; really just asking out of curiosity because
> seeing CVS diffs in the mailing lists was what visually jumped out most
> prominently to me for the first time; I’m sure after spending more time
> with OpenBSD it could be something I could just get used to.)
> Thanks for all the wonderful responses to my previous post which really
> helped me gain a better understanding of the Project!
>


As Nick Holland wrote here on the same topic:
https://marc.info/?l=openbsd-misc&m=136724343006024&w=2
the last quote is kind of telling it all:
---
Want to sell OpenBSD on an alternative?  Find a product that was really
crappy, switched development tools, and suddenly started rivaling
OpenBSD for quality for no reason other than the switch of development
tools.
---

--
May the most significant bit of your life be positive.
Reply | Threaded
Open this post in threaded view
|

Re: SCM

Stuart Henderson
In reply to this post by Stefan Sperling-5
On 2019-07-22, Stefan Sperling <[hidden email]> wrote:
>
> If your university class prefers using git, I'd recommend the repository at
> https://github.com/openbsd/src.

However, it doesn't include branches/tags, because we haven't found anything that
is able to successfully convert the OpenBSD CVS repository to git unless it ignores
these.


Reply | Threaded
Open this post in threaded view
|

Re: SCM

Adam Thompson
On 2019-07-23 12:43, Stuart Henderson wrote:

> On 2019-07-22, Stefan Sperling <[hidden email]> wrote:
>>
>> If your university class prefers using git, I'd recommend the
>> repository at
>> https://github.com/openbsd/src.
>
> However, it doesn't include branches/tags, because we haven't found
> anything that
> is able to successfully convert the OpenBSD CVS repository to git
> unless it ignores
> these.

I haven't tried this with the OpenBSD code base, but in a previous life
I did a CVS to Git conversion starting with a repo that resembled
OpenBSD's in many ways.
The "solution" was to get to git by way of SVN.  SVN was able to
preserve branches/tags/etc. from CVS into SVN, and was then able to in
turn be converted to git through SVN's git-compatibility layer (IIRC).
Whether this helps anyone out there... *shrug*
-Adam

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Stuart Henderson
The problem with tags/branches is on the input side (parsing RCS files), at
least we haven't had good results with cvsps-based tooling or
rcsparse-based. I don't think it will make much difference whether
conversion is by way of svn or not (except there will be extra
conversion-related artefacts going by way of svn).

It could likely be fixed on a one off conversion by repo surgery, but as
the master repo is unlikely to be switched (various reasons already
mentioned in this thread), conversion would need to be on an ongoing basis
without constant tweaks..

--
Sent from a phone, apologies for poor formatting.

On 23 July 2019 19:42:24 Adam Thompson <[hidden email]> wrote:

> On 2019-07-23 12:43, Stuart Henderson wrote:
>> On 2019-07-22, Stefan Sperling <[hidden email]> wrote:
>>>
>>> If your university class prefers using git, I'd recommend the
>>> repository at
>>> https://github.com/openbsd/src.
>>
>> However, it doesn't include branches/tags, because we haven't found
>> anything that
>> is able to successfully convert the OpenBSD CVS repository to git
>> unless it ignores
>> these.
>
> I haven't tried this with the OpenBSD code base, but in a previous life
> I did a CVS to Git conversion starting with a repo that resembled
> OpenBSD's in many ways.
> The "solution" was to get to git by way of SVN.  SVN was able to
> preserve branches/tags/etc. from CVS into SVN, and was then able to in
> turn be converted to git through SVN's git-compatibility layer (IIRC).
> Whether this helps anyone out there... *shrug*
> -Adam



Reply | Threaded
Open this post in threaded view
|

Re: SCM

Ingo Schwarze
In reply to this post by Nathan Hartman
Hi Nathan,

Nathan Hartman wrote on Mon, Jul 22, 2019 at 04:25:14PM -0400:

> I always assumed that the OpenBSD devs have audited the heck
> out of CVS for security issues

While many parts of the tree received auditing - and some even get
re-autited - that doesn't mean that *all* parts of the tree got
audited.  In particular, stuff living in the subtree /usr/src/gnu/,
an acronym which stands for "Gigantic and Nasty but Unavoidable",
is much less likely to receive auditing.  For stuff there that is
indeed Gigantic, the reason is obvious.  But even smaller /gnu/
stuff is less likely to receive auditing for several reasons:

 1. It's harder to audit.
    If you don't apply KNF and don't change the way the code is
    organized to match OpenBSD conventions, it is obvious why
    it is hard to audit.  If you do, that implies forking.
    And applying KNF and cleaning up code organization is really
    a lot of work.

 2. With a bad license, it's hardly worth it.
    Who would want to waste their time auditing GPL'ed code?
    Who would want to waste their time forking GPL'ed code?
    It will never become free anyway.
    So rewriting it from scratch is better - if you have the time.

 3. It's less fun.
    Auditing is (1) easier, (2) more effective, (3) and the more
    rewarding for the auditor the better the code quality already
    is.  Auditing low-quality or poorly written code is a real
    pain: slow, tedious, and it constantly keeps you wondering
    "yeuch, yet another bad habit - should i expunge that one,
    too, or would that mean going down a rabbit hole and never
    completing this audit at all?"

The latter point no. 3 may scare you.  Am i saying that work may
not get done because it is not fun?  Am i saying that code may not
get audited precisely because it is bad quality?  Yes, i am.
But isn't bad quality code in *more* need of auditing than good
quality code?  Yes, it is.

But we are talking about volunteer work here.  Many eyes only make
bugs shallow if the code is appealing enough to look at.  To a
certain degree, we do take importance of work work into account
when deciding what to work on.  But the fact is, only about 17.8%
of us are true masochists (mostly those attending certain ports
hackathons, easily reconizable by their explicit T-shirts).
That's not nearly enough for getting all of /usr/src/gnu audited.

> and are sticking to it for that reason.

No, i never heard anyone say that they audited GNU cvs, and it doesn't
seem very likely that i missed it.  Looking at the commit history, e.g.

https://cvsweb.openbsd.org/cgi-bin/cvsweb/src/gnu/usr.bin/cvs/src/?sortby=date

doesn't suggest it either.  There are many bug fixes and it was
touched by several specialized tree sweeps (like the "%s" tree sweep
a year ago), but i see nothing that looks like an audit.  It looks
like Stefan Esser & Sebastian Krahmer did some auditing of CVS in
2004, but that was not work done in the context of the OpenBSD
project.

Besides, sometimes software does get forked for OpenBSD and then
thoroughly audited, like Apache 1 was, and then replaced by something
leaner anyway, httpd(8) in the case of Apache 1.  And as far as i
know, henning@ and reyk@ are still on friendly terms with each
other.  ;-)

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Австин Ким
In reply to this post by Австин Ким
Hi, all,
Sorry, been hella busy rushing to finish final graduation projects for school
and had no idea so many people weighed in with so much awesome feedback!

> That said, OpenBSD has a cultural restriction of requiring people to
> inspect the patches before incorporating them. Adopting git would be a
> step away from that practice.
I was suggesting Mercurial (hg), not Git; I know Git would be problematic for
the OpenBSD Project in many ways.  Plus I find it unnecessarily complex.  And
also, regardless of which SCM was used, responsible area owners would obviously
be required to inspect patches before merging into the main branch, so I don't
see why adopting hg would necessarily be a step away from that practice.

> Some of us (including myself) actually prefer CVS over git for tasks
> where it is suffiecient because KISS.
I definitely appreciate the KISS argument, but I still feel that for new
developers Mercurial would present a lower learning curve than CVS; isn't that
also a fair measure of simplicity (conceptual simplicity)?

> it is hard, almost impossible, to avoid destroying part of the
> history during the conversion of the repository.
That argument makes sense; but on the flip side that argument also seems a
little fatalistic, basically resigning oneself to being stuck with CVS forever
because no one wants to invest the energy of activation required for migration.
I think back to how the FreeBSD Project moved heaven and earth to migrate from
CVS to SVN, a bold and technically challenging undertaking that impressed the
hell out of me personally; that was also not trivial, and I understand that the
FreeBSD Project has greater staffing and resources, but I honestly believe
OpenBSD developers could be up to the task of even a greater migration, e.g.,
from CVS to Mercurial (but only if >= 99% of the OpenBSD developer community
were all on board, i.e., a consensus of buy-in emerged from the community so
everyone would be all in so as not to engender hurt feelings or animosities).

> Almost all developers prefer working on actual quality and
> functionality of the system over spending time and effort on
> infrastructure around it, unless the latter is really
> important to make progress with the former.
I can't argue with that, and obviously code quality is infinitely more
important than what SCM you use, but I feel you run the risk of turning off
potential new developers coming out of colleges and universities who cut their
teeth on distributed SCM systems like hg and Git who might be taken aback at
why the Project is still stuck with CVS (and again, I am not advocating for
Git; though if it isn't obvious by now I really believe OpenBSD developers
would honestly like Mercurial; to me it just seems consistent with OpenBSD's
culture of cleanliness and simplicity).  I understand the flip-side argument,
that I'm sure some developers might be personally proud of having arcane CVS
knowledge borne out of slogging through for years with CVS, but to me that
seems more like an issue of personal pride than an indication that CVS is
objectively better than hg.

> However, it requires rewriting git from scratch because the reference
> implementation of git is not free software.  It comes infected with
> a viral license.
Isn't CVS also GPL-licensed?  Or did OpenBSD completely rewrite CVS from
scratch under a BSD license?  Mercurial is still GPL v2, which is at least
better than GPL v3?

Finally my biggest argument (besides making contributing to the Project more
inviting to new developers, especially recent CS/CE/EE graduates) would be that
the bold challenge of migrating the entire codebase from CVS to Mercurial would
present a once-in-a-lifetime opportunity to start over with a fresh, clean
slate, once and for all tackle any issues that plagued working with CVS, and
have the rare opportunity to reset and redefine new processes that capitalize
on a quarter century of OpenBSD developers' working on maintaining a codebase
that is second to none.  It would be a monumental, fresh, clean start, albeit
an immensely technically challenging one; but one I have no doubt OpenBSD
developers could surmount.

> Mercurial would require python in base and maybe someday it will require
> also Rust.
Wow, I have no counter-argument for that :/
Of all the arguments made for CVS over hg, for me this is the one sole argument
I don't have an adequate response to.

Thanks to everyone who shed light on this potentially fraught issue.  I really
appreciate eveyone who took the time to write thoughtful, insightful responses,
based on technical considerations as opposed to dogma.  I only wish the most
salient points could be distilled and presented on an About page for the
Project for future newbies like myself who are newly coming to OpenBSD without
the quarter century of past context and its concomitant biases and are just
initially struck by seeing a major contemporary project still using CVS.

Thanks so much again!
Austin

“If you want to change the future, start living as if you’re already there.”  —Lynn Conway

Reply | Threaded
Open this post in threaded view
|

Re: SCM

gwes-2


On 7/26/19 8:29 PM, Австин Ким wrote:

> Hi, all,
> Sorry, been hella busy rushing to finish final graduation projects for school
> and had no idea so many people weighed in with so much awesome feedback!
>
>> That said, OpenBSD has a cultural restriction of requiring people to
>> inspect the patches before incorporating them. Adopting git would be a
>> step away from that practice.
> I was suggesting Mercurial (hg), not Git; I know Git would be problematic for
> the OpenBSD Project in many ways.  Plus I find it unnecessarily complex.  And
> also, regardless of which SCM was used, responsible area owners would obviously
> be required to inspect patches before merging into the main branch, so I don't
> see why adopting hg would necessarily be a step away from that practice.
>
>> Some of us (including myself) actually prefer CVS over git for tasks
>> where it is suffiecient because KISS.
> I definitely appreciate the KISS argument, but I still feel that for new
> developers Mercurial would present a lower learning curve than CVS; isn't that
> also a fair measure of simplicity (conceptual simplicity)?
>
>> it is hard, almost impossible, to avoid destroying part of the
>> history during the conversion of the repository.
> That argument makes sense; but on the flip side that argument also seems a
> little fatalistic, basically resigning oneself to being stuck with CVS forever
> because no one wants to invest the energy of activation required for migration.
> I think back to how the FreeBSD Project moved heaven and earth to migrate from
> CVS to SVN, a bold and technically challenging undertaking that impressed the
> hell out of me personally; that was also not trivial, and I understand that the
> FreeBSD Project has greater staffing and resources, but I honestly believe
> OpenBSD developers could be up to the task of even a greater migration, e.g.,
> from CVS to Mercurial (but only if >= 99% of the OpenBSD developer community
> were all on board, i.e., a consensus of buy-in emerged from the community so
> everyone would be all in so as not to engender hurt feelings or animosities).
>
>> Almost all developers prefer working on actual quality and
>> functionality of the system over spending time and effort on
>> infrastructure around it, unless the latter is really
>> important to make progress with the former.
> I can't argue with that, and obviously code quality is infinitely more
> important than what SCM you use, but I feel you run the risk of turning off
> potential new developers coming out of colleges and universities who cut their
> teeth on distributed SCM systems like hg and Git who might be taken aback at
> why the Project is still stuck with CVS (and again, I am not advocating for
> Git; though if it isn't obvious by now I really believe OpenBSD developers
> would honestly like Mercurial; to me it just seems consistent with OpenBSD's
> culture of cleanliness and simplicity).  I understand the flip-side argument,
> that I'm sure some developers might be personally proud of having arcane CVS
> knowledge borne out of slogging through for years with CVS, but to me that
> seems more like an issue of personal pride than an indication that CVS is
> objectively better than hg.
>
>> However, it requires rewriting git from scratch because the reference
>> implementation of git is not free software.  It comes infected with
>> a viral license.
> Isn't CVS also GPL-licensed?  Or did OpenBSD completely rewrite CVS from
> scratch under a BSD license?  Mercurial is still GPL v2, which is at least
> better than GPL v3?
>
> Finally my biggest argument (besides making contributing to the Project more
> inviting to new developers, especially recent CS/CE/EE graduates) would be that
> the bold challenge of migrating the entire codebase from CVS to Mercurial would
> present a once-in-a-lifetime opportunity to start over with a fresh, clean
> slate, once and for all tackle any issues that plagued working with CVS, and
> have the rare opportunity to reset and redefine new processes that capitalize
> on a quarter century of OpenBSD developers' working on maintaining a codebase
> that is second to none.  It would be a monumental, fresh, clean start, albeit
> an immensely technically challenging one; but one I have no doubt OpenBSD
> developers could surmount.
>
>> Mercurial would require python in base and maybe someday it will require
>> also Rust.
> Wow, I have no counter-argument for that :/
> Of all the arguments made for CVS over hg, for me this is the one sole argument
> I don't have an adequate response to.
>
> Thanks to everyone who shed light on this potentially fraught issue.  I really
> appreciate eveyone who took the time to write thoughtful, insightful responses,
> based on technical considerations as opposed to dogma.  I only wish the most
> salient points could be distilled and presented on an About page for the
> Project for future newbies like myself who are newly coming to OpenBSD without
> the quarter century of past context and its concomitant biases and are just
> initially struck by seeing a major contemporary project still using CVS.
>
> Thanks so much again!
> Austin
>
> “If you want to change the future, start living as if you’re already there.”  —Lynn Conway
>
IMnotsoHO, what problem are you trying to solve?

My take:

CVS is perhaps the 'assembly language' of SCMS but it *is* simple and
reliable.
I've been hung out to dry by three or four different systems because the
database
got fried and nobody both authorized and knowledgeable was available.
Weekends, you know.

For a relatively small team with good intra-team communication, CVS
is both adequate and easy. OpenBSD has only one trunk. All branches are
private until they are merged into the trunk. This fits CVS very neatly.
The 3 versions under consideration at any time are: the current release,
the head of development, and *for serious problems* the previous release.

For someone *outside* the project, it's very easy [for some value of easy]
to download the head and put it anywhere you want and do what you want
with it. So people interested can use whatever they like. If you want
to look at history, there are no branches: just a sequence which you can
look at with cvsweb if you'd like.

If you want something adopted by OpenBSD it has to fit into current
when it is merged. Notice that diffs supplied are always against the most
recent checked-in version.

I'm not a member of the team - I've had the privilege of contributing
a few small things over the years. From watching, I believe that until
there's
either a great expansion of the project team or some other
very large incentive like cubic $$$ to hire people, CVS will still be the
software management system.

geoff steckel

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Nathan Hartman
In reply to this post by Австин Ким
On Fri, Jul 26, 2019 at 8:31 PM Австин Ким <[hidden email]> wrote:

> I can't argue with that, and obviously code quality is infinitely more
> important than what SCM you use, but I feel you run the risk of turning off
> potential new developers coming out of colleges and universities who cut
> their
> teeth on distributed SCM systems like hg and Git who might be taken aback
> at
> why the Project is still stuck with CVS (and again, I am not advocating for
> Git; though if it isn't obvious by now I really believe OpenBSD developers
> would honestly like Mercurial; to me it just seems consistent with
> OpenBSD's
> culture of cleanliness and simplicity).


One can cut one's teeth on git and believe whatever one wants to
believe but SCMs are not one-size-fits all.
* Distributed does not mean better.
* Centralized does not mean worse.
* CVS does not mean "stuck."
* Git does not mean smart.
* Hg does not mean Au.

Every project has its own requirements and should use the tools that
fit best.

*IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I
root for Subversion. Subversion offers the following advantages:

1. CVS's closest relative; fixes all of CVS's shortcomings.
2. Very easy to learn and use. You practically can't screw it up.
3. Immutable history, i.e., SAFE to use.
4. Handles a giant repository with ease. (Many git projects fracture
   into numerous repositories to work around git limitations, so you
   lose atomic commits and get a maintenance headache instead.)
5. Sparse checkouts.
6. Versioned properties attached to files and directories (git can't
   version directories).
7. Follow history through copies, moves, and renames.
8. Coded in C89. Very few dependencies.
9. Apache license. Not BSD but much closer than any GPL revision.

I'm sure you've heard bad things about Subversion. These old myths and
facts stopped being true a decade ago.
Reply | Threaded
Open this post in threaded view
|

Re: SCM

Stefan Sperling-5
On Sun, Jul 28, 2019 at 01:24:02PM -0400, Nathan Hartman wrote:
> *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I
> root for Subversion.

Vetoed, for 3 simple reasons:

 1) Wrong licence

 2) FreeBSD uses it

 3) I don't want to be held responsible when it breaks on Theo

--
Stefan Sperling <[hidden email]>
V.P., Apache Subversion
ASF member (https://www.apache.org/foundation/members.html)
PGP fingerprint: B1CF 1060 A1E9 34D1 9E86  D6D6 E5D3 0273 F59D 25F0

Reply | Threaded
Open this post in threaded view
|

Re: SCM

Nathan Hartman
On Sun, Jul 28, 2019 at 3:27 PM Stefan Sperling <[hidden email]> wrote:

> On Sun, Jul 28, 2019 at 01:24:02PM -0400, Nathan Hartman wrote:
> > *IF* the OpenBSD devs ever wants to change SCMs--I said **IF**--then I
> > root for Subversion.
>
> Vetoed, for 3 simple reasons:
>

(snip)


>  3) I don't want to be held responsible when it breaks on Theo
>

THAT is definitely a valid reason!
Reply | Threaded
Open this post in threaded view
|

Re: SCM

Aaron Mason
In reply to this post by Nathan Hartman
On Mon, Jul 29, 2019 at 3:25 AM Nathan Hartman <[hidden email]> wrote:
(snip)
> * Hg does not mean Au.

I see what you did there :)

<snip>
> 9. Apache license. Not BSD but much closer than any GPL revision.

Yeah, hard pass.  The Apache license is full of encumbering legalese.
They stopped including Apache in base (after supporting a 1.x tree for
years) for this very reason.

--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse

12