I needed a break from serious work yesterday, so SRC now speaks SCCS as well as RCS. This wasn’t difficult, I had SRC carefully factored in anticipation from when I originally wrote it.
I can’t say I think this feature will be actually useful; SCCS is pretty primitive, and the SRC support has some annoying limitations as a result. But some hacks you do just because you can, and this is one of them.
For those of you who are perversely curious: the SCCS back end doesn’t support tags or branching. It would be theoretically possible to support branching, but the SCCS branch names, being native, wouldn’t have any recognizable relationship to SRC revisions.
Also, due to the sccs prs format being rather misdesigned, SRC only sees SCCS comments up to the first empty line in them. This matters for amend, log, and fast-export. This could be fixed with a bit more cleverness in the log-dump parser; perhaps in a future release.
If you don’t feel the giggle value of taking the most ancient, crufty version-control system EVER and wrapping it in a really slick modern UI, just because you can…well, you’re probably not a hacker. So sad for you; go have a life or something.
I’m actually a little sorry there aren’t any other single-file version-control systems as ancient as RCS and SCCS. Two back ends are probably all SRC will ever have.
Why not support a Subversion backend? I would hate to have to install CVS in order to use SRC. I mean, I haven’t used Subversion in ages either, but installing Subversion doesn’t give me the same sense of “something’s gone wrong” that installing CVS does.
Subversion is designed to work on file sets, and is the wrong backend for something designed to work on individual files.
What, no “file.old.old.old_13january.new.goodversion” backend?
r wrote: What, no “file.old.old.old_13january.new.goodversion” backend?
I hear Mel’s working on that one.
“Why in name of deep-fried cheesy *FNORD* did he do it?”
“He’s Eric. Sometimes, ‘just because’ is perfectly sufficient reason.”
When I first eyeballed the post’s headline, I had a damn good giggle.
I’ve got a script that I’ve been working on, and SRC seems like an excellent candidate to use for version control. The only trouble is, that renaming the file occasionally (currently up to “scriptname.5”) is easier than installing SRC (it’s not in my repository, and probably never will be unless I do an apt-get dist-upgrade) and RCS (which is, but is in universe).
Max: I think you’re confused. SRC doesn’t support CVS, nor has any dependency on it. SRC and CVS share a common dependency on RCS, but that’s it.
By the way, Eric, if you would be designing version control storage format for SRC (Simple Revision Control), namely single files, text only, human readable — how would you go about it? What would you keep from RCS, and what you would replace / change?
>By the way, Eric, if you would be designing version control storage format for SRC (Simple Revision Control), namely single files, text only, human readable — how would you go about it?
I’d strip down fast-import streams and use that. Whenever SRC came up it would rescan the file and build an index of seek offsets for versions, tags, etc.
Why? Well…disk space is cheap. Delta-centric storage representations may no longer make sense; I’d want to try it the simple way and collect statistics on repo growth over time before space-optimizing. A possibility is that *some* blobs (with a low percentage of changes) might become deltas.
Advantages: repositories are easy to pass around – they’re just flat files. All the other usual advantages of plain text formats would also apply.
If what you’d produced were a “slick” or “modern” ui then maybe you would have a case. But it isn’t and you don’t.
>If what you’d produced were a “slick” or “modern” ui then maybe you would have a case. But it isn’t and you don’t.
OK, what do you think a modern UI for a VCS would look like?
And, by the way, if your answer is “a GUI”, go away; you don’t understand the problem space well enough that your opinion matters.
> And, by the way, if your answer is “a GUI”, go away; you don’t understand the problem space well enough that your opinion matters.
True. I tried different Git GUIs (though you may say that they are not mature enough…), but in many cases I had to resort to command line hackery (in the original sense).
Though there are places where using GUI is at least a bit more efficient. I’m not talking about browsing history – you can have graphical representation of history, with colors, using ASCII-art on command line (git log –graph –oneline). I am talking about selective chunk manipulation (selecting which parts of changes you want to have in the commit).
> OK, what do you think a modern UI for a VCS would look like?
Putting GUIs aside, I’d like more “prepare a text buffer that the user can edit to select what to do” screens à la git rebase –interactive. Maybe for files to include in a commit (and bypass git add, and allow including new files that haven’t been git-added), and commits to cherry-pick. The former isn’t really applicable to a single-file system, of course.
>I’d like more “prepare a text buffer that the user can edit to select what to do” screens à la git rebase –interactive. Maybe for files to include in a commit (and bypass git add, and allow including new files that haven’t been git-added), and commits to cherry-pick.
You might like the MaGit mode in Emacs.
And apparently git-commit has an –interactive that I never looked for, but it does a sequence of prompts instead of the interface I had in mind. Nothing for cherry picking, though.
The thing stopping me from switching to emacs for general usage is the fact that ediff is terribly awkward (and not supported out of the box as a git difftool/mergetool, though I assume magit manages it somehow) compared to vimdiff. Anyone have any hints on how to make it work better? (also, speaking of things I’d like to improve… I really wish that mergetool had an option to auto-merge all non-conflict regions in all four buffers)
> The thing stopping me from switching to emacs for general usage is the fact that ediff is terribly awkward (and not supported out of the box as a git difftool/mergetool, though I assume magit manages it somehow) compared to vimdiff.
Hmmm… that’s strange that git-difftool and git-mergetool doesn’t have support for ediff (unless emerge means using ediff/emerge in Emacs). Do you (or Eric) volunteer to submit a patch?
Apparently emerge is supported, I just know when I searched on google for ediff (I hadn’t heard of emerge) all I found were shell scripts that were painful to use (though I don’t know how much of that was the scripts and how much was ediff itself, which I had no experience with, being painful to use).
I’m also perpetually annoyed, even with vimdiff, with the fact that there’s no way to do a three-way merge with all non-conflicts pre-merged in the versions and therefore only conflicts showing up as differences, rather than the four-way merge it gives you between the three raw versions and the conflict output.
And I see I already mentioned that issue in my previous comment; sorry for the repetition.