On Aug 15, 2007, at 15:26:07, Lennart Sorensen wrote:
As another example, take a look at "git", the SCM we use for the
kernel, as contrasted with the older CVS. You can import your
complete CVS history into it without data loss, and then you can even
continue to use it the exact same way you used to use CVS, with some
slight differences in command-line syntax. Once you are ready to
move further, though, you can create multiple local branches to have
your co-workers pull from to test changes. You discover that merging
branches is much easier in git than in CVS. Your company starts to
use a more distributed development model, they implement a policy
telling developers to break up their changes into smaller pieces and
write better change-logs. Somebody suddenly discovers the ability to
"sign" a particular release version with a private key, and you start
doing that as part of your release management to ensure that the
codebase marked with a client tag is the exact same one you actually
shipped to that client.
On a fundamental level, GIT is a completely different paradigm from
CVS. Its internal operations are entirely differently organized, it
uses different algorithms and different storage formats. The end
result of that is that it's literally orders of magnitude faster on
large codebases. But to the USER it can be used exactly the same;
you could even write a little CVS-to-GIT wrapper which imported your
CVS into a git repo and then let you operate on it using "gcvs"
commands the same way you would have operated on real CVS repositories.
Just some food for thought
Cheers,
Kyle Moffett
-
