K
Kenneth P. Turvey
A while back there was a thread about Linus Torvald's talk at Google about
his git revision control system (still available on YouTube). Many people
were offended by Torvald's manner of giving the talk. I wasn't
particularly and found it interesting enough to give git a try. I'm a
subversion user and used that as my benchmark. I thought I would post my
thoughts on the subject so those involved in the previous thread might
take a look at the product too.
First off... get the latest version of git. The version that was included
with my OS isn't current.
When I first tried it I was disappointed. It does some things differently
than subversion and at first I saw these differences as defects. I was
used to having a single repository for all of my source code. I liked it
that way. There were a few other things, but mostly they came down to
being questions about what I was used to, not what was best.
After trying it out for a while, giving up on it, and going back to it,
I've pretty much decided that there really isn't any reason to choose
subversion over git. Git will do everything subversion will do and does
some things much better. The only shortcoming I found in git was it's
inability to deal with multiple projects in the same repository well. You
really have to check out the whole repository and can't just check out the
piece you want. This isn't as big a liability as it seemed at first. For
real problems git can handle multiple projects and their
interdependencies as well as subversion. In both cases you will end up
with symbolic links under revision control. This isn't really something
that can be avoided using subversion's design.
Git will also allow multiple developers to commit to their own
repositories and merge their commits (including all history) together when
they choose, rather than at each commit. This can all be done while
offline. I think this is probably a big win for many projects.
Other than these two issues there really isn't much to differentiate the
products from each other. Git performs better and is more flexible in
dealing with history so it is probably the system to choose by default.
In addition, moving all the history for a project out of subversion and
into git will only take an hour or so for most projects (a few minutes if
you've done it before). So keeping a project in subversion because of
momentum doesn't really make much sense either.
I'm moving my code from subversion to git based on what I saw in Torvald's
talk and learned in later experimentation.
Thanks Google and YouTube.
his git revision control system (still available on YouTube). Many people
were offended by Torvald's manner of giving the talk. I wasn't
particularly and found it interesting enough to give git a try. I'm a
subversion user and used that as my benchmark. I thought I would post my
thoughts on the subject so those involved in the previous thread might
take a look at the product too.
First off... get the latest version of git. The version that was included
with my OS isn't current.
When I first tried it I was disappointed. It does some things differently
than subversion and at first I saw these differences as defects. I was
used to having a single repository for all of my source code. I liked it
that way. There were a few other things, but mostly they came down to
being questions about what I was used to, not what was best.
After trying it out for a while, giving up on it, and going back to it,
I've pretty much decided that there really isn't any reason to choose
subversion over git. Git will do everything subversion will do and does
some things much better. The only shortcoming I found in git was it's
inability to deal with multiple projects in the same repository well. You
really have to check out the whole repository and can't just check out the
piece you want. This isn't as big a liability as it seemed at first. For
real problems git can handle multiple projects and their
interdependencies as well as subversion. In both cases you will end up
with symbolic links under revision control. This isn't really something
that can be avoided using subversion's design.
Git will also allow multiple developers to commit to their own
repositories and merge their commits (including all history) together when
they choose, rather than at each commit. This can all be done while
offline. I think this is probably a big win for many projects.
Other than these two issues there really isn't much to differentiate the
products from each other. Git performs better and is more flexible in
dealing with history so it is probably the system to choose by default.
In addition, moving all the history for a project out of subversion and
into git will only take an hour or so for most projects (a few minutes if
you've done it before). So keeping a project in subversion because of
momentum doesn't really make much sense either.
I'm moving my code from subversion to git based on what I saw in Torvald's
talk and learned in later experimentation.
Thanks Google and YouTube.