Re: Delete *for real* from a repository

Many people are jumping on GIT because it's what Linux uses and if Linux
uses it, it must be cool. What people don't understand is that Linux has a
good reason not to use something like Subversion.

Linux has a hierarchy of thousands of contributors. Giving and vetting each
one would be almost impossible. So, GIT works out pretty well because each
copy of the GIT repository has a gatekeeper who is responsible for that
revision. For example, if I want to make a change in Linux, I could checkout
the root copy of the repository and try to submit a change, but the change
will simply be rejected because I am not a trusted contributor at that
level.

Instead, I find a friend who is working on Linux and check out from his copy
of the repository. My friend will accept my changes and then submit their
changes with mine to the copy of the repository they used. As this gets
filtered up the line, my change might eventually make it into the official
release.

However, I find major problems with GIT when you are working in a commercial
environment. First of all, each copy of the GIT repository requires a
particular person to be the gatekeeper whether or not to accept changes in
their copy. That means that person is responsible for merging all changes
into that copy of the repository. The last place which used Git made me, the
SCM who is not a developer, the person responsible for handling all the
merging since the developers didn't want to do it themselves. Hilarity
ensued.

Another problem is what I call the ClearCase problem. In ClearCase, each
developer gets their own branch for development, and the developers like it
because they can easily make their changes without worrying about the
constant updates to the source code other developers make. Unfortunately, it
is very easy to forget to submit your work on a regular basis. Developers
started changing bigger and bigger chunks of code and then submitting those
changes right before a release deadline. Forcing all developers to work on
the same branch makes each developer more careful about their code, and
their changes. Add a continuous build engine, mix, and serve.

This ClearCase problem isn't an issue with the open source because there is
no real deadline pressure. In GIT, if someone is making a particular change,
doesn't keep up to date with the rest of the changes in the source tree,
then submits their changes, that changes can easily be rejected. When you
promised paying customers that your software will have feature "X" by the
end of the month, and the person who is working on feature "X" submits the
changes on the 27th of the month, you have to accept their changes.

I can see why GIT is popular and why Linux uses it, but I don't see a
distributed repository as the bright shiny future of revision control.

-- 
David Weintraub
qazwart_at_gmail.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2396151
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].