From Newsgroup: comp.os.vms

I grabbed standard SVNKit:
https://www.svnkit.com/com.tmatesoft.svn_1.10.13.standalone.nojna.zip

I unzipped.

I defined command:

$ jsvn == "''java' -cp /disk2/arne/jsvn/lib/* org.tmatesoft.svn.cli.SVN"

And it seems to work out of the box.

(I have some problems with files created on Windows with CRLF end up on
VMS with trailing CR's, but I am pretty sure that would be the same
problem on Linux, so not a VMS problem)

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Mon, 2 Mar 2026 12:23:26 -0500, Arne Vajh|+j wrote:

And it seems to work out of the box.

Linus Torvalds said <https://www.youtube.com/watch?v=4XpnKHJAok8> in
his Google Tech Talk on Git (transcript <https://gist.github.com/dukeofgaming/2150263>):

When I say I hate CVS with a passion, I have to also say that if
there any SVN users (Subversion users) in the audience, you might
want to leave. Because my hatred of CVS has meant that I see
Subversion as being the most pointless project ever started,
because the whole slogan for the Subversion for a while was 'CVS
done right' or something like that. And if you start with that
kind of slogan, there is nowhere you can go. It's like, there is
no way to do CVS right.

(Found thanks to <https://news.ycombinator.com/item?id=32672498>.)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/2/26 6:23 PM, Arne Vajh|+j wrote:

I grabbed standard SVNKit:
...
$ jsvn == "''java' -cp /disk2/arne/jsvn/lib/* org.tmatesoft.svn.cli.SVN"
...
(I have some problems with files created on Windows with CRLF end up on
VMS with trailing CR's, but I am pretty sure that would be the same
problem on Linux, so not a VMS problem)

Do the Windows files end up on VMS as stmlf? Then there are "trailing"
CRs. As you probably know, you can change the rfm to stm. Then on VMS
you should not see the CRs. Or you can convert the file with CONVERT/FDL
to stream_lf (Yes, FDL keywords and set FILE/ATTRIBUTE keywords differ.)
I don't know, whether the VMS JVM can handle VMS stm files or not. You
may want to give some more details on how these files end up on VMS. And
yes, many Linux tools can handle Windows files without any problem.
Whether svn on Linux or jSVN on the Linux JVM can do this, I don't know. (Unfortunately what you showed on how to use jSVN on the VMS JVM was not enough for me to run and try jSVN on the Linux JVM. But I admit, I
prefer git, anyway.)
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 03/03/2026 13:42, hb0815 wrote:

On 3/2/26 6:23 PM, Arne Vajh|+j wrote:

I grabbed standard SVNKit:
...
$ jsvn == "''java' -cp /disk2/arne/jsvn/lib/* org.tmatesoft.svn.cli.SVN"
...
(I have some problems with files created on Windows with CRLF end up on
VMS with trailing CR's, but I am pretty sure that would be the same
problem on Linux, so not a VMS problem)

Do the Windows files end up on VMS as stmlf? Then there are "trailing"
CRs. As you probably know, you can change the rfm to stm. Then on VMS
you should not see the CRs. Or you can convert the file with CONVERT/FDL
to stream_lf (Yes, FDL keywords and set FILE/ATTRIBUTE keywords differ.)
I don't know, whether the VMS JVM can handle VMS stm files or not. You
may want to give some more details on how these files end up on VMS. And yes, many Linux tools can handle Windows files without any problem.
Whether svn on Linux or jSVN on the Linux JVM can do this, I don't know. (Unfortunately what you showed on how to use jSVN on the VMS JVM was not enough for me to run and try jSVN on the Linux JVM. But I admit, I
prefer git, anyway.)

Plenty of us old Gits here anyway ;)
--
Chris
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/3/2026 9:13 AM, Chris Townley wrote:

On 03/03/2026 13:42, hb0815 wrote:

But I admit, I prefer git, anyway.)

Plenty of us old Gits here anyway ;)

VSI support Git.

https://products.vmssoftware.com/git

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/3/2026 8:42 AM, hb0815 wrote:

On 3/2/26 6:23 PM, Arne Vajh|+j wrote:

I grabbed standard SVNKit:
...
$ jsvn == "''java' -cp /disk2/arne/jsvn/lib/* org.tmatesoft.svn.cli.SVN"
...
(I have some problems with files created on Windows with CRLF end up on
VMS with trailing CR's, but I am pretty sure that would be the same
problem on Linux, so not a VMS problem)

Do the Windows files end up on VMS as stmlf?

Yes.

Then there are "trailing"
CRs. As you probably know, you can change the rfm to stm. Then on VMS
you should not see the CRs.

I am sure:

$ SET FILE/ATTR=RFM:STM ...

will fix the problem.

There are also plenty of "strip trailing CR's" tools around. And
I could write one myself if necessary.

But I don't think these are the right solution.

I think that the right solution would be one of:
* configure the SVN server to handle it
* change all the files in the repo to be only LF

I don't know, whether the VMS JVM can handle VMS stm files or not.

It should be able to read them.

But I fear that committing them back will be seen as all lines changed.

You
may want to give some more details on how these files end up on VMS.

$ jsvn co url path

Whether svn on Linux or jSVN on the Linux JVM can do this, I don't know. (Unfortunately what you showed on how to use jSVN on the VMS JVM was not enough for me to run and try jSVN on the Linux JVM.

java -cp /disk2/arne/jsvn/lib/* org.tmatesoft.svn.cli.SVN ...

should work.

My symbol is just a convenience with a workaround to make it
work with the existing foreign command.

Arne


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/3/26 5:44 PM, Arne Vajh|+j wrote:

VSI support Git.

https://products.vmssoftware.com/git

I know. It's installed on x86ner, but I can't get it to clone from
codeberg or github ...
$ git clone https://codeberg.org/hb0815/hexdump.git
Cloning into 'hexdump'...
fatal: unable to access 'https://codeberg.org/hb0815/hexdump.git/':error setting certificate file: /curl$root/etc/ca-bundle.crt
$

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/3/26 5:56 PM, Arne Vajh|+j wrote:

$ SET FILE/ATTR=RFM:STM ...

will fix the problem.

There are also plenty of "strip trailing CR's" tools around. And
I could write one myself if necessary.

SET FILE/ATTR=RFM:STM does not strip trailing CRs. But it seems you want
to strip the CRs on a non-VMS system, because $ CONVERT/FDL can do it.

Whether svn on Linux or jSVN on the Linux JVM can do this, I don't
know. (Unfortunately what you showed on how to use jSVN on the VMS JVM
was not enough for me to run and try jSVN on the Linux JVM.

java -cp /disk2/arne/jsvn/lib/* org.tmatesoft.svn.cli.SVN ...

should work.

My symbol is just a convenience with a workaround to make it
work with the existing foreign command.

Maybe I didn't make it clear:
$ curl -L https://www.svnkit.com/com.tmatesoft.svn_1.10.13.standalone.nojna.zip -o
x.zip
...
$
$ unzip x.zip
Archive: x.zip
creating: svnkit-1.10.13/
creating: svnkit-1.10.13/conf/
creating: svnkit-1.10.13/lib/
...
$
$ java --version
openjdk 21.0.10 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Debian-1deb13u1, mixed mode, sharing)
$
$ java -cp svnkit-1.10.13/lib/* org.tmatesoft.svn.cli.SVN
Error: Could not find or load main class svnkit-1.10.13.lib.jcl-over-slf4j-1.7.32.jar
Caused by: java.lang.ClassNotFoundException: svnkit-1.10.13.lib.jcl-over-slf4j-1.7.32.jar

$ java -cp svnkit-1.10.13/lib/ org.tmatesoft.svn.cli.SVN
Error: Could not find or load main class org.tmatesoft.svn.cli.SVN
Caused by: java.lang.ClassNotFoundException: org.tmatesoft.svn.cli.SVN
$
$ java -cp svnkit-1.10.13/lib/ -jar
svnkit-1.10.13/lib/svnkit-cli-1.10.13.jar org.tmatesoft.svn.cli.SVN
no main manifest attribute, in svnkit-1.10.13/lib/svnkit-cli-1.10.13.jar
$
$ jar xvf svnkit-1.10.13/lib/svnkit-cli-1.10.13.jar META-INF/MANIFEST.MF
inflated: META-INF/MANIFEST.MF
$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0

$

I gave up.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/3/2026 3:59 PM, hb0815 wrote:

On 3/3/26 5:44 PM, Arne Vajh|+j wrote:

VSI support Git.

https://products.vmssoftware.com/git

I know. It's installed on x86ner, but I-a can't get it to clone from codeberg or github ...
$ git clone https://codeberg.org/hb0815/hexdump.git
Cloning into 'hexdump'...
fatal: unable to access 'https://codeberg.org/hb0815/hexdump.git/':error setting certificate file: /curl$root/etc/ca-bundle.crt
$

:-(

My point was just that looking into SVN is semi-relevant despite
Git being totally dominant, because VSI is handling Git - or
at least should be handling Git.

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/3/2026 4:07 PM, hb0815 wrote:

On 3/3/26 5:56 PM, Arne Vajh|+j wrote:

Whether svn on Linux or jSVN on the Linux JVM can do this, I don't
know. (Unfortunately what you showed on how to use jSVN on the VMS
JVM was not enough for me to run and try jSVN on the Linux JVM.

java -cp /disk2/arne/jsvn/lib/* org.tmatesoft.svn.cli.SVN ...

should work.

My symbol is just a convenience with a workaround to make it
work with the existing foreign command.

Maybe I didn't make it clear:
$ curl -L https://www.svnkit.com/ com.tmatesoft.svn_1.10.13.standalone.nojna.zip -o x.zip
...
$
$ unzip x.zip
Archive:-a x.zip
-a-a creating: svnkit-1.10.13/
-a-a creating: svnkit-1.10.13/conf/
-a-a creating: svnkit-1.10.13/lib/
...
$
$ java --version
openjdk 21.0.10 2026-01-20
OpenJDK Runtime Environment (build 21.0.10+7-Debian-1deb13u1)
OpenJDK 64-Bit Server VM (build 21.0.10+7-Debian-1deb13u1, mixed mode, sharing)
$
$ java -cp svnkit-1.10.13/lib/* org.tmatesoft.svn.cli.SVN
Error: Could not find or load main class svnkit-1.10.13.lib.jcl-over- slf4j-1.7.32.jar
Caused by: java.lang.ClassNotFoundException: svnkit-1.10.13.lib.jcl- over-slf4j-1.7.32.jar

...

I gave up.

Sorry - I have been doing too much too much VMS and Windows.

I forgot about *nix shells and wildcards.

java -cp "svnkit-1.10.13/lib/*" org.tmatesoft.svn.cli.SVN ...

:-)

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10o7imk$2bbra$1@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 3/3/2026 3:59 PM, hb0815 wrote:

On 3/3/26 5:44 PM, Arne Vajh|+j wrote:

VSI support Git.

https://products.vmssoftware.com/git

I know. It's installed on x86ner, but I-a can't get it to clone from
codeberg or github ...
$ git clone https://codeberg.org/hb0815/hexdump.git
Cloning into 'hexdump'...
fatal: unable to access 'https://codeberg.org/hb0815/hexdump.git/':error
setting certificate file: /curl$root/etc/ca-bundle.crt
$

:-(

My point was just that looking into SVN is semi-relevant despite
Git being totally dominant, because VSI is handling Git - or
at least should be handling Git.

I used to work with one of the SVN developers. When he joined
our team, he apologized. :-D

But seriously, there's nothing inherently wrong with subversion.
It was a decent implementation, but the world passed it by while
it was still in incubation.

Torvalds famously hates it, but not all projects fit into the
`git` model of shipping the entire repository around. At the
time he presented at Google, for example, google3 contained
about a terabyte of source code: it would not be reasonable to
ship that to every engineer's workstation and keep it
synchronized. A monorepo just has different requirements than a
relatively small project like the Linux kernel. The Linux
people have a real tendency to overstate the size and scope of
their project.

- Dan C.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/4/2026 10:01 AM, Dan Cross wrote:

I used to work with one of the SVN developers. When he joined
our team, he apologized. :-D

But seriously, there's nothing inherently wrong with subversion.
It was a decent implementation, but the world passed it by while
it was still in incubation.

Torvalds famously hates it, but not all projects fit into the
`git` model of shipping the entire repository around. At the
time he presented at Google, for example, google3 contained
about a terabyte of source code: it would not be reasonable to
ship that to every engineer's workstation and keep it
synchronized. A monorepo just has different requirements than a
relatively small project like the Linux kernel. The Linux
people have a real tendency to overstate the size and scope of
their project.

I have no practical Git experience.

But aren't people supposed to use partial clone
and sparse checkout to deal with the size problem
of monorepos?

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/4/2026 10:01 AM, Dan Cross wrote:

I used to work with one of the SVN developers. When he joined
our team, he apologized. :-D

But seriously, there's nothing inherently wrong with subversion.
It was a decent implementation, but the world passed it by while
it was still in incubation.

Torvalds famously hates it, but not all projects fit into the
`git` model of shipping the entire repository around. At the
time he presented at Google, for example, google3 contained
about a terabyte of source code: it would not be reasonable to
ship that to every engineer's workstation and keep it
synchronized. A monorepo just has different requirements than a
relatively small project like the Linux kernel. The Linux
people have a real tendency to overstate the size and scope of
their project.

Linux kernel has a need for a distributed version control
system, because it is a distributed project.

There are many companies that do custom work on Linux
kernel.

(different contexts for code: expected to go upstream,
offered and accepted upstream, offered but rejected
upstream, not offered initially but forced when accused
of GPL violation etc.)

Anything SVN style would not work well for Linux kernel.

For a closed source source project not depending on
open source, then SVN will work fine.

But projects not depending on open source is
going the way of the dinosaurs.

Arne


--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/3/26 10:14 PM, Arne Vajh|+j wrote:

Sorry - I have been doing too much too much VMS and Windows.

I forgot about *nix shells and wildcards.

java -cp "svnkit-1.10.13/lib/*" org.tmatesoft.svn.cli.SVN ...

I admit, I didn't know what the wildcard for -cp means. java --help
doesn't say anything about it. I thought it would be specific to VMS
because wildcards are not expanded on the DCL command line. Now jSVN
seems to work.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/4/2026 2:47 PM, hb0815 wrote:

On 3/3/26 10:14 PM, Arne Vajh|+j wrote:

Sorry - I have been doing too much too much VMS and Windows.

I forgot about *nix shells and wildcards.

java -cp "svnkit-1.10.13/lib/*" org.tmatesoft.svn.cli.SVN ...

I admit, I didn't know what the wildcard for -cp means. java --help
doesn't say anything about it. I thought it would be specific to VMS
because wildcards are not expanded on the DCL command line. Now jSVN
seems to work.

java -cp lib/a.jar lib/b.jar lib/c.jar ...

adds the 3 jar files to classpath.

java -cp lib/* ...

adds all jar files in lib to classpath.

The feature was added to Java 1.6 in 2006.

And to me it sort of seems logical.

But I guess it is a fair question where people that
are not senior members of the J cult would find out.

And I actually had to Google a bit to find it.

https://docs.oracle.com/en/java/javase/25/docs/specs/man/java.html#standard-options-for-java

<quote>
--class-path classpath, -classpath classpath, or -cp classpath

Specifies a list of directories, JAR files, and ZIP archives to
search for class files.

On Windows, semicolons (;) separate entities in this list; on other platforms it is a colon (:).

Specifying classpath overrides any setting of the CLASSPATH
environment variable. If the class path option isn't used and classpath
isn't set, then the user class path consists of the current directory (.).

As a special convenience, a class path element that contains a base
name of an asterisk (*) is considered equivalent to specifying a list of
all the files in the directory with the extension .jar or .JAR . A Java program can't tell the difference between the two invocations. For
example, if the directory mydir contains a.jar and b.JAR, then the class
path element mydir/* is expanded to A.jar:b.JAR, except that the order
of JAR files is unspecified. All .jar files in the specified directory,
even hidden ones, are included in the list. A class path entry
consisting of an asterisk (*) expands to a list of all the jar files in
the current directory. The CLASSPATH environment variable, where
defined, is similarly expanded. Any class path wildcard expansion that
occurs before the Java VM is started. Java programs never see wildcards
that aren't expanded except by querying the environment, such as by
calling System.getenv("CLASSPATH").
</quote>

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/4/2026 2:59 PM, Arne Vajh|+j wrote:

On 3/4/2026 2:47 PM, hb0815 wrote:

On 3/3/26 10:14 PM, Arne Vajh|+j wrote:

Sorry - I have been doing too much too much VMS and Windows.

I forgot about *nix shells and wildcards.

java -cp "svnkit-1.10.13/lib/*" org.tmatesoft.svn.cli.SVN ...

I admit, I didn't know what the wildcard for -cp means. java --help
doesn't say anything about it. I thought it would be specific to VMS
because wildcards are not expanded on the DCL command line. Now jSVN
seems to work.

java -cp lib/a.jar lib/b.jar lib/c.jar ...

adds the 3 jar files to classpath.

java -cp lib/* ...

adds all jar files in lib to classpath.

The feature was added to Java 1.6 in 2006.

And to me it sort of seems logical.

Note that the wildcard features is broken somehow
in VMS x86-64 Java 17 beta version.

I assume it will be fixed in final.

Because it is a PITA having to specify each jar file
individually.

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Wed, 4 Mar 2026 10:46:27 -0500, Arne Vajh|+j wrote:

For a closed source source project not depending on open source,
then SVN will work fine.

I think the SVN creators considered SVN to be rCLCVS done rightrCY,
because CVS couldnrCOt do atomic multifile commits, while SVN does.

I also think TorvaldsrCO objection to the whole concept of SVN is the
way it handles branches. The SVN folks liked to bandy around the
phrase rCLcheap copiesrCY, which meant that creating branches doesnrCOt
consume a lot of extra space making copies of files that havenrCOt
changed.

However, when it comes time to try merging across different branches,
SVN becomes a nightmare. ThatrCOs one thing Git does better than any
other VCS -- reducing merging to a mostly routine, daily operation,
rather than something that requires a lot of careful organization to
get right.

As for closed-source projects, I canrCOt see why they would have less
need for branching and merging than open-source projects.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/4/2026 4:09 PM, Lawrence DrCOOliveiro wrote:

On Wed, 4 Mar 2026 10:46:27 -0500, Arne Vajh|+j wrote:

# Linux kernel has a need for a distributed version control
# system, because it is a distributed project.
#
# There are many companies that do custom work on Linux
# kernel.
...
# Anything SVN style would not work well for Linux kernel.

For a closed source source project not depending on open source,
then SVN will work fine.

I think the SVN creators considered SVN to be rCLCVS done rightrCY,
because CVS couldnrCOt do atomic multifile commits, while SVN does.

Yes.

I also think TorvaldsrCO objection to the whole concept of SVN is the
way it handles branches. The SVN folks liked to bandy around the
phrase rCLcheap copiesrCY, which meant that creating branches doesnrCOt consume a lot of extra space making copies of files that havenrCOt
changed.

However, when it comes time to try merging across different branches,
SVN becomes a nightmare. ThatrCOs one thing Git does better than any
other VCS -- reducing merging to a mostly routine, daily operation,
rather than something that requires a lot of careful organization to
get right.

Not sure.

As indicated above then I see the the Linux kernel choice being
more about the distributed aspect.

Before Git they used another distributed source control system
BitKeeper.

And that was deliberately chosen for the distributed aspect.

https://lkml.org/lkml/1998/9/30/122

As for closed-source projects, I canrCOt see why they would have less
need for branching and merging than open-source projects.

Probably because there are no such logic. And nobody claimed there
to be such logic.

I wrote that Linux kernel need distributed and that closed
source would not have the same need.

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Wed, 4 Mar 2026 16:40:16 -0500, Arne Vajh|+j wrote:

On 3/4/2026 4:09 PM, Lawrence DrCOOliveiro wrote:

As for closed-source projects, I canrCOt see why they would have less
need for branching and merging than open-source projects.

Probably because there are no such logic. And nobody claimed there
to be such logic.

You previously said rCLFor a closed source source project not depending
on open source, then SVN will work finerCY, did you not? Given SVNrCOs limitations on branches, how could you say rCLnobody claimedrCY that closed-source projects wouldnrCOt need them?

I wrote that Linux kernel need distributed and that closed source
would not have the same need.

The term yourCOre looking for is rCLdecentralizedrCY, not rCLdistributedrCY.

Centralized source-code management is a pain even for closed-source
projects. ThatrCOs why Git has become so popular; and it happened in
spite of official company management policies to use only the
centralized system.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10o9jdr$2v1fr$2@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 3/4/2026 10:01 AM, Dan Cross wrote:

I used to work with one of the SVN developers. When he joined
our team, he apologized. :-D

But seriously, there's nothing inherently wrong with subversion.
It was a decent implementation, but the world passed it by while
it was still in incubation.

Torvalds famously hates it, but not all projects fit into the
`git` model of shipping the entire repository around. At the
time he presented at Google, for example, google3 contained
about a terabyte of source code: it would not be reasonable to
ship that to every engineer's workstation and keep it
synchronized. A monorepo just has different requirements than a
relatively small project like the Linux kernel. The Linux
people have a real tendency to overstate the size and scope of
their project.

I have no practical Git experience.

But aren't people supposed to use partial clone
and sparse checkout to deal with the size problem
of monorepos?

That all came _much_ later; he presented Git at Google in the
very early days. Indeed, much of that work was done at the
hyperscalars because their engineers wanted to use git to manage
their monorepos.

The effort was only marginally successful. Most never migrated
succesfully; Google did its own internal Perforce replacement;
Meta did its own thing; MSFT has their own tools; I don't
actually know what Amazon uses, but I suspect they've got a
similar story. The early momentum building around Jujutsu is a
direct result of the hyperscalar experiences (jj is essentially
a rewritten and better open source version of Google's `fig`,
which sits on top of CitC, SrcFS, and interacts with the
builder clusters and ObjFS).

- Dan C.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

In article <10o9k4j$2v1fr$3@dont-email.me>,
Arne Vajh|+j <arne@vajhoej.dk> wrote:

On 3/4/2026 10:01 AM, Dan Cross wrote:

I used to work with one of the SVN developers. When he joined
our team, he apologized. :-D

But seriously, there's nothing inherently wrong with subversion.
It was a decent implementation, but the world passed it by while
it was still in incubation.

Torvalds famously hates it, but not all projects fit into the
`git` model of shipping the entire repository around. At the
time he presented at Google, for example, google3 contained
about a terabyte of source code: it would not be reasonable to
ship that to every engineer's workstation and keep it
synchronized. A monorepo just has different requirements than a
relatively small project like the Linux kernel. The Linux
people have a real tendency to overstate the size and scope of
their project.

Linux kernel has a need for a distributed version control
system, because it is a distributed project.

There are many companies that do custom work on Linux
kernel.

`git` has become the de facto revision control system for, I
would wager, most working engineers. It solves a lot of gnarly
problems, is well maintained and supported by tooling, and is
not unreasonably pleasant to work with. There are some young
turks on the scene gunning for it; Jujutsu is the one most of my
colleagues are excited about (and it _is_ cool). One colleague
in particular, who used to work on revision control systems at
Meta, thinks it is a game changer. But in many ways it augments
`git` or whatever backend is used by a monorepo rather than
outright replacing it. That's not necessarily a bad thing: it
suggests that these two ideas (the versioned store and how one
interacts with it) can and perhaps should be decoupled.

(different contexts for code: expected to go upstream,
offered and accepted upstream, offered but rejected
upstream, not offered initially but forced when accused
of GPL violation etc.)

Anything SVN style would not work well for Linux kernel.

They used to not do any revision control at all. Larry McVoy
got Torvalds to start using BitKeeper, which evolved from the
architectural principles of the internal revision control tools
he had built at Sun. It was based on a distributed model with
branching because that fit Sun's usecases well, despite being
closed-source, proprietary code.

For a closed source source project not depending on
open source, then SVN will work fine.

It turns out that, even in the world of mono-repos, there is a
need for something distributed; when you've got thousands of
engineers geographically spread 6 continents, the traditional
centralized repo living on one machine doesn't scale. Perforce
had a multi-master replication mode, but it was wildly
inefficient; at one point Google realized that 90% of uplink
bandwidth to some of the smaller offices was being consumed by
synchronizing source code, the vast majority of which was never
read by anyone in that office. The result was SrcFS, which was
a caching filesystem layer that understood the version control
system: you could `cd` to a particular revision and see the
state of the monorepo at that commit. Bits of code were lazily
read in as required. Google already had a reliable, versioned,
storage layer built internally; the backend for the revision
control system was rebuilt on that, allowing us to move off of
Perforce.

Personally, I thought that an internal-github model would have
worked better: projects create their own "repo" on the internal
repo thing; the build tool would be aware of those and allow one
to say, "I depend on version X of this other package." Packages
could then be independently versioned and released by their
maintainers.

This would have solved a lot of problems with the monorepo:
build breakage at tip was a serious problem for a long time,
because transitive dependency chains could be extremely long
and pull in very surprising packages: a minor change on one side
of the repo could break something important on the other, and it
was difficult to figure out where that coupling occurred in
advance without doing a "mondo build" of the entire monorepo.
This eventually grew a kind of de facto solution that kinda
sorta looked like versioning, but it was never a great fit. The
"distinct repo per internal project" thing would have made
versioning relationships explicit, and decomposed what was
essentially compile-time discovery of a versioning problem to a
a much, much cheaper graph query problem.

But projects not depending on open source is
going the way of the dinosaurs.

The distinction shouldn't be open source or not, but rather
style of inter-developer interaction and project need.

- Dan C.

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/4/2026 5:33 PM, Lawrence DrCOOliveiro wrote:

On Wed, 4 Mar 2026 16:40:16 -0500, Arne Vajh|+j wrote:

On 3/4/2026 4:09 PM, Lawrence DrCOOliveiro wrote:

As for closed-source projects, I canrCOt see why they would have less
need for branching and merging than open-source projects.

Probably because there are no such logic. And nobody claimed there
to be such logic.

You previously said rCLFor a closed source source project not depending
on open source, then SVN will work finerCY, did you not? Given SVNrCOs limitations on branches, how could you say rCLnobody claimedrCY that closed-source projects wouldnrCOt need them?

Because nobody did.

My argument about open vs closed source was explicitly
based on the distributed vs non-distributed capability.
I had not mentioned branch/merge capabilities at all.
That was an aspect you brought up.

I wrote that Linux kernel need distributed and that closed source
would not have the same need.

The term yourCOre looking for is rCLdecentralizedrCY, not rCLdistributedrCY.

The technical term for source control is distributed.

https://git-scm.com/

<quote>
Git is a free and open source distributed version control system ...
</quote>

https://en.wikipedia.org/wiki/Distributed_version_control

You can say that distributed/non-distributed is the
capability of the (D)VCS while centralized/decentralized
is the project organization, where:
* distributed supports both centralized and decentralized
* non-distributed only supports centralized

Arne

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Sun, 8 Mar 2026 13:45:54 -0400, Arne Vajh|+j wrote:

My argument about open vs closed source was explicitly based on the distributed vs non-distributed capability. I had not mentioned
branch/merge capabilities at all. That was an aspect you brought up.

IrCOll be charitable and assume you didnrCOt know about it. Now that it
has been brought to your attention, are you still sticking to your
claim that rCLFor a closed source source project not depending on open
source, then SVN will work finerCY?

Because, now that you know, if you still insist that rCLSVN will work
finerCY, that must mean that you donrCOt consider the branching/merging capability to be important. QED.
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On 3/4/26 10:01, Dan Cross wrote:

But seriously, there's nothing inherently wrong with subversion.
It was a decent implementation, but the world passed it by while
it was still in incubation.

I don't know that that's fair; I know several devs who use it in
their organizations, mine included. Many don't care about what "the
world" is using for their internal tools, as well they shouldn't.

By the same token, I like Wiha screwdrivers, and I really don't care
what screwdrivers the guy down the street uses.

Torvalds famously hates it, but not all projects fit into the
`git` model of shipping the entire repository around.

Feh...git's entire featureset reads as a list of solutions in search
of problems. Even in the beginning it left me wondering WTF these kids
were smoking. But of course a lot of fanboys are going to hate on SVN
just because Their God Linus hates on SVN. (and I say this as a devout
Linux guy!)

-Dave
--
Dave McGuire, President/Curator
Large Scale Systems Museum
New Kensington, PA
--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 20 Mar 2026 17:15:07 -0400, Dave McGuire wrote:

...git's entire featureset reads as a list of solutions in search of problems.

Friction-free branching and merging would seem to be a sine qua non of collaborative software development. How does your organization work?
--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: comp.os.vms



On 3/20/26 15:36, Lawrence DrCOOliveiro wrote:

On Fri, 20 Mar 2026 17:15:07 -0400, Dave McGuire wrote:

...git's entire featureset reads as a list of solutions in search of
problems.

Friction-free branching and merging would seem to be a sine qua non of collaborative software development. How does your organization work?

Here is a very technical visualization of a git merge.

https://www.digitalsynergyinc.com/GitMerge.gif
--- Synchronet 3.21e-Linux NewsLink 1.2

From Newsgroup: comp.os.vms

On Fri, 20 Mar 2026 17:50:23 -0700, jeffrey_dsi wrote:

On 3/20/26 15:36, Lawrence DrCOOliveiro wrote:

On Fri, 20 Mar 2026 17:15:07 -0400, Dave McGuire wrote:

...git's entire featureset reads as a list of solutions in search
of problems.

Friction-free branching and merging would seem to be a sine qua non
of collaborative software development. How does your organization
work?

Here is a very technical visualization of a git merge.

Fun fact: thatrCOs what Linus Torvalds does all day. No other VCS makes
it that easy.

Here is a talk he gave at Google nearly a decade ago, on why they
should switch to Git <https://www.youtube.com/watch?v=4XpnKHJAok8>,
and on why rCLSVN is CVS done rightrCY is such a stupid thing to day.

You may have heard of Google: theyrCOre rumoured to be full of smart
folks, who are not just smart because they come up with ideas of their
own, but because they are also capable of learning about smart ideas
from others.

How smart is your organization?
--- Synchronet 3.21e-Linux NewsLink 1.2