Fossil deserves a chance compared to Git, even more in Rust times.
From CVS to Git, thirty years of source control
21–30 of 67 posts
Re: From CVS to Git, thirty years of source control
#22Earlier quoted context omitted.
Where does that leave the SCCS people?
Killed themselves after using it for fifteen minutes. I used to have to teach a commercial "Intro to Unix" course which had a section on SCCS - shudder!
I've never actually used SCCS was it that bad? I'd have thought that alcoholism would have been enough to numb the pain.
Re: From CVS to Git, thirty years of source control
#23I 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. :)
I loved the simple increasing numbers of Subversion. This was better then CVS "ad-hoc" versioning and also far better then git's hashes. Single numbers are easy for humans. I would love git would make it possible to work that way (there is one way: `git describe` can show something like "v1.0.4-14-g2414721" which means "14 commits ahead of tag v1.0.4".)
Some form of "increment authority" that simply appends to a list of hashes whenever it encounters a commit not yet on the list? Then you could use URI like $authorityhost/orderedcommits/$number as synonyms for the hashes. Multiple increment authorities would not necessarily have them in the exact same order (and "current latest" would likely differ by an order of magnitude or two after some time if you ever had multiple authorities), but it would still provide a lot of intuitive understanding.
I wonder how the tag mechanism would perform if you just burned it with this content. I suspect that it would not perform well...
Re: From CVS to Git, thirty years of source control
#24Where are my RCS people at?
The nostalgia hits hard.
I have a silly little wiki engine I made 20 years ago. It was an exercise in trying to better learn the traditional unix text processing tools. So the page templates were in m4, sed and awk did their traditional heavy lifting for request parsing and page generation. and page history was provided by rcs. Which fit better than cvs because it provides a history per file.
https://nl1.outband.net/fossil/gami/file?name=bin/save_node&...
The whole thing is really the mother of all injection vulnerabilities but I am still half tempted to try and spin it up once more and see what happens if i put it on the public web.
Re: From CVS to Git, thirty years of source control
#25Earlier quoted context omitted.
Killed themselves after using it for fifteen minutes. I used to have to teach a commercial "Intro to Unix" course which had a section on SCCS - shudder!
I've never actually used SCCS was it that bad? I'd have thought that alcoholism would have been enough to numb the pain.
> was it that bad?
I don't know - RCS just made more sense to me. And I really disliked RCS. You know some things are bad when something like CVS seems all warm and cuddly in comparison.
> I'd have thought that alcoholism would have been enough to numb the pain.
You may be right - it would certainly explain some aspects of my life since those days ;)
Re: From CVS to Git, thirty years of source control
#26I 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
Re: From CVS to Git, thirty years of source control
#27There 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…
Sounds like the “jj edit” command.
Its not
Re: From CVS to Git, thirty years of source control
#28There 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…
Microsoft Visual SourceSafe worked like this, but badly.
Re: From CVS to Git, thirty years of source control
#29Web 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.)
Re: From CVS to Git, thirty years of source control
#30Earlier quoted context omitted.
I loved the simple increasing numbers of Subversion. This was better then CVS "ad-hoc" versioning and also far better then git's hashes. Single numbers are easy for humans. I would love git would make it possible to work that way (there is one way: `git describe` can show something like "v1.0.4-14-g2414721" which means "14 commits ahead of tag v1.0.4".)
Some form of "increment authority" that simply appends to a list of hashes whenever it encounters a commit not yet on the list? Then you could use URI like $authorityhost/orderedcommits/$number as synonyms for the hashes. Multiple increment authorities would not necessarily have them in the exact same order (and "current latest" would likely differ by an order of magnitude or two after some time if you ever had multi…
Mercurial has serial numbers which work like this ("revision numbers"), but you can only see your local repo's serial number. There's no concept of a public revision number authority.