I wrote a version-control system today. Yes, an entire VCS. Took me 14 hours.
Yeah, you’re looking at me like I’m crazy. “Why,” you ask, quite reasonably, “would you want to do a thing like that? We’re not short of powerful VCSes these days.
That is true. But I got to thinking, early this morning, about the fact that I haven’t been able to settle on just one VCS. I use git for most things, but there’s a use case git doesn’t cover. I have some document directories in which I have piles of things like HOWTOs which have separate histories from each other. Changes in them are not correlated, and I want to be able to move them around because I sometimes do that to reorganize them.
What have I been using for this? Why, RCS. The ancient Revision Control System, second oldest VCS in existence and clinging tenaciously to this particular niche. It does single-file change histories pretty well, but its UI is horrible. Worse than git’s, which is a pretty damning comparison.
Then I got to thinking. If I were going to design a VCS to do this particular single-file, single-user job, what would it look like? Hm. Sequential integer revision numbers, like Subversion and Mercurial used locally. Lockless operation. Modern CLI design. Built-in command help. Interchange with other VCSes via git import streams. This sounds like it could be nice…
Then, the idea that made it inevitable. “I bet.” I thought, “I could write this thing as a Python wrapper around RCS tools. Use them for delta storage but hide all the ugly parts.”
Thus, SRC. Simple Revision Control, v0.1.
This first version is a very rough cut. It does all the basic VCS things – commits, checkouts, diff listings, tags – but the implementation is fragile. The first other person to look at it has reported that it inexplicably fails when you set EDITOR=vi. (UPDATE: This is already fixed.)
Still…read the manual page to see where it’s going (I wrote the manual page before the code). Most of the UI is shamelessly swiped from Subversion – I simplified where it made sense.
Yes, I will implement branching and import/export. There will be Emacs VC support, too. The overall emphasis will be on keeping it simple and light, a handy small tool for the jobs where a real VCS would be overkill. And if it goes sproing – hey, the masters are RCS files, you have an easy recovery path.
SRC – RCS as if user interface mattered. SRC – maybe Rome wasn’t built in a day, but this tool was. SRC – when you care enough to use the very least. Thank you, I’ll be here all week.
And if you’re thinking “Hey, that’s cheating! You didn’t really write a VCS, you let RCS do the hard parts!”, why, doing that is downright traditional. CVS was implemented – badly – the same way. But we’ve learned a lot in the quarter-century since, and know what mistakes not to repeat.
A VCS I might be able to use for all the silly business documents that I use that is simple and not SharePoint?
/drool
Could I ask for an option like “src monitor [time in min]” to monitor mtime and autocommit? Would be nice to have for all the rollback saves I make between commented commits.
>Could I ask for an option like “src monitor [time in min]” to monitor mtime and autocommit? Would be nice to have for all the rollback saves I make between commented commits.
Hm. Maybe. Email me a more detailed feature request, please.
Zit (http://git.oblomov.eu/zit) was written for the same reason – as a single file content tracker (single file version control). The difference is that it was written as wrapper around Git and not RCS.
The balance is different – it probably doesn’t have [local] sequential integer revision numbers like RCS, Subversion, Mercurial and Bazaar. On the other hand branching, merging, tagging, checking out older revision just works… though single-file tagging and branching was not *that* terrible in RCS / VCS. Sticky state… bleh, I’d take anonymous branch (detached HEAD).
Bash, rather than Python.
Eric, it looks like you cannot create ‘delete’ branch or tag in SRC due to quirks in UI (subcommand rather than option)…
>Eric, it looks like you cannot create ‘delete’ branch or tag in SRC due to quirks in UI (subcommand rather than option)…
Hah! Thought of that. “–” is a magic token that says “options and subcommands are done”, it’s just not documented yet.
Perhaps I’m missing the point, but why not just keep each HOWTO in its own git repo?
@Tom because keeping them in on directory keeps things simpler.
>@Tom because keeping them in on directory keeps things simpler.
Indeed. Here’s another use case: All those little scripts in your ~/bin directory.
I’ll quote esr from IRC here, but it should be important to mention on the blog. When he was brainstorming the idea on creating SRC, he had the following criterea in mind:
Only deals with single files (use it for HOWTO documents, memoranda, etc)
Has a human-readable master-file representation – no binary blobs anywhere.
Modern interface – Subversion or hg-like commands.
Integer sequential revision numbers a la SVN.
Plain RCS fails at the latter two points. I had brought up Zit but noted that it doesn’t qualify either, it fails on the last three points entirely. Other implementations basing on Git usually fail at least points two and four.
There is a good niche for SRC. Alas, it will probably never be as common as any big VCSes, but it can easily serve as an excellent single-file version control. A key in SRC’s design is simplicity, forgoing all features unnecessary for multi-user multi-file development. RCS tried to denote revisions using version numbers; in practice, these almost never lined up with what actual releases were called, and just results in meaningless clutter. The Subversion method of an ever-incrementing integer actually makes sense in this use-case, SRC is not a distributed system. RCS supported tracking changes by multiple users, it was the direct precursor to CVS, after all, but SRC has no such need; no users are tracked nor known about (this isn’t technically true, yet, in implementation). SRC is the truly stupid content tracker.
The point about never being as common is actually more important than it might seem. SRC should not actively try to have an unusual commandset compared to the commonplace ones. The more a Subversion, Mercurial, or Git user can pickup and use SRC without relearning a new command set, the better.
I don’t understand why people are talking as if the single-file use case automatically means multi-user or distributed features are useless.
>I don’t understand why people are talking as if the single-file use case automatically means multi-user or distributed features are useless.
Doesn’t make them useless at all – but think about that ~/bin directory full of uncorrelated little scripts.
> you let RCS do the hard parts!”
Why, that’s a Unixish approach to things…
I’ve never had a project complex enough to warrant marrying into a revision control scheme, but something simpler and saner… I might actually use ESR’s RCS shell.
> Indeed. Here’s another use case: All those little scripts in your ~/bin directory.
At some point those are small enough that any non-live code worth keeping can simply be commented out rather than doing any formal history tracking.
@Emmanuel Rylke
>because keeping them in on directory keeps things simpler.
To each his own of course, but I must say I struggle to understand how building and maintaining an extra VCS is simpler than just introducing an extra level of directory hierarchy.
To me, version control is basically a solved problem. We have git. Throwing away years of engineering and refinement to go back in time decades just to avoid putting things in sub-directories makes little sense.
But, that’s me. I understand other people have different priorities :)
>Throwing away years of engineering and refinement
Er. Have you looked at the UI? You are describing exactly what I did not do.
>Doesn’t make them useless at all – but think about that ~/bin directory full of uncorrelated little scripts.
I have this exact use case (and a similar one with my dot files). I keep them each in one big (well, really not that big) git repo. It doesn’t matter to me that the files are uncorrelated. I don’t really understand why that is a problem.
@Tom:
> I have this exact use case (and a similar one with my dot files). I keep them each in one big (well, really not that big) git repo. It doesn’t matter to me that the files are uncorrelated. I don’t really understand why that is a problem.
I guess that the problem is that with uncorrelated file you want to go e.g. go back to older [working] version of a script or dotfile on per-file basis; you don’t want any other file to rewind to older version.
@Mike:
> Has a human-readable master-file representation – no binary blobs anywhere.
Though Git fails that in strict sense, the loose format does support it in less strict sense – objects are easily inspectable with the help of zlib unpacker (or ‘git cat-file’ helper). All the rest is plain text (refs, reflogs, etc.).
BTW, @esr, do you think that for SRC use case (single-file local SCM), does having history of the tip, i.e. reflog (in Git jargon) makes sense? What about bisect? Keywords expansion?
>BTW, @esr, do you think that for SRC use case (single-file local SCM), does having history of the tip, i.e. reflog (in Git jargon) makes sense?
I don’t know about or use this feature. Explain?
>What about bisect? Keywords expansion?
Bisect – possible. Though if you’re doing fault isolation that serious the project should probably just move to a real VCS.
Keywords – bletch, barf, puke. NO. All SRC files are set to -kb and there is no way to change that by design. That is one RCS ‘feature’ that should be shot and buried. Or better yet, buried at a crossroads with a stake through its heart.
@Jakub
>I guess that the problem is that with uncorrelated file you want to go e.g. go back to older [working] version of a script or dotfile on per-file basis; you don’t want any other file to rewind to older version.
Sorry if I’m missing something, but git lets you do this (if I understand you correctly). You can easily see the entire history of any single file, and checkout (without changing any of your other files) any earlier version of just that file.
>I don’t know about or use this feature. Explain?
The reflog is a history of the commits that your HEAD as been pointing to. It’s in effect a local undo history for your repo. Extremely useful.
>>Throwing away years of engineering and refinement
>Er. Have you looked at the UI? You are describing exactly what I did not do.
Not sure I follow. What I meant is that we have an advanced, extremely well-engineered VCS in git that has had years of bug fixing. It works. It’s reliable. It’s fast. It’s maintained by a great team. Before throwing all that away for a different system there would have to be a pretty compelling reason. I am just struggling to understand it.
>Before throwing all that away for a different system there would have to be a pretty compelling reason.
Sometimes you don’t want your file histories tied together. It’s that simple.
>Sometimes you don’t want your file histories tied together. It’s that simple.
Fair enough.
@Random832 –
> > Indeed. Here’s another use case: All those little scripts in your ~/bin directory.
> At some point those are small enough that any non-live code worth keeping can simply be
> commented out rather than doing any formal history tracking.
Yeah, but —
I just looked in my ~/bin. I’ve got files there that are (by their mod dates) 21 years old, and have been through (counts quickly to himself) at least 8 different versions of *nix (and I’m counting all Linux variants as one kind). I distinctly remember that I’ve had to modify some of them going from *nix1 to *nix2, and then exactly reverse those mods as I went from *nix3 to *nix4 (mostly SVR4ish <=> BSDish changes, for any other old farts in the audience who care).
You really do want to keep a formal history on your most-used tools. I would have killed for a decent lightweight revision control system back in the day. And I expect I’ll start using this one RSN….
Am I the only one who’s thinking this might be useful for /etc config file management?
>Am I the only one who’s thinking this might be useful for /etc config file management?
No. :-)
If you put a nice GUI wrapper on this I can see it being used by tech writers and marketing droids. Version control for things like white papers or brochures tends to be abysmal and leads to much fail as a result
>Doesn’t make them useless at all – but think about that ~/bin directory full of uncorrelated little scripts.
Actually this is exactly the use case that I am thinking of for a single-file full DVCS: one person publishes their “uncorrelated little script”, another person modifies it to their purposes but continues tracking future improvements that the original author publishes.
As yet another backend for etckeeper? :-)
This might be a good place for a question I was going to ask by email… Eric, are histories of HOWTOs available somewhere? Seeing the actual diffs of revisions would ease the work for translation maintainers a great deal.
>Eric, are histories of HOWTOs available somewhere?
Not that I know of.
>> I don’t know about or use this feature. Explain?
> The reflog is a history of the commits that your HEAD as been pointing to. It’s in effect a local undo history for your repo. Extremely useful.
More precisely, reflog stores local log of history of each ref (branch, HEAD, etc.) – what was previous position and what command was used.
Git uses it to
1. implement @{time} revision identifiers, e.g. master@{yesterday},
2. as kind of unlimited undo (in addition to ORIG_HEAD), to recover from ‘git reset’, or ‘git bisect’, or ‘git commit –amend’, etc. — here you usually use @{n} identifier, e.g. HEAD@{2}, where current branch was two commands ago; though it is that important only if you allow history rewriting,
3. to implement ‘git checkout -‘ (which is special form for more generic @{-n} branch identifier), which means switch to previous branch (like ‘cd -‘),
4. it is abused to implement more than one stash (‘git stash’ is used to shelve away local uncomitted changes, to e.g. switch to other branch, create a fix, and go back).
HTH
Odd…I would have thought the very first of those mistakes was the RCS delta format. At least teach it to use rdiff and zlib so that the history file doesn’t become many times larger than the current version, and add some hashes so we know when our bits rot. Fossil sports a human-readable rdiff format that could be adapted for this purpose. zlib support could be as simple as “automatically pipe the RCS file through gzip.”
I don’t know about anyone else’s ~/bin, but mine is full of uncorrelated little scripts with dependencies on each other. When I’m cherry-picking changes I want all the related changes at once. This is even more important for /etc.
git log –follow takes care of the renamed-files problem nicely (assuming your renames are distinct commits from your file content modifications).
>At least teach it to use rdiff and zlib so that the history file doesn’t become many times larger than the current version, and add some hashes so we know when our bits rot.
Too many people want me to overengineer this. If the history file bulks up that much, you’re no longer in the use case SRC was designed for. I think eyeball-friendliness of the underlying format is a higher priority; disk space is cheap. Also, what part of “small single-user project” was difficult to understand?
On the other hand, you have some point about verification hashes. I’m mulling over a hacky way to include those.
On a slight tangent off your original post, Eric: In general terms, what do you mean by “modern CLI design”? I get your point that the RCS interface is broken and yours is not, but how is RCS’s interface old and yours modern? If it helps clarify the question, how does SRC’s interface differ from what a Unix hacker with good design sense would have crafted in the 1980s?
>If it helps clarify the question, how does SRC’s interface differ from what a Unix hacker with good design sense would have crafted in the 1980s?
Er…we didn’t on the whole, have any UI design sense back in the ’80s. :-)
One big difference is fewer switches sticking out all over the place. The Subversion CLI, which was my model here, is pretty good that way.
Another is that SRC continues a UI pattern pioneered by CVS (though in a weak and compromised form) and really polished by Subversion – now standard for VCSes. That is, instead of a large collection of distinct tools with idiosyncratic invocation styles, just one binary (or at least one dispatcher thingy) which selects an operation via a subcommand word, rather than a dash-prefixed switch.
Compare RCS’s “co -l foo” with SRC’s “src co foo” and you’ll see what I mean. The idiom is “in the context of src, perform the co operation”. Similarly, git doesn’t try to grab the word “commit” out of the general namespace; instead it’s “git commit”. Such interfaces are significantly easier to remember, document, and use.
It is not completely irrelevant that reposurgeon takes this interface style one step further…
Finally, RCS’s UI wasn’t exactly “broken”. Spiky and overcomplicated, yes, but if we gigged VCSes for that offense Git would be a failure. It gets the job RCS was designed for done – it’s just better hidden behind something less rebarbative, like Emacs VC mode (which I wrote) and SRC (which I wrote…gee, is there a pattern here?)
You need to add “line-oriented plain text” to “small single-user project,” then.
Without that proviso, people might try to throw their Excel or Powerpoint files into the thing, and wonder why its storage cost is so astronomically high.
> ‘git log –follow’ takes care of the renamed-files problem nicely (assuming your renames are distinct commits from your file content modifications).
First, there is a question whether single-file version control needs to support file renames (Eric, does SRC support it?).
Second, ‘git log –follow’ is a bit of hack, and not always works (though situations where it stops working are not common, like e.g. merging in formerly separate project inside subdirectory).
>First, there is a question whether single-file version control needs to support file renames (Eric, does SRC support it?).
Not yet, but it would be pretty trivial.
> it inexplicably fails when you set EDITOR=vi.
Isn’t that a feature rather than a bug?
>Isn’t that a feature rather than a bug?
You know, I wasn’t gonna say that. But I’m glad you did.
I fixed the bug, Alas.
> On a slight tangent off your original post, Eric: In general terms, what do you mean by “modern CLI design”?
@Thomas, my guess is first, dispatch via single command (‘src command [options]’) rather than separate commands (‘ci’ for checkin, ‘co’ for checkout, ‘rcsdiff’, ‘rcs’ for administration, ‘rcsmerge’, ‘rlog’ and not ‘rcslog’ or ‘rcs log’, etc.). Second, modern names: ‘commit’, ‘checkout’ or ‘update’ rather than ‘checkin’ / ‘checkout’.
>Eric, are histories of HOWTOs available somewhere?
There is a git repository that claims to have been converted from The Linux Documentation Project’s CVS at https://github.com/tLDP/LDP .
Thanks for the explanation, Eric.
@Jay Maynard
>> Am I the only one who’s thinking this might be useful for /etc config file management?
No sir, you are not partying alone tonight.
@FrancisT
>> If you put a nice GUI wrapper on this I can see it being used by tech writers and marketing droids.
Which is why, dare I say it … {glances furtively around for ESR} … first post. /run away! /run away!
@Zygo
>> Without that proviso, people might try to throw their Excel or Powerpoint files into the thing, and wonder why its storage cost is so astronomically high.
At this moment, I am working on a customer deliverable containing every single MSOffice formation, pdf’s, etc. and have no less than 6 versions of each base file, every single one coming from someone different having different naming conventions for the versions. And all this in addition to the multiple file versions I personally save to track my own changes for roll-back/forward, re-merge, etc.
I am already “wasting” the space. I would kill for a simple tool to manage the versioning on an individual base file basis.
>Yeah, you’re looking at me like I’m crazy.
Nah. It’s only natural for a programmer to write new software just for the fun or the challenge, isn’t it? ;-)
Based on this, I thought your policy was to stay outside of the editor wars. ¬_¬ (Disclosure: I find Emacs more comfortable than vi, but am considering giving the latter a second chance by seriously learning it. Vim’s got some nice plugins [such as this one], and its leader-key thing might help me make it more comfortable.)
>I thought your policy was to stay outside of the editor wars
It is. Why else do you think I resisted the initial opportunity to snark, and just quietly fixed the bug?
General question for ESR – I would email it, but I don’t know if the email address I have for you is good.
A) Is it possible to get the comments RSS feed to return more than ten comments? Ideally I’d like to be able to see a few days’ worth, or at least see what articles have received new comments in the last few days (alternately a way to sort articles by what has most recently received comments would be useful).
B) Does the comments RSS feed include pingbacks?
>Is it possible to get the comments RSS feed to return more than ten comments?
I don’t know. I’ve never used it and have no idea what its configuration knobs are
Jessica Boxer on 2014-11-07 at 12:29:35 said:
> > it inexplicably fails when you set EDITOR=vi.
> Isn’t that a feature rather than a bug?
ESR says:
> You know, I wasn’t gonna say that. But I’m glad you did.
> I fixed the bug, Alas.
This tool will find a LOT more use amongst systems administrators and ops guys than programmers/developers.
I would *never* hire a Unix/Linux admin or ops guy that couldn’t do vi 3 sheets to the wind.
Emacs? A tool for people who don’t have to carry a pager.
I’ve often thought about trying to tie RCS into vim such that when vim was called on certain classes of files it would *automatically* check the file in such that you would have to work really, really hard to permanently screw up a configuration.
The thing stopping me is that it’s really only worth doing if you can get rapid, widespread coverage, otherwise you get sloppy. Learning to keep your finger off the trigger is a lot more valuable than having a safety.
What if they only use ed? (I went through a brief phase of using ed as my preferred text editor in high school. Being thus constrained taught me a few vi tricks, and knowing ed itself served me well when I started messing around with a PDP-11 simulator with v7 UNIX..)
Of the two major Unix editing titans, one is virtually guaranteed to be on any Unix-flavored production box, and is thus as William O’Blivion points out, required learning for sysadmins and ops guys.
The other was created by Richard Stallman.
Meanwhile, the ascendancy of the Mac as the dominant Unix workstation platform has taught hackers the harsh lesson that UI and UX are important — really fucking important. This insight has brought about the emergence of extensible programmers’ editors with humane interfaces such as TextMate and SublimeText, which have been shown to be such an improvement over the status quo that many hackers are willing to pay money and accept their proprietary license terms rather than deal with the free alternatives for daily use.
Since some people are asking about autocommit…
While I was at the university, I wrote papers in RTF format using a “word processor” that at the time was missing all support for Undo.
(Note: RTF may not be the optimal text format, but it’s widely used, works if you need to do digital submissions, and works if you have to edit it on Windows; also, it’s somewhat readable.)
My solution was to have a git repository for each class; pdf and such would be ignored, and rtf would be saved. I then configured incron (http://inotify.aiken.cz/?section=incron&page=about&lang=en) to watch the directory and run a script which would automatically add and commit any new or changed RTF file.
inotifyd might also work for this.
incron or inotifyd could readily be hooked up to any revision system, however.
> Since some people are asking about autocommit…
There is *Flashbake*, inspired by Cory Doctorow.
ESR> …it inexplicably fails when you set EDITOR=vi.
I am curious – what was the bug?
>I am curious – what was the bug?
I was indiscriminately quieting subcommands with /dev/null redirection. Oops…
How is this any different from SCCS? One of my coworkers at my last company used it to maintain config files and the like? If the UI is that bad, could a wrapper around it make more sense?
>If the UI is that bad, could a wrapper around it make more sense?
Yes. In fact teaching SRC to use SCCS as a back end world be pretty trivial.
>It is. Why else do you think I resisted the initial opportunity to snark, and just quietly fixed the bug?
Wise guy, eh?
Anyway, would you recommend SRC as a “gateway drug” for people new to version control?
And another thing: you may or may not be aware of this, but your site’s map is blank. Not that I need it, but it would be a nice thing to have.
(Sorry for the double post; I accidentally clicked the submit button too early. :$)
> Of the two major Unix editing titans, one is virtually guaranteed to be on any Unix-flavored production box,
Why isn’t running an editor locally using a file transfer protocol (likely sftp these days) to load/save files the preferred solution, over running (possibly not configured to be the optimal editing environment for the user) an editor installed on the server?
@Random832
>> Why isn’t running an editor locally using a file transfer protocol (likely sftp these days) to load/save files the preferred solution, over running (possibly not configured to be the optimal editing environment for the user) an editor installed on the server?
Big difference between using an editor to produce something versus using an editor to administer something.
When a server refuses to come up beyond init 1 and all you have is a terminal connection, your editor choice is no longer under your control. And if the problem is a library problem, your choices may be reduced even further.
I still insist that new sysadmins learn both vi and at least a little ed for those cases. They are not as rare as you might think.
No no no…. the joke is supposed to end with “The other was created by Bill Joy”!
I wouldn’t. SRC will be useful, but it fills a niche of being useful for single-file documents like HOWTOs, FAQs, and other assorted documents that aren’t necessarily attached to any larger projects. If you want to manage software, you’re still better off learning Git or Mercurial, but there is going to be a large overlap with SRC’s design and git/hg.
I think this is one reason (out of many) that Emacs is popular, but it’s not really the point. SRC is meant for much simpler cases :)
> No no no…. the joke is supposed to end with “The other was created by Bill Joy”!
But it wasn’t a joke. Can you name even one linux distribution or unix variant that doesn’t include, either as part of the base system or as a package that is installed by default and part of the “don’t remove unless you really know what you’re doing” set, some version/derivative/clone of vi?
Discounting, of course, those from before vi existed. You won’t find Emacs on those either.
How many can you name that place any version of emacs in this position? I’ve seen ae, nano, and ee all in that position (in the same kind of “default modeless editors for newbies” niche, often as the default EDITOR and aliased to some newbie command name like “edit”) more often than any version of emacs.
>I think this is one reason (out of many) that Emacs is popular, but it’s not really the point. SRC is meant for much simpler cases :)
I feel compelled to point out that Vim can do the same. The real on-topic question, though, is: does SRC have any feature that allows it to work with such a system?
*ahem*
SRC makes no special networking provisions, and networking is entirely out-of-scope. It will treat local storage, NFS mounts, CIFS mounts, sshfs, etc equally (at least as far as the underlying file system is reasonably behaved and allows just a tiny bit more flexibility than MS-DOS, primarily starting a directory name with a period).
“Why isn’t running an editor locally using a file transfer protocol (likely sftp these days) to load/save files the preferred solution, over running (possibly not configured to be the optimal editing environment for the user) an editor installed on the server?”
What do you do when you can’t transfer files to or from the server because the necessary daemon is misconfigured?
Sorry in advance about the noise. I tried to log in using my WordPress login, but got nowhere. Do you have a separate non-WP login process?
I have only just found, via Instapundit, an essay of yours on Gramscian Damage. From 2006. Nice. I was looking for a place to ask you about that and the fact that I have been reading, and reading of, certain of your essays for many years now, with nary a mention from the open source crowd of this aspect of your work.
>Do you have a separate non-WP login process?
Yes. But you don’t have to be logged in to post comments.
In addition to the aforementioned issues, at times you’re working/troubleshooting either locally (keyboard & monitor), over a serial connection (or a serial over lan connection of you’ve got things organized right) or over something like a HP ILO or Dell iDrac connection.
Had to do this quite a bit on Friday, between bringing up 7 servers that are a special case, and trying to get a build SOP for some new hardware (72x4TB disks on SAS controllers, 2x110G SSDs on a SATA controller. 512GiB of ram. We have dozens of them. Hey Eric, need any REALLY large repos converted?)
> >Eric, are histories of HOWTOs available somewhere?
>
> Not that I know of.
I hope you do track histories of those files yourself? Would you mind publishing them? I am specifically interested in Hacker’s HOWTO, don’t really care about the others.
>Would you mind publishing them? I am specifically interested in Hacker’s HOWTO, don’t really care about the others.
Hm. I guess I could make the RCS master available for upload. Yes, it’s in RCS. This is exactly the use case I designed SRC for.
> Yeah, you’re looking at me like I’m crazy.
…not before I’m done laughing at the first line of this blog post…
> Hm. I guess I could make the RCS master available for upload. Yes, it’s in RCS. This is exactly the use case I designed SRC for.
Would be great to have access to either of these.
> Hm. I guess I could make the RCS master available for upload. Yes, it’s in RCS. This is exactly the use case I designed SRC for.
You could arrange the masters in a neat little directory structure, then write some scripts to manage them as a group, then write another script to convert the group history into a git fast-import stream, then post that stream on github…
(ducking and running ;-)
Then again, that’s probably exactly the flow esr had in mind: fill in the gap that existed between “start simple and small” and “have a plan for scaling up.”
As one of those operators William O might be hiring, I can confirm I had damn well better be able to vi 3 sheets to the wind (or at least at oh-dark-hundred after an hour or two of sleep when the cellphone rings because my name is up next on the on-call rotation and a box is down hard and outages are Serious Business). Among other things, even if it’s My Box, I may or may not have authorization to install anything that didn’t come from the vendor on it.
And almost 4 years later this STILL isn’t in Ubuntu.
Damn it.