<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I've seen a lot of discussion in recent days about Jujutsu. It's a standalone DVCS, but the primary production backend uses Git, making it significantly more practical to use than the other options.<div><br></div><div><a href="https://github.com/martinvonz/jj">https://github.com/martinvonz/jj</a><br><div><br></div><div><a href="https://neugierig.org/software/blog/2024/12/jujutsu.html">https://neugierig.org/software/blog/2024/12/jujutsu.html</a><div><br></div><a href="https://ahal.ca/blog/2024/jujutsu-mercurial-haven/">https://ahal.ca/blog/2024/jujutsu-mercurial-haven/</a></div><div><br></div><div>David<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Dec 14, 2024, at 3:54 PM, Luther Johnson <luther.johnson@makerlisp.com> wrote:</div><br class="Apple-interchange-newline"><div>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
<div bgcolor="#FFFFFF" text="#000000"><p>"Is there a DVCS out there that's an alternative to Git?"</p><p>I'm sure the list will offer many options, but I think you might
want to look into mentioning either Fossil or Mercurial as
alternatives to Git. I have used Mercurial a tiny bit, and I have
used Fossil regularly over the last several years. Considering
commercial (not open source) software, I think Perforce is another
candidate, I have used it before, not lately, but at the time I
used it, I think it had a reasonably large customer base.</p>
<div class="moz-cite-prefix">On 12/14/2024 12:13 PM, Marc Rochkind
wrote:<br>
</div>
<blockquote cite="mid:CAOkr1zWG2Afg6-rbGQGBG7SvciHzbR+Wrt_dHHFkVX6k_7Mkpw@mail.gmail.com" type="cite">
<div dir="ltr">Thanks, Larry and Branden. I'll try to work what
you're saying into my paper.
<div><br>
</div>
<div>Larry, I found your post of a few days ago (<a moz-do-not-send="true" href="https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html">https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html</a>)
very illuminating, and I'd like to reference it, which I could
do with that post. But, is there some other, more
referenceable article saying the same thing that I can
reference instead?</div>
<div><br>
</div>
<div>Regarding BK vs. Git. Even if BK is superior, can today's
developers use BK? My understanding is that it is no longer
supported.</div>
<div><br>
</div>
<div>Is there a DVCS out there that's an alternative to Git?</div>
<div><br>
</div>
<div>The reason why this part of my paper has to be short is
that I'm discussing the influence of SCCS on software
engineering, and its influence on DVCSs is very indirect. My
paper isn't a history of VCSs.</div>
<div><br>
</div>
<div>Marc</div>
</div>
<br>
<div class="gmail_quote gmail_quote_container">
<div dir="ltr" class="gmail_attr">On Sat, Dec 14, 2024 at
11:53 AM Larry McVoy <<a moz-do-not-send="true" href="mailto:lm@mcvoy.com">lm@mcvoy.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson
wrote:<br>
> At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:<br>
> > As I mentioned in another post, I'm writing an
invited paper for an<br>
> > upcoming issue of IEEE Transactions on Software
Engineering that will<br>
> > be a 50-year retrospective of my original 1975 SCCS
paper (<br>
> > <a moz-do-not-send="true" href="http://mrochkind.com/aup/talks/SCCS-Slideshow.pdf" rel="noreferrer" target="_blank">mrochkind.com/aup/talks/SCCS-Slideshow.pdf</a>).
Can some people here<br>
> > review a couple of paragraphs for accuracy?<br>
> <br>
> I apologize for this not being quite responsive to your
query, then.<br>
> <br>
> 1. Tom Lord's Arch (ca. 2001) was at one timely
recognized for<br>
> popularizing, or perhaps _introducing_, the notion of
decentralized<br>
> version control to the dot-com era of hard-scrabble
FLOSS developers<br>
> who were building "Web 2.0" and whose startup
employers, be they<br>
> flush with cash or not, generally would not spring
for a commercial<br>
> VCS (which might not have been decentralized anyway).<br>
<br>
BitKeeper was 3 years into development by then. Here is the
first BK<br>
changeset:<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:ChangeSet@1.1">ChangeSet@1.1</a>, 1999-03-19 16:11:26-08:00, <a moz-do-not-send="true" href="mailto:lm@lm.bitmover.com" target="_blank">lm@lm.bitmover.com</a><br>
BitKeeper gets stored in BitKeeper.<br>
<br>
> The most salient point here is that Linus Torvalds
was not prescient<br>
> or uniquely perceptive in recognizing the value of a
DVCS. <br>
<br>
Couldn't agree more. He, Dave Miller, and Richard Henderson
came to my<br>
house in SF because Dave was threatening to fork Linux because
Linus<br>
used no SCM at all. That pushed all the merges to the next
level, to<br>
people like Dave. It took me 4-5 hours of explaining how
distributed<br>
SCM would work for Linus to get it. My wife was unimpressed
with him.<br>
Whatever, at the end of that day, he said "build that and I'll
use it".<br>
And we did, he did, and rate of development doubled (according
to the<br>
people who hated me) and was actually about 10x faster
(according to the<br>
people who could do math).<br>
<br>
> 2. "TeamWare and BitKeeper took advantage of the
interleaved delta<br>
> algorithm, also known as a weave, to implement an
efficient way to<br>
> represent merged deltas by reference, instead of
reproducing code<br>
> inside the repository. This is a lot more complicated
to do with<br>
> reverse deltas, introduced by RCS.*"<br>
> <br>
> I'd a like a second footnote directing me to where I
can understand<br>
> the mathematics supporting this claim. Just out of
nerd interest.<br>
<br>
See if this helps:<br>
<br>
<a moz-do-not-send="true" href="https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html" rel="noreferrer" target="_blank">https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html</a><br>
<br>
You can work out that SCCS/BK are doing what they claim by
running <br>
bk annotate on a file that was authored by X but automerged by
Y.<br>
The authorship stays the same across the merge, that's not
true in<br>
most SCM systems that copy the data from the branch to the
trunk.<br>
<br>
Happy to answer any questions. And, yes, git is a ginormous
step<br>
backwards. Only one graph, BK had a graph per file so the GCA
is<br>
always the correct one, none of this try different ones until
you<br>
get one that automerges; since there is only one graph, all
you <br>
get are commit comments, you lose the
oh-so-valuable-file-comments<br>
that you need when the crap hits the fan; you lose a boat load
of<br>
performance, especially in areas like annotate/blame when the
repo<br>
gets big, etc. Git sucks, it really does. Linus claims he
wrote<br>
it in a week and it shows.<br>
-- <br>
---<br>
Larry McVoy Retired to fishing <a moz-do-not-send="true" href="http://www.mcvoy.com/lm/boat" rel="noreferrer" target="_blank">http://www.mcvoy.com/lm/boat</a><br>
</blockquote>
</div>
<div><br clear="all">
</div>
<div><br>
</div>
<span class="gmail_signature_prefix">-- </span><br>
<div dir="ltr" class="gmail_signature">
<div dir="ltr">
<div><i>My new email address is <a moz-do-not-send="true" href="mailto:mrochkind@gmail.com" target="_blank">mrochkind@gmail.com</a></i></div>
</div>
</div>
</blockquote>
<br>
</div>
</div></blockquote></div><br></div></div></body></html>