> Long live CDC Update!

Yes! It's one of those things I've carried over to bitty box distributed environments.

> You posted before Steve's response[0]. Does that help?

It does a little, yeah, but I'll admit that I still feel somewhat teased by it rather than properly informed. As I wrote, I'm close enough to the technical details of this problem that I'm able to use my imagination. I wouldn't be surprised if some of my own proposed designs mesh up with what Steve and co. are doing.

I just want some more concrete messaging "from the horse's mouth," as it were, about what's being undertaken to mitigate shortcomings in Git's architecture for folks in the enterprise space of technology and procurement stripes alike who might find it an interesting contrast to GitHub Enterprise.

▲

steveklabnik 2 days ago | parent [-]

Certainly meant to be more of a teaser. We’ll get there.

It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say. But there’s just a lot of stuff that’s already working in existing systems that just hasn’t been productized because those companies aren’t trying to get into the version control business.

If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines. We think that workflow is very valuable for people.

We certainly know that people will want to know more details before they buy, and have shared stuff with prospective customers during the POC process. We’ll be more generally open about it over time.

	▲	nrr 2 days ago \| parent [-]
		> It’s very possible some of your proposals are similar, I’m not familiar with them specifically so I can’t say. If I can ever get around to writing about it or polishing up what I have enough that I feel comfortable with someone else looking at it, I'll poke you directly about some of what I've been working on over on the Fossil side of things. > If you’re familiar with citc/commit cloud, for example, we’ll be doing something along those lines. Oh, hey, yeah. I'm not first-hand familiar with that tooling (I've never been at Google), but there's a similar(-ish) workflow I've been kind of missing from Plan 9, so I've been hammering on that a little. Something like `m1 client connect $remote_url --name $client_name` and `m1 workspace bind M: --client_name $client_name --name $workspace_name`, which is a slightly more obtuse take on running `9fs` to authenticate and bind the sources server into the current namespace. I've found that, at the time of a client connecting, there's a lot of value for me in having, like, the last however many commit manifests and seldom much else as far as file data goes. I can pull down the raw blocks containing that data on demand, and at least for now, commit manifests contain a complete enumeration of what's in the file tree at that commit. That's enough for me to rehydrate a browsable filesystem projection of the repository before I decide that I need to mirror blocks locally.