> VSS

I just had trauma!

I will say that SourceSafe had one advantage: You could create "composite" proxy workspaces.

You could add one or two files from one workspace, and a few from another, etc. The resulting "avatar" workspace would act like they were all in the same workspace. It was cool.

However, absolutely everything else sucked.

I don't miss it.

▲

gcr a day ago | parent [-]

So it’s a workspace that includes changes from multiple branches at once, like `jj new revset-1 revset-2 revset-3 …` ?

(Git has octopus merges, jj just calls them “merge commits” even though they may have more than two parents)

▲

andrewaylett 19 hours ago | parent | next [-]

No, it let you continue to follow the main branch for most files, while files you edited would have their changes saved to a different location. And was just about as horrible as you might imagine.

We moved from VSS to SVN, and it took a little encouraging for the person who had set up our branching workflow using that VSS feature to be happy losing it if that freed us from VSS.

▲

ChrisMarshallNY a day ago | parent | prev [-]

Don't remember exactly. If I think about it, it could be quite complex.

Git has the concept of "atomic repos." Repos are a single unit, including all files, branches, tags, etc.

Older systems basically had a single repo, with "lenses" into sections of the repo (usually called "workspaces," or somesuch. VSS called them something else, but I can't remember).

I find the atomic repo thing awkward; especially wrt libraries. If I include a package, I get the whole kit & kaboodle; including test harnesses and whatnot. My libraries thend to have a lot more testing code than library code.

Also, I would love to create a "dependency repo," that aggregates the exported parts of the libraries that I'm including into my project, pinned at the required versions. I guess you could say package managers are that, but they are kind of a blunt instrument. Since I eat my own dog food, I'd like to be able to write changes into the dependency, and have them propagate back to their home repo, which I can sort of do now, if I make it a point to find the dependency checkout, make a change, then push that change, but it's awkward.

But that seems crazy complex (and dangerous), so I'm OK with the way things work now.

▲

gcr a day ago | parent | next [-]

Your workflow is fascinating! What languages do you work in, if you don’t mind me asking?

Both git and jj have sparse checkouts these days, it sounds like you’d be into that

Do you vendor the libraries you use? Python packages typically don’t include the testing or docs in wheels uploaded to PyPI, for instance

These days in Pythonland, it’s typical to use a package manager with a lockfile that enforces build reproducibility and SHA signatures for package attestation. If you haven’t worked with tools like uv, you might like their concepts (or you might be immediately put off by their idea of hermetically isolated environments idk)

	▲	ChrisMarshallNY a day ago \| parent [-]
		I work mostly in Swift (native Apple apps). Most of my libraries are Swift Package Manager modules. You can see most of my stuff in GH. You need to look at the organizations, as opposed to my personal repos: https://github.com/ChrisMarshallNY#browse-away Thanks for the heads-up. I'll give it a gander.

▲

baq a day ago | parent | prev | next [-]

a repo is a repo - you're describing what is nowadays known as a 'monorepo' and it's a perfectly reasonable and desirable even exactly for the reasons you mention, except the 'distributed' part makes it very inconvenient to handle on dev boxes if it grows a lot.

in a centralized VCS there are viable CICD options like 'check the compiler binaries in' or even 'check the whole builder OS image in' which git is simply not able to handle by design and needs extensions to work around deficiencies. git winning the mindshare battle made these a bit forgotten, but they were industry standard a couple decades ago.

▲

cindyllm a day ago | parent | prev [-]

[dead]