Michael Sokolov skrev:
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.
Ok, so the necessary tracking of data seems to be in both. One might be
better that the other in some aspects and visa versa. I stand corrected.
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
With change/merge-tracking in both system, the important thing must be
that you do not have to throw the tracked information away before in you
attempt to get your changes into the main repository. You certainly
throw this information away when you create a dumb patch-file. Guess
that we could make it work, if just "outsiders" where allowed to make
branches in Apaches SVN - we are not :-) So I guess that is the main
bennefit of git. It allows for forks from the main repository to live
remote from the main repository - that is, I would be able to make a
fork from the Apache git-repository (github or not), a fork that "lives"
entirely on my system of servers. And when I want to forward changes
into Apache it can go from my forked repository into the main repository
(through upstreaming) without having to cross a border where the nice
change/merge-tracking is lost. Still pretty sure that the stuff for this
is all in git, but depeding on whether or not Apache would need access
to my local repository (containing my fork) in order for the upstream
from my repository to the Apache repository to be possible, when the
actual action of accepting the upstream has to be on the Apache side, I
dont know. With GitHub my repository would live the same place as
Apaches and then certainly it would be possible. But why the discussion?
Why not just GitHub?!
Regards, Per Steffensen
