Git conversion: disposition of old branches and tags

[Manuel López-Ibáñez]

On 16/09/15 17:49, Paul_Koning@Dell.com wrote:
>
>> On Sep 16, 2015,@4:38 AM, Richard Biener <richard.guenther@gmail.com> wrote:
>>
>> On Tue, Sep 15, 2015@7:09 PM, Florian Weimer <fw@deneb.enyo.de> 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.