On 12/1/2012 7:59 AM, Per Steffensen wrote:
It is all about information - git has it, SVN doesnt. And my logical
sence tells me that is has to be git and not github!
:-) Now tell me that I am stupid :-)
This kind of information (merge tracking) has been in svn since 1.5 (see
http://subversion.apache.org/docs/release-notes/1.5.html#merge-tracking). I
believe this perception of SVN dates from its early days, when merging
was indeed much more difficult: you had to keep track of all the merges
you had done, to avoid doing them again, and it was a huge mess. That
has pretty much been sorted out now.
Now it seems to me that the main advantage about git/github is that it
doesn't create a strict boundary between committers and non-committers.
As a committer, the two systems are basically the same up to differences
in UI, convenience of tools, etc.
But for a non-committer, with SVN the situation is irritating if you
submit patches that you continue to use, but are not accepted (or not in
a timely way) into the main repository. In such a case, you either have
to abandon the use of source control (OUCH!), or you have to fork the
entire project and maintain your own repo, with no tools for integrating
with the main repo.
My understanding is that with git, you can maintain your own repo, and
you have tools for taking changes from upstream repos, and also that the
"pull request" mechanism may be more convenient than submitting
patches. So this sounds, on the whole, much more attractive for outside
contributors. I have to admit I've only fiddled with this a bit, so
this is mostly based on what I've read and heard: please "tell me that I
am stupid"!
-Mike
