That file naming convention is too predictable. Around here we use names like: winter-project nov-15-project project-2.0 11.05.12-project project-somebodys-name
Which one is the most recent? Oh look at the last modified date for the file, of course.
:( You need about 5 pages of material to learn how to do 90% of stuff in GIT, it gets more complicated in bigger environments, but a lot of it is rinse & repeat. The best I've done with GIT is pair it up with NANT/CruiseControl.NET to get a free & extremely effective build server going. Most of the setup was in the latter two technologies referencing dev & prod environments. A 456 page book about this straight forward of a technology seems a bit excessive. Then again 456 pages is probably an
With regular version control you're correct. Git however is a mess of leaky abstractions and misfeatures and requires an expert to do things that would be mundane less silly systems.
My experience with "less silly systems" suggests that the mundane things list is 2 items, and everything else is either impossible to do or doesn't quite do what you want. That and those 2 items aren't any harder to do in git, people just get confused by the staging area.
"X's aren't any harder to do in git, people just get confused by Y"
This seems to be a common response to complaints about git, in spite of it being obviously silly. If more people get confused: it is harder to use; that is what harder to use means.
Other flavors of such silliness include: "git is not complex, you just have to understand its internal data model well" or "it is great, just read this 450 page book very very carefully and perhaps you can figure it out"
There are different kinds of hard. 1)How long does it take for an expert to do it? 2)How long does it take for a beginner to do it? 3)How long does it take for an expert in a different tool, who is a beginner in this one?
There are a large number of things that are trivial for an intermediate/expert git user to do using git that are damn near impossible to do in SVN.
Basically GIT does well with 1 and so-so with 2, but terrible with 3 SVN does poorly with 1, good with 2, and 3... the only sane person who's an ex
VSS was at least usable if you stuck SourceOffSite in front of it. That kept 99% of the problems from happening.
We evaluated a bunch of solutions back in '05-'07 and finally switched everything to SVN in '07. TortoiseSVN was the key selling point. Our environment is one where the users are not overly geeky or technical and a central repository suits our needs far better. We're not an open-source shop and all code is proprietary.
I've looked at git a few times, it just doesn't meet our needs.
We have a equal opportunity Calculus class -- it's fully integrated.
PFT! Version control is for sissies. (Score:5, Funny)
I have my own simple and versatile way of keeping track of branches.
*Project
*Copy of project
*Copy of Copy of project
*Copy of Copy of copy of project
Re: (Score:2)
That file naming convention is too predictable. Around here we use names like:
winter-project
nov-15-project
project-2.0
11.05.12-project
project-somebodys-name
Which one is the most recent? Oh look at the last modified date for the file, of course.
Re: (Score:1)
Re: (Score:2)
Speaking from exp.
And then somebody makes an argument that all devs should be paid equal and the servers start smoking
Re: (Score:1)
True, and so is the version control idea I stole:
age file
does "mv file file-; cp -p file- file" so you end up with files named "file" and "file-". age again and you get file, file- file--.
Which one is the most recent? In this example, it's always the file named "file".
Simple but very effective. However, I'm moving into the 21st century with git.
Re: (Score:0)
Version control? Isn't that why they made USB Sticks?
Re: (Score:0)
Reading a 456 page book on version control seems a waste of time. (Unless lots of your life resolves around merging code).
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:0)
With regular version control you're correct. Git however is a mess of leaky abstractions and misfeatures and requires an expert to do things that would be mundane less silly systems.
Re: (Score:0)
My experience with "less silly systems" suggests that the mundane things list is 2 items, and everything else is either impossible to do or doesn't quite do what you want. That and those 2 items aren't any harder to do in git, people just get confused by the staging area.
Re: (Score:1)
"X's aren't any harder to do in git, people just get confused by Y"
This seems to be a common response to complaints about git, in spite of it being obviously silly. If more people get confused: it is harder to use; that is what harder to use means.
Other flavors of such silliness include:
"git is not complex, you just have to understand its internal data model well" or "it is great, just read this 450 page book very very carefully and perhaps you can figure it out"
Re: (Score:0)
There are different kinds of hard.
1)How long does it take for an expert to do it?
2)How long does it take for a beginner to do it?
3)How long does it take for an expert in a different tool, who is a beginner in this one?
There are a large number of things that are trivial for an intermediate/expert git user to do using git that are damn near impossible to do in SVN.
Basically GIT does well with 1 and so-so with 2, but terrible with 3
SVN does poorly with 1, good with 2, and 3... the only sane person who's an ex
Re: (Score:2)
the only sane person who's an expert with another tool switching to SVN is just in the process of leaving CVS...
Or RCS. Or SCCS. Or PVCS. Or Clearcase. Or (shudder) Visual SourceSafe. There are a lot of tools out there that are more painful than Subversion...
Re: (Score:2)
We evaluated a bunch of solutions back in '05-'07 and finally switched everything to SVN in '07. TortoiseSVN was the key selling point. Our environment is one where the users are not overly geeky or technical and a central repository suits our needs far better. We're not an open-source shop and all code is proprietary.
I've looked at git a few times, it just doesn't meet our needs.