21 ms·
Simple Revision Control
- jordigh 12y agoSource at gitorious: https://gitorious.org/src-vcs/ https://gitorious.org/src-vcs/
- ten7 12y agoOh the irony of hosting it on something other than SRC. SMH
- fdej 12y agohttp://www.catb.org/~esr/src/FAQ.html#self-hosting http://www.catb.org/~esr/src/FAQ.html#self-hosting
- bshimmin 12y agoFrom that link: > Is SRC used to develop itself? No. That would be silly. From Git's Wikipedia page: > The development of Git began on 3 April 2005. The project was announced on 6 April, and became self-hosting as of 7 April.
- owenmarshall 12y agoYou're kinda missing the point: this project is designed around a single user maintaining a linear history for a single file. Using it for a project would be a weird impedance mismatch. That's not to say I find SRC compelling... in the slightest. Just that you'd never use SRC to track a project.
- bshimmin 12y agoYou're right, I was mostly just being snarky - but, that said, the source of SRC (sigh - what a terrible name, as others have said) is, in fact, just one Python file, so I suppose you could arguably use SRC for it. I don't find it at all compelling either.
- owenmarshall 12y agoHah. I just looked at the src (heh) - you're right, one file. I take back my argument. If esr wants to fetishize a time when Real Programmers took patches over nntp and applied them in rcs, then by god he should go all in and self host the thing!
- fetbaffe 12y agoESR is not the only contributor to SRC, check the log. So no, SRC would be the wrong tool.
- mateuszf 12y agoChosen name "src" is quite unfortunate, as it will be a src of confusion.
- rsanheim 12y agoAgreed, such a horrible name choice.
- aw3c2 12y agoMuch better link is http://www.catb.org/~esr/src/ http://www.catb.org/~esr/src/
- dang 12y agoOk, we changed to that from http://www.catb.org/~esr/src/README http://www.catb.org/~esr/src/README.
- SwellJoe 12y agoI am not entirely sure I understand why one wouldn't use git for this role. If you don't need a remote git repository, you don't need to use one, and git will be available everywhere. Certainly many production machines will tend to have it for deployment of applications across multiple machines. What are some use cases that don't work with git (which is probably already available on the system)? And why wouldn't git be an effective tool for that particular role? I'm certainly not as experienced as ESR (though, I'm coming up on 20 years of administering Linux and UNIX servers), and perhaps I'm missing some subtle nuance here. I'm not wanting to come off as "screw this, this is stupid". I'm just genuinely not understanding why I should learn a new tool (or re-learn an old tool that's be "reloaded") when git does all of this and more...and I already know it and have it installed broadly across my systems.
- hapless 12y agoYou are almost certainly more experienced than ESR. He held his last technology position in the early 1990s.
- mwfogleman 12y agoThen again, ESR has assumed a role in the free software community as a VCS expert, as evidenced by his reposurgeon project and uses.
- GFK_of_xmaspast 12y agoProviding an excellent example of what your schoolteacher said about "assuming".
- jordigh 12y agoAnd his recent months of work on migrating Emacs from bzr to git.
- deng 12y agoDuring which it became abundantly clear that he is surely no git expert (which does not diminish the work he did).
- kazinator 12y agoThere is already a very decent little single-user revision control system that is light-weight and well-suited for making changes to individual files. Namely: the Quilt patch management system. http://en.wikipedia.org/wiki/Quilt_%28software%29 http://en.wikipedia.org/wiki/Quilt_%28software%29 In quilt, your revision history is a "stack" of patches which is applied to the tree. You can push and pop up and down the stack, and revise the patches (for instance, to migrate them to a different version of the tree, or just to make them more perfect).
- viraptor 12y agoQuilt is good for managing patches - as in applying or removing them if you know they do apply. But from what I experienced, doing anything else with it is a world of pain. You actually need to say which file are you going to change before changing it! Handling git merges/rebases seems to be a walk in the park compared to fixing quilt patches that don't apply anymore. I wouldn't say it's useful for individual files either...
- muyuu 12y agoDepends on Bash which is not popular in many platforms, builds with autoconf. My granny is not going to use Quilt.
- debacle 12y agoESR, is, if nothing else, the champion of his own relevance. I've never really been fond of his work, though he seems like a nice enough guy. But he's just another OSS hacker. Bruce Perens has accomplished far more with far less controversy and self-fluffing.
- comice 12y ago"ESR, is, if nothing else, the champion of his own relevance" wonderful.
- GFK_of_xmaspast 12y ago"a nice enough guy" Nope: http://esr.ibiblio.org/?p=26 http://esr.ibiblio.org/?p=26
- jayvanguard 12y agoYeah, I unsubscribed from his blog "Armed and Dangerous." He thinks he thinks he is smarter and more knowledgable about general topics than he really is. It should be named "Just Enough Knowledge to be Dangerous." Logic only gets you so far when your base of knowledge is very limited in a subject.
- pothibo 12y agoThanks for the link. He actually compares homosexual with pedophiles. I want to have absolutely nothing to do with such a degenerate.
- tellitlikeitis 12y agoThis is great. He's pointing out the facts! Your comment appears to be a classic case of projection. How is pointing out the facts about homosexual behavior a characteristic of a degenerate? Au contraire, your protestations signify you as a likely degenerate.
- pothibo 12y agoFor those of you brave souls who downvote me. I'm wondering which part of my statement you disagree with. - You think homosexual are pedophiles? - It's not important what he thinks about homosexuals. You're going to support him by using his software. If he had held the same hate speech about women in 2014, everyone would be here talking how imbecile this guy is.
- snoopybbt 12y agoYeah, sure. I'm definitely going to use it. Sure. Trust me.
- mrb 12y agoHe claims he did not use Mercurial because (a) it stores the history in binary blobs, (b) it does not have sequential revision numbers, and (c) its CLI syntax is ugly, see [1]. Unfortunately he is wrong about (b) and (c). Mercurial assigns automatic sequential revision numbers (perfect for a single non-distributed repo) and its CLI syntax is so neat that this is the reason I do use it a lot to track changes to single files... Sounds like ESR should have spent a little more time studying Mercurial. I cannot understand his need for (a). Does he want the possibility to quickly and easily see, or edit the history? If it's only seeing it all, in one command, then a simple "hg log -e" does it. [1] http://www.catb.org/~esr/src/FAQ.html#another-vcs http://www.catb.org/~esr/src/FAQ.html#another-vcs Edit: @leoc I based my comment on "Other projects to mold Mercurial and Git [...] will fail criteria #3 and #5, and often #4 as well" with #4 referring to a "modern CLI syntax". But yeah it could be implied that this criticism does not (always) apply to Mercurial.
- leoc 12y agoFrom TFA: > 4. Modern CLI user-interface. Commands familiar to Subversion, Hg, Git users. Doesn't seem that he's down on Mercurial's syntax.
- xixixao 12y ago[Modern CLI user-interface.] [Commands familiar to Subversion, Hg, Git users.] Those two just make up an oxymoron for me.
- e12e 12y agoI'm nit particularly fond of git, I much prefer mercurial - but they are of course pretty much equivalent. Either way I have a hard time seeing which usecases aren't covered by the duo of RCS and mercurial (actually I'm very hard pressed to see why one would ever use RCS over mercurial, but no question RCS is simpler). At least something like fossil have some actually unique features....
- bryanlarsen 12y agoThat was ESR's conclusion as well. SRC is just a simple wrapper around RCS.
- awalton 12y agoI think in a strange way, this tool is actually not a terrible idea. Git is not a configuration management tool, no matter how hard people try to shoe-horn it into that role. A simpler Git designed for configuration management is indeed a good idea. Unfortunately, I think the implementation leaves a lot to be desired. For one, not including the committer is an important flaw. If you're only managing your own system's configuration, it makes sense, but surely ESR realizes that UNIX-based OSes are multiuser systems, often administrated by teams of people. Being able to track whodunnit is definitely an important part of the equation. (It'd be incredibly clever if it signed the log with the user's public key too, but that might be asking a lot.) Needing something like SRC to track changes to a simple README or HOWTO? My local bin dir? Ehh not so much. Especially if it's a software project? No, that definitely should live in the VCS with the code, so that those who touch the code will also touch the documentation. It says a lot about src that it doesn't even live in a src repository.
- muyuu 12y agoIt's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. I routinely use my own rdiff/rsync scripts but this is not something you find in every system and also not something most people would use. A barebones, simple, no-install, easy, not-necessarily-for-experienced-developers VCS is a good thing to have. BTW it's going at 1 release per day. Heh :-)
- npsimons 12y agoIt's actually a good idea. People often don't bother version-controlling simple stuff because it's a hassle. Here's the thing that's funny to me: git is easy. Everyone (especially mercurial users) goes on about how horrible the UI is, but when I think of git, I think of how similar it is to RCS: easy, quick, and simple. With both, I can diff things and check in changes very quickly. I have a bunch of single files in RCS which I'm moving over to git because it's a no brainer: all the speed and ease of use with a ton of advantages (such as dead simple replication) if I ever need them.
- 12y ago
- bhaak 12y agoI can see the need for a VCS that doesn't grab the whole directory but is file based. But this "SRC is built on top of RCS" doesn't sound like the best idea. RCS has been historically more errorprone than SCCS, probably because it doesn't use a checksum in its history file. So you never know if there has been a corruption or not. Even though he mentioned SCCS "SCCS died off due to its proprietary nature", he doesn't seem to be aware that the Solaris version of SCCS got open sourced: http://sccs.sourceforge.net/ http://sccs.sourceforge.net/
- towelguy 12y agoAparently you need the rcs and rcsdiff commands available to use it.
- peterwwillis 12y agoAt the very least I would have liked to see some kind of minimal global index of changes. With single-file vcs, you may have a large tree littered with .src files, and you have to walk to the whole tree just to find all your revision controlled files. By [also] storing them in a global index you could simply list all revision controlled files, then perform operations on them all or on parts of them, without having to 'find' each time. That could default to $HOME/.srcidx so you never have to initialize some root tree or track an environment variable.
- dzsekijo 12y agoI don't get how git (or any proper multi-file dvcs) falls behind facilitating the purpose ESR is shooting at. You can use "git log <file>" to track changes of <file>. It's like Gmail drafts. While it's delivered to you as an email stashing feature, I realized that it's the best cloud-based (offline-synced, omnipresent) note application. It can do that even if "note" is not in its name. We can be creative about using the tools at our disposal. Besides (back to the original problem), it can be handy sometimes that you have a tool that can operate over the whole range of managed files, even if they are logically unrelated.
- crazygringo 12y agoI don't know about this tool, but git does not make it easy to move files from one repository to another, for instance, and maintain that file's history. Heck, I'd like to be able to e-mail a single file to someone, and have the file keep its revision history. File-based revision histories, as opposed to repository-based, have a whole host of advantages that come from flexibility.
- dzsekijo 12y agogit also has good support for explicit cutting down the repo to a subset of its files, or merging back changes of a partial repo to the common one, see filter-branch and subtree commands.
- jxf 12y agoHere's a very obvious use-case: You have a single file with many historical changes. That file moves to a new directory that is not a subdirectory of its current directory. In git, the file vanishes from the repo and can't be tracked easily anymore. You lose all of its past history if you put it into a new repo. In SRC the history moves with the file.
- aidenn0 12y agothe .git directory need not be in the same place as your working files. I keep my /etc in git with no issues.
- sparticvs 12y agoSounds like someone misses DEC VMS's method of revision
- GFK_of_xmaspast 12y agoI sort of do.
- dmd 12y agoSee also https://github.com/rupa/rvn https://github.com/rupa/rvn (not to be taken seriously). (By the author of z, possibly the most time-saving unix tool ever created).
- ansible 12y agoFor this niche, I use vcsh: https://github.com/RichiH/vcsh https://github.com/RichiH/vcsh I've been using git for years at this point, so I'm glad to leverage my existing skill. It also ties into my existing setup for SSH, so that I can push and pull changes from a central server. I like this because I regularly work on two different desktops, a laptop, and a few other machines.
- coned88 12y agoWhat's wrong with RCS?
- jarun 12y agoHow about fossil? http://tuxdiary.com/2013/09/20/fossil/ http://tuxdiary.com/2013/09/20/fossil/