On 06/08/2013 10:07, Jean-Pierre Flori wrote: > [snip helpful detail] Thanks JP, I will study how you work in the hope that I might get to love GIT!
However, with SVN it is much easier to manage the definitive MPIR than it appears to be with GIT. For example, I am the primary manager of the stuff in the directories build.vc<n>, and mpn/x86_64. In SVN I don't have to rely on anyone else to ensure that MPIR is fully up to date in respect of these directories - I just push my stuff to the SVN repository. But with GIT I have to tell Bill every time I want to change 'my stuff' in the definitive MPIR and hope that he has the time to fetch and merge this into his repository. Alternatively Bill has to constantly monitor my GIT repository for changes to 'my stuff' and merge it into his repository. Ans, as with the INTEL_COMPILER macro issue, how does Bill (or anyone else) know that I have fixed it? In contrast with SVN I just fix and commit it and its done! And, assuming that Bill is the MPIR manager, in order to maintain a definitive version of MPIR he has to either rely on us to tell him that he needs to take stuff from us or he has to constantly monitor what we are doing. And we have to rely on Bill to do this management work - work that is not even necessary with SVN! So I really don't see what benefits GIT has bought for MPIR when compared with SVN. Unless we can use GIT in an SVN like fashion with a central repository that we can all commit to, GIT just adds a management overhead that doesn't exist with SVN. Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
