"Pietro Mascagni" [off-list ref] writes:
So, in 15 seconds, how does one argue that GIT is vastly superior to
other version control software, especially CVS.
Vs CVS, in 15 seconds, I'd say:
* Atomic commits. CVS makes it hard to get back to a consistant state
in the past. What does it mean, for example to checkout revision 1.5
of a project in CVS (hint: nothing, it's meaningfull for a file
only).
* Rename management.
* Performance.
* Perhaps your boss will be interested in the "data integrity" (i.e.
git fsck) problem too.
You have also the joker argument "Linus Torvalds is very intelligent,
and he gave up with CVS looong ago", but it might or might not work.
If you have to argue against SVN, you'll need more than 15
seconds ;-).
--
Matthieu
On Tuesday 2007 April 17 10:13, Matthieu Moy wrote:
* Atomic commits. CVS makes it hard to get back to a consistant state
in the past. What does it mean, for example to checkout revision 1.5
of a project in CVS (hint: nothing, it's meaningfull for a file
only).
* Rename management.
* Performance.
* Perhaps your boss will be interested in the "data integrity" (i.e.
git fsck) problem too.
Don't forget
* Can work offline
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
On 4/17/07, Matthieu Moy [off-list ref] wrote:
If you have to argue against SVN, you'll need more than 15
seconds ;-).
- Same branch/merge limitations as CVS: knows how to branch, not how
to merge :-/
- Repository corruption / Berkeley DB
cheers,
martin
On 4/17/07, Andy Parkins [off-list ref] wrote:
Don't forget
* Can work offline
Bad argument with seniors. Being able to take your work home
considered security breach. Being able to work indepently of the
clueless technical support team considered inability to delegate
(like "pass the blame on").
This one is already tried with the described effect.
On Tue, 17 Apr 2007, Matthieu Moy wrote:
* Perhaps your boss will be interested in the "data integrity" (i.e.
git fsck) problem too.
The data integrity thing is a lot more than just fsck.
I care a lot about my data, and it's an area where a *lot* of systems fall
down. CVS is just about the worst (basically no checksums or sanity
checking anywhere), and you can pretty much have total data corruption
without ever even _realizing_, until you try to get some old version.
Even more interesting with CVS is that you can have total data corruption
and you'll not realize it *even*as* you use the data. Lots of people and
projects have been known to happily move *,v files around and edit the
CVS repo files by hand to make things look right, which means that not
only did you do a "rename" in CVS, you actually renamed *retroactively*
too - you made history look wrong!
So with CVS, you actually have no guarantees what-so-ever that when you
check out something old, you'll get what you actually used to have. You
can tag things as much as you want - if people end up editing the CVS
files (and people *do* that), you'll never have any indication that the
history you checked out isn't the "real" history. So you can check out
some old version that you made a release to a customer off, and may be
totally unable to recreate the customer problem, because the release you
checked out doesn't even compile any more!
You can actually do the same with most other SCM's. It may need somebody
who is actually malicious, but even that isn't necessarily the case. Lots
of SCM's don't have any checksums *at*all* on their data - the only way
you'd ever know that something bad happened and you had disk corruption,
is when you check something out and it just looks corrupted!
In other words, in a lot of SCM's, you're actually *lucky* if the
corruption is so serious that it's not just a subtle "data is wrong"
thing, it's so pervasive that you actually get an error from the SCM.
In git, every *single* piece of data is not just checksummed, it's
CHECKSUMMED. Yeah, we use CRC's and Adler32 for some things, but even
those are actually *also* protected at a higher level by real
cryptographic hashes. You simply *cannot* corrupt data by mistake and not
know about it. You can lose it, you can corrupt it, but it *will* be
noticed.
If that doesn't make you feel good about your data, I don't know what
will. Git will not replace backups in any way, shape, or form (although
you can obviously use git itself to _do_ those backups - the joy of
distributed SCMS), but it will tell you when you *need* those backups.
Guaranteed.
And I can tell you that that is actually very rare. I doubt *any*
commercial SCM will come even close. They might have checksums, but
nothing really strong. It might be a CRC or even weaker. Or it might be
nothing at all (and sadly, that's the *common* case).
Linus