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
"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"
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.
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:1)
Re: (Score:2)
Re: (Score:1)
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: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.