Linus wants a "distributed" version control system. In Linux
development, every developer can have their own complete source
archive which they sync with various other archives. Subversion simply
isn't structured in this way. And, adding SDK doesn't quite cut it.
The advantage of a system like GIT is that the archive is distributed
and there is no "point of failure". Each developer can have their own
private copy of the entire archive. They can put their changes in
their archive and sync with other developers. If access to the archive
you normally sync to is down, you can simply sync with another
developer. Also, there are no bottle necks since you can sync your
source archive with thousands of other copies of the archive. It can
scale up indefinately.
Virtually, the archive is structured in a pyramid like structure. Each
developer can deliver their changes with other developers on their
level or they can deliver their code to the level above. At the very
top of this pyramid sits that grand foobah who holds the keys to the
main development branch. In Linux development, that position is held
by Linus himself.
Distributed archive fans like to talk about the fact that thousands of
developers can work on the archive in their own little way without
affecting anyone else. These developers can work with their fellow
developers and sync changes back and forth with each other. Since each
developer is king of their own little domain, they each can decide
what changes to accept or reject from their fellow developers. Grand
collaborations can take place without the approval of anyone from
above. The official claim is that a centralized server cannot handle
that type of development.
I disagree that centralized servers cannot handle this development method.
Let's imagine a centralized version control system that has excellent
branch development capabilities. No developer directly works off of
the trunk. Instead, each developer has one or more branches that
branched off of the trunk. Developers can rebase their branch based
upon changes in the trunk they might not have, or deliver code to the
trunk. For this to work, branching and merging operations must be
smooth and automated. Directories as well as file changes must be able
to be merged back and forth.
Let's imagine that developers have a right to control change access to
their branch. They may only allow themselves to make changes (probably
the default setting), allow only a select group of developers to make
the changes, or maybe open the ability to make changes to everyone. In
this respect, the trunk is just another branch. The Grand Foobah who
sits at the top of development owns the trunk and can set privileges
who can and cannot make changes on the trunk.
In such a centralized system, the development methodology is the same
Virtual Pyramid as it was in the distributed system. However, in a
distributed system, developers make a lot of changes to their private
copy of the archive without anyone being able to see or even know that
changes are taking place. In a centralized archive, all changes are
part of the central archive and are under constant scrutiny. This
allows the owner of the branch that will be receiving the changes to
track what is going on and know what types of changes to expect. This
puts pressure on developers to deliver their code on a more regular
basis.
The only real claims that distributed fans can claim is that there is
no point of failure, and that since not everyone is hitting a single
server, distributed archives are infinately scalable. Plus, there is
no single point of failure. If a large comet strikes North America
causing it to sink into the inky blue. And, that causes large tidal
waves to surge forth crossing the Atlantic and Pacific oceans and
wiping out civilization in both Europe and Eastern Asia, somewhere in
Uzbekistan, someone will have a copy of the source archive.
Civilization as we know it might end, but your project is safe.
I have personally found that distributed systems aren't all that
distributed. Most developers don't want other users using their
machines for syncing back and forth to the archive. Instead,
developers depend upon a very few machines that become the central
archive for everyone. In the end, everyone is syncing to the same
servers and hitting the same bottle necks.
Also, maintenance tends to be sloppier on distributed archives. In a
centralized heirarchy, someone takes the responsibiltiy for its
maintenance. A centralized archive is much more likely to be backed up
and its hardware kept up to date. In a distributed system, no one is
necessarily responsible because everyone believes someone else is
taking care of the issue.
On 8/15/05, Stefano Spinucci <virgo977virgo@yahoo.it> wrote:
> In the article "Linux: Using Git For More Than The
> Kernel" (http://kerneltrap.org/node/5557) Linus
> Torvalds says "...quite frankly, I think git is a lot
> better than CVS (or even SVN) by now...".
>
> SVN fits perfectly my needs, and I think git "is a lot
> better" only in some (few) areas, but maybe I haven't
> understand GIT very well... and I'd like to know what
> other SVN users think about the "inferiority" of
> SVN...
>
> ---
> Stefano Spinucci
>
>
>
> __________________________________
> Do you Yahoo!?
> Read only the mail you want - Yahoo! Mail SpamGuard.
> http://promotions.yahoo.com/new_mail
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
--
David Weintraub
qazwart@gmail.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 16 21:00:29 2005