On 16/09/15 17:49, [email protected] wrote:
On Sep 16, 2015,@4:38 AM, Richard Biener <[email protected]> wrote:
On Tue, Sep 15, 2015@7:09 PM, Florian Weimer <[email protected]> wrote:
...
Unlike Subversion branch deletion, Git branch deletion is permanent,
so this might not be the best option.
We could have a 2nd git repository just containing deleted branches...
Agreed. A correctly designed source control system doesn't lose stuff, and the
fact that GIT fails that test in the case of branches is rather disturbing. If
the conversion would follow the GIT pattern, then the data it is going to
delete should be preserved elsewhere. (I suppose another answer might be to
keep the existing SVN server available read-only.)
I have refrained to speak up so far because I'm only a sporadic volunteer, thus
the convenience of the most prolific contributors is surely more important than
my own.
That said, given the complexity of the task, the fact that GIT can and will
lose data, that GIT is notably much more difficult to use than SVN, that SVN is
still maintained and improving, and that nowadays people who want to use GIT to
develop GCC are already doing it, what is the benefit of doing this conversion?
For those of us that very much prefer SVN than GIT, is there going to be a SVN
mirror like there is a GIT mirror right now? Is there an equivalent of git-svn
so we can continue with our SVN workflow?
My impression is that right now one can develop GCC with GIT or SVN (people are
submitting GIT patches all the time). After the conversion, only GIT will be
possible. Does this actually lower the entry barrier and will attract contributors?
Wouldn't all this effort be better spent in getting finally rid of CVS for
wwwdocs! If there was a SVN repository for wwwdocs, there could also be a GIT
mirror! Using GIT to commit to wwwdocs, wouldn't that be cool!
Cheers,
Manuel.
