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

21–30 of 179 posts

Re: Simple Revision Control

#21

Post by debacle »

kazinator wrote: post #15
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…

> computer science degree and years of experience to even begin to understand Git, for one thing.

Unless you're programming, in which case you should be able to understand git well enough, there are plenty of tools which completely abstract away the CLI interface (GitHub's is great).

Re: Simple Revision Control

#22

Post by mrb »

He 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

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.

Re: Simple Revision Control

#23

Post by click170 »

kazinator wrote: post #15
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…

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

With respect, I call shenanigans on this my good friend.

I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams.

I feel like this myth is perpetuated by a small group of people who are very vocal about "git is hard". If git commit and git checkout are too complicated, I don't know what else to say except that every VCS has those concepts, perhaps you're just used to those systems instead.

Re: Simple Revision Control

#24

Post by comice »

debacle wrote: post #18

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.

"ESR, is, if nothing else, the champion of his own relevance"

wonderful.

Re: Simple Revision Control

#25

Post by viraptor »

kazinator wrote: post #12

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

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

Re: Simple Revision Control

#26

Post by awalton »

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

Re: Simple Revision Control

#27

Post by GFK_of_xmaspast »

debacle wrote: post #18

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.

"a nice enough guy"

Nope:

http://esr.ibiblio.org/?p=26

Re: Simple Revision Control

#28

Post by GFK_of_xmaspast »

mwfogleman wrote: post #19
hapless wrote: post #10

Earlier quoted context omitted.

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.

Providing an excellent example of what your schoolteacher said about "assuming".

Re: Simple Revision Control

#29

Post by leoc »

mrb wrote: post #22

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

From TFA:

> 4. Modern CLI user-interface. Commands familiar to Subversion, Hg, Git users.

Doesn't seem that he's down on Mercurial's syntax.

Re: Simple Revision Control

#30

Post by k-mcgrady »

click170 wrote: post #23
kazinator wrote: post #15

Earlier quoted context omitted.

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…

> Because, for one thing, "one" sometimes doesn't have the computer science degree and years of experience to even begin to understand Git, for one thing. With respect, I call shenanigans on this my good friend. I dropped out of highschool and attended no postsecondary and I don't have any problems with Git. I started with the basics and read more as I got myself into tighter and tighter jams. I feel like this myth i…

I think git hard a small but steep learning curve. Lots of developers aren't used to using the command line anymore so git can seem 'scary'. Personally I gave up on git a couple of times before finally learning it but as a developer working by myself I also couldn't understand the need for version control (at the time) so giving up wasn't a big deal. I think once you give it a couple of hours of your time you can understand enough to use it in most situations. Plus the GUI tools (SourceTree for example) are quite good.
Post reply on HN