Announcement: Skara update to support CVS and SourceForge
forax at univ-mlv.fr
forax at univ-mlv.fr
Thu Apr 1 12:54:09 UTC 2021
----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Magnus Ihse Bursie" <magnus.ihse.bursie at oracle.com>, "announce" <announce at openjdk.java.net>, "skara-dev"
> <skara-dev at openjdk.java.net>, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Jeudi 1 Avril 2021 11:23:05
> Objet: Re: Announcement: Skara update to support CVS and SourceForge
> On Apr 1, 2021, at 1:55 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>>
>> Hi Magnus,
>> at last !
>> We can now say that the OpenJDK is pulling forward.
>>
>> Is there a SCCS addon somewhere, because it will be hard for me to migrate
>> otherwise ?
>>
>> Rémi
>
> No, Remi, there is no SCCS view, because RCS is superior.
>
> RCS uses backward deltas, as any reasonable versioning
> scheme must, because deriving the current version of
> a file must be faster than deriving a historic version.
> SCCS is wrong-headedly out of step with history,
> because it uses forward deltas, and thus requires
> the CPU-wasting recapitulation of the entire history
> of a file in order to materialize its most recent version.
For me, RCS, CVS, SVN and Git are the losers, because they are thinking in term of how beautiful and fast their internal data structures are instead of term of user model, a versioned code is a graph of patches,
at least with SCCS, you have a list of patches, that's why SCCS is far better than any other SCMs.
As a users, i don't care about git rerere being fast, i want to see a graph of patches and be able to bubble them up/down/"on the side" so i don't need git rerere.
While i get why Linus Torvald wants each commit to have a SHA for the linux kernel, in practice, it means that i can not swap two patches easily, why the tree of software versions (where you need SHA) and the graph of patches has to be the very same data structure ?
>
> Thus, SCCS is almost as dumb as a loser-system which
> which would store bit-images of *every* version of a file,
> and then (magically, as if it were possible) would retrieve
> those bit images on demand by some sort of magic
> name. Hah, as if one could build some sort of
> interplanetary file system (they’d call it “IPFS”,
> the losers) that just shared files by *wishing*
> for them!
>
> — John
>
> P.S. I once wrote an SCCS ingester in Java,
> when HotSpot was stored in SCCS. I lost it.
> True facts, those.
Rémi
More information about the jdk-dev
mailing list