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

41–50 of 179 posts

Re: Simple Revision Control

#41

Post by bhaak »

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

Re: Simple Revision Control

#42

Post by _delirium »

GFK_of_xmaspast wrote: post #27
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

See also his attempts to take credit for other people's work on ncurses: http://invisible-island.net/ncurses/ncurses-license.html. I don't think I would want to work with him on a project.

Re: Simple Revision Control

#43

Post by kazinator »

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 dropped out of highschool and attended no postsecondary and I don't have any problems with Git.

Git problems arise when people want to do moderately sophisticated things, beyond just committing changes and viewing logs and diffs.

> If git commit and git checkout are too complicated,

If "If git commit and git checkout are too complicated" is your argument, then you aren't doing anything more sophisticated with git than what you learned from a svn to git migration tutorial in five minutes.

People do more with version control than "commit and forget".

If that's all you need, then what you really want is backup software that takes regular snapshots of your filesystem.

Re: Simple Revision Control

#44

Post by Roboprog »

cschmidt wrote: post #33
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…

I sometimes use git this way on local files: git init # make a local repo git add foo.txt # add the file [edit] git add -u # add changes to commit git commit -m"made a change" # check in changes git log # see commits git status # what has changed That's really all you need to know.

That's what I do on my "bin" directories (for scripts and such).

On the other hand, maybe being able to grab something analogous to a ",v" file and moving the archive for a single file around by itself has some value. Just not enough value for me to bother installing RCS when git is already present :-)

Re: Simple Revision Control

#45

Post by pjc50 »

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…

git commit and git checkout are fine. git pull and git push are where the problems start.

as I got myself into tighter and tighter jams

I suppose this is the thing; if you're happy to learn that way, fine. It's just that git is particularly prone to "I've trashed local state and lost work" / "I've just pushed a huge mess and will have to lose time cleaning it up, if that's even possible".

Re: Simple Revision Control

#46

Post by e12e »

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…

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

Re: Simple Revision Control

#48

Post by treerock »

cschmidt wrote: post #33
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…

I sometimes use git this way on local files: git init # make a local repo git add foo.txt # add the file [edit] git add -u # add changes to commit git commit -m"made a change" # check in changes git log # see commits git status # what has changed That's really all you need to know.

So what benefit do you get from that? i.e. have you ever gotten yourself in a mess and thought, 'thankfully I used git here, otherwise I'd be fecked.'

Re: Simple Revision Control

#49

Post by kazinator »

cschmidt wrote: post #33
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…

I sometimes use git this way on local files: git init # make a local repo git add foo.txt # add the file [edit] git add -u # add changes to commit git commit -m"made a change" # check in changes git log # see commits git status # what has changed That's really all you need to know.

What you need to know is that "git add" has little to do with "foo add" where "foo" is just about any other version control system. Look, you ran "git add" on files that were already added, what?

There is this hidden thing called the index that confuses the heck out of everyone. Oh, but it's not always called the index, either: that would be unnecessarily easy. Sometimes it is called "the cache". How to show the difference between the index and HEAD? Why, of course not "git diff --index" but "git diff --cached".

(In what way the index acts as a cache is beyond me; a cache is a fast place where you look for something that is also available in some slower place, but things in the index are sometimes only in the index and nowhere else!)

Furthermore, things in the index are not "indexed" or "cached". Why, they are "staged". So why don't they call it the stage? (And only that: no synonyms?)

(The index behaves like a cache in the following sense: it has transparent "read through". If you do a "git diff", you see the difference between the index and your working copy for any changed file. But if the index doesn't have that file, then it gets out of the way and you see the diff between HEAD and the working copy. This confuses people because the transparent behavior teaches them, most of the tiem, that "git diff" is like "svn diff" when it isn't.)

The overloaded meanings of "git reset" are astonishing also. Sometimes it means "make the working tree like what is in HEAD". Sometimes it means "no, don't touch the working tree, but change HEAD to a particular revision". Sometimes it means "don't touch HEAD or the working tree: make the index look like a particular revision".

Want interactivity? Sometimes it's --interactive, and sometimes it's --patch. Please, just let me do "git stash --interactive"; don't make me correct that to "--patch".

Re: Simple Revision Control

#50

Post by desdiv »

Karunamon wrote: post #36
vertex-four wrote: post #14

Earlier quoted context omitted.

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.

How is this different from just `init`ing the repo in your home directory and only adding files you care about?

What happens if you accidentally git clean -dfx?
Post reply on HN