Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simple Revision Control

catb.org

Post reply on HN
Print view View original

11–20 of 179 posts

Re: Simple Revision Control

#11

Post by jgrahamc »

SwellJoe wrote: post #8

I 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…

There's a FAQ on this: http://esr.ibiblio.org/?p=6518

"Why SRC instead of $VCS?

Most version control systems today are multi-user, multi-file, and multi-fork oriented. These are all good features and properties to have, but they neglect the need to maintain simple single-file documents, such as HOWTOs and FAQs, much like the very file you are reading now. There is even a good use-case for small programs and scripts. Do you presently keep your ~/bin contents under version control? If not, consider using SRC for them."

Re: Simple Revision Control

#12

Post by kazinator »

There 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

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).

Re: Simple Revision Control

#13

Post by bshimmin »

owenmarshall wrote: post #9
bshimmin wrote: post #7

Earlier quoted context omitted.

From 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.

You'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.

You'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.

Re: Simple Revision Control

#14

Post by vertex-four »

SwellJoe wrote: post #8

I 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…

The point is managing single files, not directories. Want to version control your ~/.bashrc, for example? Or a single document? You can do that without having to move the file into its own directory in some hackish way.

Re: Simple Revision Control

#15

Post by kazinator »

SwellJoe wrote: post #8

I 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…

I am not entirely sure I understand why one wouldn't use git for this role.

Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git.

For many users, using Git means cutting and pasting command line recipes scoured from desperate web searches, and crossing their fingers.

This does not go away when you use Git just for personal use with a repo that has no upstream.

ESR probably wants something that is simple to use for simple use cases.

Re: Simple Revision Control

#16

Post by owenmarshall »

bshimmin wrote: post #13
owenmarshall wrote: post #9

Earlier quoted context omitted.

You'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.

You'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.

Hah. 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!

Re: Simple Revision Control

#17

Post by shabble »

vertex-four wrote: post #14
SwellJoe wrote: post #8

I 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…

The point is managing single files, not directories. Want to version control your ~/.bashrc, for example? Or a single document? You can do that without having to move the file into its own directory in some hackish way.

GNU Stow[1] referencing a git repo in ~/.dotfiles is what I use for that.

You might consider it hackish, but at least there are plenty of tools out there for managing it :)

[1] https://www.gnu.org/software/stow/

Re: Simple Revision Control

#18

Post by debacle »

ESR, 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.

Re: Simple Revision Control

#19

Post by mwfogleman »

hapless wrote: post #10
SwellJoe wrote: post #8

I 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…

You are almost certainly more experienced than ESR. He held his last technology position in the early 1990s.

Then again, ESR has assumed a role in the free software community as a VCS expert, as evidenced by his reposurgeon project and uses.
Post reply on HN