Live data from Hacker News

From CVS to Git, thirty years of source control

evilgeniuslabs.ca

41–50 of 67 posts

Re: From CVS to Git, thirty years of source control

#41
post #10

There were several proprietary systems in the late 1980s and early 1990s. The one I remember was DSEE from Apollo Computer. It was integrated with the file system such that commits and branches worked like zfs snapshots. You could just "cd" to whatever tag, branch, or individual commit you wanted. No checkouts required. Very cool, I wish we still had that today. DSEE was spun off as Clearcase, acquired by IBM, then I…

That would be very easy to do with FUSE. I would be amazed if it hasn't been done.

I doubt it's really that useful though - it would be difficult to make the filesystem mutable, which means anything that puts caches or build files in the tree (which is most things) wouldn't work.

I did a very quick search. First result: https://github.com/csutorasa/git-fuse

Re: From CVS to Git, thirty years of source control

#42
post #7

I sometimes wonder what would have happened if Atlassian had stuck with Mercurial support on Bitbucket - I don't think they can pretend that switching to git did very much for them. I love(d) Mercurial, and particularly TortoiseHg integration on Windows.

Fossil supports wiki, forum, issues but thing is, aren't coding agents tunned for git based workflows? many agents use git trees right? so it's unlikely that any git alternative will pickup from here?

I worry llm will increase inertia and make more difficult to adopt new technologies.

But who knows? Maybe it would lower the barrier instead. If switching to fossil is just one agent.md instruction away and it brings useful features with minimal effort, it might be an easier sell than without them.

After all, the new generation of programmers won't bother learning git anyway.

Re: From CVS to Git, thirty years of source control

#43
> What SVN didn't fix was the fundamental centralized model. You could not commit without a network connection. The repository was still a single server. "Working offline" meant "reading-only", you could browse history but not record any new work, and the day the server was down was the day the whole team waited.

FWIW this is how most projects work anyway. And IMO Subversion is still the best VCS when you have a lot of large binaries (the various extensions to Git like git-lfs are just hacks that graft a separate half-baked version control system to it and add further complexity to an already annoyingly complex system). I remember working at a gamedev company in early 2010s and out of curiosity i tried to put everything in the 250GB perforce workspace in a git repository only for git to choke and die before it managed to do anything. In comparison, ~5-6 years earlier i worked briefly at a game porting studio where every single game they had ported (which i'm almost certain went all the way back to the 90s), including all data and source (and these were AAA games, not tiny indie games), were into a single Subversion server.

Unfortunately Subversion lost the VCS fashion wars and nowadays it barely seems to have any development. I still use it for a few projects where i do have a lot of binary stuff, but most new things are in Git. I also have a bunch of stuff in Fossil (which also did handle binary files better than Git when i tested it years ago, though not as good as Subversion or P4) but nowadays i convert them to Git when i need to share because, well, pretty much everyone expects Git (and projects such as Codeberg and Forgejo make sharing and self-hosting easier).

Ironically the "fundamental issue" mentioned above was solved not too long ago with Subversion as nowadays you can have multiple "changelists" and each changelist is a full (hidden) SVN repository by itself, allowing you to do commits (as "shelving") and such locally and then push to remote when you're done. AFAIK changelists can also coexist (unlike Git where you can only work at one branch at each time). Unfortunately since Subversion is basically barely held together, only the command-line UI provides that functionality (at least in FLOSS clients) and even TortoiseSvn didn't seem to support it last time i checked.

Re: From CVS to Git, thirty years of source control

#45

> What SVN didn't fix was the fundamental centralized model. You could not commit without a network connection. The repository was still a single server. "Working offline" meant "reading-only", you could browse history but not record any new work, and the day the server was down was the day the whole team waited. FWIW this is how most projects work anyway . And IMO Subversion is still the best VCS when you have a lot…

You could always keep a local svn repository and commit to that, if you really wanted to commit without connectivity. But in practice most people don't, as evidenced by the success of github, which grinds many development processes to a halt every time it is down.

It also ignores svk, which is (was?) a popular add-on to svn, which provided a convenient way to do this and replay all the commits to the central svn repository when connectivity allowed.

Re: From CVS to Git, thirty years of source control

#47
post #29
post #3

Web design tip: don't have animations within a short distance of text, as human eyes evolved to follow the flashiest/fastest-moving thing around, which makes such text literally illegible to many of us. This particular site takes the cake in that regard by animating the whole page background.

True, but the site is called Evil Genius Labs for a reason. And it's not too hard to switch off, there's a clear prompt in the bottom right corner. (Didn't try mobile.)

> ... there's a clear prompt in the bottom right corner.

Indeed, it does.

> (Didn't try mobile.)

And my eyes didn't make it that far down the screen. If i can't read the first paragraph, there's no point in scanning further down the page (and certainly not to look for something as esoteric as an option to disable what should not be there in the first place). Grumble, grumble.

Re: From CVS to Git, thirty years of source control

#48

I use Subversion w/o a server too. You can have your repositories locally (file:///Path/to/repository). All my own (single man) projects are in local SVN repositories. For my use case git is just too much extra friction, and I still love to have my one single unique global revisions number that is linearly increasing with each commit. :)

Yes but the .svn dirs everywhere keep being annoying

Since Subversion 1.7 (2011), working copies only use a single .svn directory at the top level.

Re: From CVS to Git, thirty years of source control

#49

Most surprising thing from this article is that svn’s reign was only two years. I vividly remember using it for much longer than that, but at the same time, adopting git almost as soon as it arrived. It’s probably my memory playing tricks and svn was indeed a short term endeavor.

My experience was actually close to the one from the article. I used SVN for a year or two, moved to git and never looked back
Post reply on HN