Re: RFC: Moving to github
Harald Kipp <[email protected]>
| Newsgroups | gmane.comp.hardware.microcontrollers.ethernut |
|---|---|
| Message-ID | <[email protected]> |
Uwe, On 22.07.2015 12:33, Uwe Bonnes wrote: > my mail what is worse with a svn-git setup from some days ago was > unanswered. Probably because I explained "Worst of both world" in that same email. It's mainly related to branching/merging. I'll try to explain it in more detail with other words. With Git I can fork a new public repository, change whatever I like, and, most important, I can easily fetch from and push to any other Git repository. This way I can freely cooperate with other developers. With SVN I have to do this via branches, which is more complicated and requires write access to the central repository. And, as we have had this in the past, avoiding lengthy discussions in the mailing list about how to implement a new feature, without any code ever appearing. SVN on the other hand offers an easy to handle revision mechanism, which makes maintaining release branches very comfortable. Example: Get the branch and cd into its directory with svn co branches/4.8 local48 cd local48 To see, which patches had been applied, use svn propget svn:mergeinfo which gives /branches/4.8:117-119 /trunk:203-204,316,322 Release branches must not add new features, only fixes are allowed. They need to be selected manually. To see, what hasn't been applied use svn mergeinfo --show-revs eligible ^/trunk which gives r205 r210-300 r327-r331 Now I can easily see, that last time I applied trunk:r322 and that I skipped anything before. Therefore I check r327-r329 only. Let's say, that r327-r328 turn out to be a new feature, which I don't want in this older release. With svn merge -r 329:331 svn commit I can merge the remaining fixes into the older 4.8 version. Just a few steps with simple revision numbers. With Git this might not become much harder (except those lengthy hashes instead of nice rev-numbers). But isn't it significantly more effort with git-svn? Do you have extra time to handle this? > SF offer: > - a definite official repo > - mailing list, bug tracker etc. > - a nice web page for the project > - a file repo > > I would miss those things a github What SF-services are you using beside the repository? Remember, you almost have the same project admin status like me. > Again: Is there any reason to move away from SF? Beside the need for setup > and care, we loose the points above. If we lose something we do not use, who cares? Regards, Harald P.S.: I'd appreciate, if "SF or Github" is not all the way mangled with "SVN to Git". _______________________________________________ http://lists.egnite.de/mailman/listinfo/en-nut-discussion