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

141–150 of 179 posts

Re: Simple Revision Control

#141

Post by kazinator »

bryanlarsen wrote: post #100
e12e wrote: post #46

Earlier quoted context omitted.

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

That was ESR's conclusion as well. SRC is just a simple wrapper around RCS.

If you want a simple wrapper around RCS (or at least RCS semantics), why not just use CVS.

CVS has sequential numbers. Well, sort of: 1.1, 1.2, ... unless you branch. Close enough.

It works with individual files well enough (and in fact not all that well with clusters of them).

CVS started in 1986 as in fact a shell-scripted wrapper around RCS.

Re: Simple Revision Control

#142

Post by sofal »

IshKebab wrote: post #116
npsimons wrote: post #95

Earlier quoted context omitted.

It'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…

Are you serious? Git is by far the least user-friendly version control system I've used (Mercurial being the best). Here are some longer articles explaining why git sucks so much (from a convenience / user friendliness point of view): http://reprog.wordpress.com/2010/05/10/git-is-a-harrier-jump... http://merrigrove.blogspot.co.uk/2014/02/why-heck-is-git-so-... http://stevebennett.me/2012/02/24/10-things-i-hate-about-…

Version control is one of those annoying admin tasks that you have to do and what to think about as little as possible.

I disagree. Version control as a concept is inherently embedded in every software change you make as part of a team. Every time you coordinate a change with other people, you are participating in a version control task. Your VCS can either capture the inherent complexity involved or it can sit there and force you to hash out the complexities on your own before you invoke it. Either way, you will be occupied by the task of controlling versions of your code.

Re: Simple Revision Control

#143

Post by zBard »

kazinator wrote: post #124
click170 wrote: post #59

Earlier quoted context omitted.

I think you may have misunderstood my comment, of course there is more to it then checkout and commit. Those are the basics, that's where you start. Then you get stuck somehow, and you read more . That's what I did at least. IMO It's about not giving yourself the impression that the learning curve is insurmountable, you can do it. Starting with the basics and growing up is, I thought, common knowledge for acquiring a…

I perfectly understand that there are hordes of programmers for whom messing around with git is far more interesting than the actual code they are working on. "Man, I just interactively rebased my last six changes so the commits are in a different order, and two of them were squashed into one! Boy, does that feel productive."

How is that in anyway a reply to what s/he wrote ? Even snark should have a purpose.

Re: Simple Revision Control

#144

Post by GFK_of_xmaspast »

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

Eric Raymond, everybody: "Nor is it any good thing that “youths” now behave as though they think they’re operating with a kind of immunity. We saw this in Ferguson, when Michael Brown apparently believed he could could beat up a Pakistani shopkeeper and then assault a cop without fearing consequences. (“What are you going to do, shoot me?” he sneered, just before he was shot) As he found out, eventually that shit’ll get you killed; it would have been much better for everybody if he hadn’t been encouraged to believe that his skin color gave him a free pass."

"

It’s not clear to me that this kind of indulgence is any better – even for blacks themselves – than the old racist arrangement in which blacks “knew their place” and were systematically cowed into submission to the law. After all – if it needs pointing out again – the victims of black crime and trash culture are mainly other blacks. Press silence is empowering thugs."

Re: Simple Revision Control

#145

Post by ngoldbaum »

kazinator wrote: post #49
cschmidt wrote: post #33

Earlier quoted context omitted.

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

Notably mercurial sidesteps this mess but not exposing the staging area in its UI.

Re: Simple Revision Control

#146

Post by sofal »

InclinedPlane wrote: post #130
npsimons wrote: post #95

Earlier quoted context omitted.

It'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…

Git is terrible. Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encourage the most effective modes of use. Hell, even the "best practices" of the git community are highly questionable (just rewrite history for aesthetic reasons, what could go wrong?). Git is highly tuned to the use case of serving linux kernel development. Many ot…

just rewrite history for aesthetic reasons, what could go wrong?

I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing your change, how is this not a "rewrite of history for aesthetic reasons"? Do you really need to know about all the tens of little WIP commits I made because I just wanted to back up my changes before going to the bathroom? Am I not allowed to clean up a little bit before I publish all my own changes to the world?

Now if you're just talking about rewriting published history, then nobody is going to disagree with you.

Re: Simple Revision Control

#147

Post by ynik »

duaneb wrote: post #110
click170 wrote: post #23

Earlier quoted context omitted.

> 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 would say, git isn't harder than any other distributed vcs. However, its tooling leaves a lot to be desired: its terminology is non-obvious and requires sifting through dense man pages (or dense reference books), it's hugely inconsistent (e.g. git remote rename vs git branch -m), and rebasing and merging can create confusing messes for users to sift through. DVCS is hard. Git is hard. They're hard for very differen…

git is harder than other distributed vcs.

With a centralised VCS, you have two 'version's of the file system: your local working copy, and the current branch in central repository. That leaves limited room for inconsistencies between the versions that might confuse the user / need conflict resolution. Logical versions = Number of working copies + Number of branches

With a distributed VCS, you necessarily add a third 'version' (current branch in local repository). That's unavoidable. Logical versions = Number of working copies + Number of local branches (over all working copies) + Number of branches in central repository.

But git is considerable worse: with git checkout working with a central repository, there's at least 5 versions involved, all of which may differ: working copy, index, local branch in local repo, remote branch in local repo, branch in remote repo.

Different commands affect different 'versions', so it's easy for new users to get them into an inconsistent state, and pretty much impossible for them to recover: usually they can't identify the reason for their trouble because they do not distinguish between these 5 'versions' mentally.

It's impossible to build good tooling on top of this mess, unless your tooling completely hides these extra 'versions' from the user by always keeping them consistent with some other 'version'.

For example, a commit tool might use the stash only during the commit itself, so stash and local working copy are always kept consistent. Unless the user also uses the git command-line client...

Of course, git is also hard due to the inconsistencies in the command line interface, but that's in addition to this fundamental unnecessarily complexity.

Re: Simple Revision Control

#148

Post by ansible »

For this niche, I use 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.

Re: Simple Revision Control

#149

Post by wglb »

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

And there is this: https://lists.debian.org/debian-devel/1999/04/msg00197.html

Re: Simple Revision Control

#150

Post by jotux »

sofal wrote: post #146
InclinedPlane wrote: post #130

Earlier quoted context omitted.

Git is terrible. Git is typical of a tool built by engineers. It has good primitives but a clunky overall design and horrible UI. It does not naturally encourage the most effective modes of use. Hell, even the "best practices" of the git community are highly questionable (just rewrite history for aesthetic reasons, what could go wrong?). Git is highly tuned to the use case of serving linux kernel development. Many ot…

just rewrite history for aesthetic reasons, what could go wrong? I have never understood the problem that some people have with the idea of rewriting history. It's as if the very idea of it offends them. Do file system writes also put you off? Is it important that I see the history of every single keystroke you made while twiddling with your config file? When you fixed a typo you made in a comment before publishing y…

I see the ability to change local history as a huge benefit. Not only can I track changes but before I publish them I can make decisions about how to make them more presentable/understandable to other developers.
Post reply on HN