Back then, it was. I ran all my projects on CVS. Then came along Git. I
tried to keep up with it, but had to quit for day-job reasons. When I came
back, Git was already so good that I switched almost everything over.
In my experience, the offline mode has been a huge advantage. For example,
in one project I work together with people from three different countries,
some of them traveling quite a bit. I sold Git solely on the
transportability. One of them was so happy that he switched over most of
his projects, too.
BTW that is the common way I see: once people get hooked, they not only
convert their existing projects to Git, but they use cvsimport a lot more,
and they start to manage configuration settings, documents, pictures, etc.
with Git, because it gives rise an easy backup mechanism.
Another difference between central and distributed operation I see is the
workflow. With Git, you can commit much more often. For example, when
working with Sourceforge's CVS (which _was_ comparable with the speed of
corporate SourceSafe repos), I would always think about committing (and
having a coffee), or rather combine these changes with the next ones.
Obviously, committing more often leads to a much nicer repository
structure, making it much easier to get into the code for new developers.
It also makes it easier to get at bugs. And because it is so much faster,
you can actually do a "git diff" before committing, to make sure that you
did not leave in that stupid debug statement.
This is a lousy argument, IMHO.
Why are forks bad? They are not. But if you "learnt" that merges are hard,
they are.
It is a pity that so many people were trained in CVS, and keep thinking
some of the lectures were true, when they are no longer.
Forks are good. In fact, we all "forked" with CVS as soon as we began
hacking. Everybody who claims to never have started over from a fresh
checkout, or from an "update -C"ed state, is probably lying, or a bad
developer. Thinking about it, I believe that the difference between
forking and branching is philosophical, not technical. You can always
merge a fork.
And the thing is, you would not start hacking on some obscure feature, if
that happened completely in the open, for fear of being accused a complete
moron.
With CVS, that meant that you tried to get at a stage where others could
see that it was worth doing, before committing. Which makes for monster
commits. ("The number of bugs is the _square_ of the number of changed
lines.") With Git, that problem is virtually not there.
I have to admit that I drive one of my projects "CVS" style, with SSH
accounts for all developers, who push into the same repo.
But that worked quite well up to now.
If I _had_ to restrict them, I'd probably do that by (temporarily)
assigning a release engineer, and setting up some hook scripts in all
repos. But I don't believe in restriction when it comes to creativity.
Not at all. I think the best example is kernel.org, where you find tons of
forks. IMHO it is really helping the benevolent dictator cave into the
consensus-based model, since forks can be preferred at any time. Hey, even
switching from one to another upstream is just a git-pull away!
Ciao,
Dscho
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
