Item — HN Reader

After seeing luckydude answer questions on the little thread the other evening, I'm wondering what other things the SCCS/BK folk think we should be doing better. What have we forgotten?

luckydude mentioned real per-file history for example¹, and that pushed me to remember per-file comments as the thing I'd want back.

Perhaps someone is listening.

¹ https://news.ycombinator.com/item?id=26207037

2 comments

Branch operations should be first-class transactions in a revision control system. In Git, if you rename branch "foo" to "bar" there's even less record-keeping in place than changes to files. Instead, there should be a first class transaction in the repo history that represents this change.

A reasonable direction to go, and I'll give sort of a non-response. For me, it's to take some time to absorb and celebrate this paper. If I go too quickly to doing better, I tend to miss the amazing. It also makes it easier for me to talk about other's contributions (like luckydude's many) to the state of the art, as then get into what could be better.

An example:

The 4th paragraph from the end of section II talks about optional deltas. It's like ifdefs in a version control system: many version can be checkout with or without some of the deltas. While not part of many version control systems, it's an interesting idea explored in Andreas Zeller's Feature Logic PhD work 20 years later [1].

[1 - currently, SSL cert expired this morning; notified] https://www.st.cs.uni-saarland.de/publications/files/zeller-...

Zeller's design seems to be addressed at least in part by darcs/pijul using the methods described in David Roundy's Theory of Patches¹. A virtual filesystem seems like an especially nice way to solve the interface issues that would arise too.

It strikes me that I treat the result of git-rerere as a ridiculously weak version of this. I'll occasionally carry an unwanted integration branch simply to handle changes that could be managed correctly if there was a better way to express relationships in my tools. Having the functionality baked in to the graph with the associated strictness, and available across clone boundaries would be great.

¹ https://www.cs.tufts.edu/~nr/cs257/archive/david-roundy/Theo...

> It strikes me that I treat the result of git-rerere as a ridiculously weak version of this

I'm the main author of Pijul, and rerere has been my main argument in every discussion about Pijul to explain how everybody is trying to simulate commutation instead of really achieving it.

This is the first time I hear it from somebody else. THANKS!

Also, Darcs' theory doesn't really work around conflicts. Also, until recently, applying a patch in Darcs could take a time exponential in the size of history. It seems to be quadratic in the last few versions (Pijul is in log of the size of history).

If you're familiar with the Zeller paper... Was I right in believing that the approach you're using in pijul allows the use of optional deltas as Zeller's paper describes? I was planning on digging around a little more next weekend, but if you happen to know.

It definitely appears to be a natural extension of the channels feature, but it isn't clear to me that you can express the actual relationship Zeller describes.

I'm not familiar with that thesis. Pijul uses deltas everywhere (but a special form of deltas, storing more information than the output of `diff`), plus tricks to make that fast.