OSDev.org

Solar wrote:On the "git -> overkill" tangent:

Link to Thorvals talking about git

1) I don't like the arrogance he repeatedly expresses during his speech. In fact, I think Thorvals is a git.

Solar wrote:2) git is *aimed* at a massive-parallel, multi-merge project (like the Linux kernel undoubtedly is). It's great for that purpose, no doubt, but many of its features, and its overall workflow, are especially aimed at that very purpose.

Solar wrote:3) Those features and workflows make git less-than-straightforward to learn and use, especially if you had previous experience with "classic" systems (like CVS, SVN, ...).

4) For projects who do not have the requirements mentioned under 2), "man git" and "man git-clone" are, IMHO, overkill. Just go along with "XYZ checkout", "XYZ add" and "XYZ commit".

git clone http://some.url/repo.git project
cd project
$EDITOR somefile
$EDITOR newfile
git add newfile
git commit -a
git push

echo "export EDITOR=nano" >> ~/.bashrc

Owen wrote:Oh, and to the person who complained about using vim:

Owen wrote: Don't use them features then. You don't have to. Git is like C: it contains lots of useufl features. Lots of features to hang yourself with too. But they're optional.

Kevin wrote:However, with SVN this means that for almost any operation you need to access the server (obviously for commit, but also including log, diff, ...). So if you're offline you basically can't work. And if your connection to the server isn't really fast, you'll definitely notice the difference compared to working on a local repository as in git.

• several SVN commands, including 'svn diff' (working copy against repo HEAD) and 'svn revert', work without access to the server. (I admit that 'svn log' requires connection.)
• SVN transmits much less data over the network than CVS, and thus is much faster on most operations.

Owen wrote:I don't see any real arrogance in that speech; in fact, I see lots of jokes at his own expense about his (not entirely undeserved) reputation for arrogance.

Owen wrote:

Solar wrote:2) git is *aimed* at a massive-parallel, multi-merge project (like the Linux kernel undoubtedly is). It's great for that purpose, no doubt, but many of its features, and its overall workflow, are especially aimed at that very purpose.

Don't use them features then. You don't have to. Git is like C: it contains lots of useufl features. Lots of features to hang yourself with too. But they're optional.

I understand SVN. I know that none of the additional features of git make any difference to me, and I know that - to use git confidently - I would have to spend quite some time reading. And none of the projects I work on, most importantly including office work, actually use git - so that reading / learning would earn me nothing. On the other hand, being competent in SVN made me the #1 contact for SVN-related problems in our department... it's a ROI thing.

Solar wrote:Keep in mind what you are comparing. SVN was written not as the perfect solution to version control, but as a replacement for the most commonly used VCS of the time, which was CVS. Some of the core improvements of SVN over CVS are:

• several SVN commands, including 'svn diff' (working copy against repo HEAD) and 'svn revert', work without access to the server. (I admit that 'svn log' requires connection.)
• SVN transmits much less data over the network than CVS, and thus is much faster on most operations.

And none of the projects I work on, most importantly including office work, actually use git - so that reading / learning would earn me nothing.

Kevin wrote:...be glad I didn't discuss about SVN with you then - you wouldn't use it today because of the aggressive advertising!

git-svn exists and is my favourite SVN client nowadays.

Solar wrote:As a CVS user at the time, the advantages of SVN - or rather, the complete lack of disadvantages - were immediately obvious to me.

Combuster wrote:

I understand SVN. I know that none of the additional features of git make any difference to me, and I know that - to use git confidently - I would have to spend quite some time reading. And none of the projects I work on, most importantly including office work, actually use git - so that reading / learning would earn me nothing. On the other hand, being competent in SVN made me the #1 contact for SVN-related problems in our department... it's a ROI thing.

I might add to that, that I never saw any VCS except for subversion (or none ) in all professional environments that I have seen so far.

What you never seen Source Safe

Solar wrote:Actually, in my first company they did use VSS. And the application was VBA for Access. About 100 tables, modules, and forms, In a single .mdb file. Oh, the fun of having to wait for the other dev'er to check in, and having to merge your changes into his version (which, of course, was different from the one you started with). While the next dev'er prods you for taking so long.

And the server being unavailable half the time.

That was fun.

Solar wrote:when we talked about the "war on terror" recently, he expressed confusion about why they would target something like the World Trade Center, when hitting the Microsoft campus would be so much more damaging to the economy "because everyone needs their patches and updates".