Many people think that Git MUST be better because Linus Tolvards uses
it. But, that's mainly because of the way the Linux project operates.
I've had developers tell me how much better Git is when they work with
on their own one-man projects because Git is "distributed". They don't
realize that Git isn't distributed unless you actually have two copies
of the repository.
Git uses a distributed repository which can have its advantages.
However, there are times I'd rather have a centralized repository like
Subversion has.
Distributed repository version control systems are good when you have
lots of people working on a project, no desire to try to control
access to all of those people, and no real deadlines.
Think of a distributed repository as a tree with the top level being
the "official" archive. At each node of the tree is a duplicate
repository. You can check out from any node of the repository and
create your own node. Since you have your own node, you have a
complete source repository, and can check in and out of that
repository to your hearts content.
And, you can have your friends share your repository or make their own
nodes and treat your repository as their parent repository.
The trick is when you want your changes to be placed into the official
project. You can submit your changes (in Git as a patch) to the parent
repository, but the person in charge of that repository acts as a
gatekeeper and can simply reject your changes. Thus, although you
still have your changes, and their checked into your version of the
repository, they won't be in the parent, and they won't be in the
project.
You can see how this works out great with Linux which has hundreds of
programmers doing active development. Tolvards only has to trust a
handful of people. You can check out from Tolvard's master repository,
but he won't ever accept your changes. If you want your changes into
the official Linux kernel, you have to find someone who trusts you in
the hierarchy and use their repository node.
However, distributed repository systems don't work so well with most
commercial development. In commercial development, you have deadlines
and allowing people to work isolated from the rest of the group
usually is asking for trouble. Developers simply like working isolated
because they don't have to worry about what other people are doing.
They can concentrate on their own work. What happens is that
developers deliver patches around deadline times because their work is
incomplete. Then, someone has to do the merging of all of those
changes, and handle merge conflicts. Hilarity ensues.
Distributed systems also mean duplicated copy of proprietary
information. Your entire source development tree can easily be
duplicated far and wide. And, it does happen. Centralized repositories
mean centralized control over who gets to see what and who gets to
make changes.
So, the question is really what are you planning on developing. Is
this a corporate development? Will these people have access to the
centralized repository, or will it be mainly "off line". Are you
responsible for securing the projects or is each group going to do
that themselves?
If all you're providing is a server, and you have no care about the
individual projects, Git might be better. In that case, you have a
single person be the team leader for a particular project, and you'll
only accept patches from that one person for that one project. If
another person wants to work on that project, they'll have to get
their copy of the repository from that team lead and submit their
changes to that team lead. It keeps you out of the picture.
If you have some sort of central responsibility for the various
projects, and you're expected to maintain the accessibility, you'll
need a centralize repository system like Subversion.
--
David Weintraub
qazwart_at_gmail.com
Received on 2010-05-24 23:49:53 CEST