Re: RFC: Moving to github

Uwe Bonnes <bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org>
Newsgroups gmane.comp.hardware.microcontrollers.ethernut
Message-ID <[email protected]>
>>>>> "Harald" == Harald Kipp <[email protected]> writes:

    Harald> 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.

    Harald> Probably because I explained "Worst of both world" in that same
    Harald> email.  It's mainly related to branching/merging. I'll try to
    Harald> explain it in more detail with other words.

    Harald> With Git I can fork a new public repository, change whatever I
    Harald> like, and, most important, I can easily fetch from and push to
    Harald> any other Git repository. This way I can freely cooperate with
    Harald> other developers. With SVN I have to do this via branches, which
    Harald> is more complicated and requires write access to the central
    Harald> repository. And, as we have had this in the past, avoiding
    Harald> lengthy discussions in the mailing list about how to implement a
    Harald> new feature, without any code ever appearing.

But what hinders you from using these functionality with git-svn based on an
"offical" SF NutOS? Nothing!

    Harald> SVN on the other hand offers an easy to handle revision
    Harald> mechanism, which makes maintaining release branches very
    Harald> comfortable. Example:

    Harald> Get the branch and cd into its directory with

    Harald>  svn co branches/4.8 local48 cd local48

    Harald> To see, which patches had been applied, use

    Harald>  svn propget svn:mergeinfo

    Harald> which gives

    Harald>  /branches/4.8:117-119 /trunk:203-204,316,322

    Harald> Release branches must not add new features, only fixes are
    Harald> allowed. They need to be selected manually. To see, what hasn't
    Harald> been applied use

    Harald>  svn mergeinfo --show-revs eligible ^/trunk

    Harald> which gives

    Harald>  r205 r210-300 r327-r331

    Harald> Now I can easily see, that last time I applied trunk:r322 and
    Harald> that I skipped anything before. Therefore I check r327-r329
    Harald> only. Let's say, that r327-r328 turn out to be a new feature,
    Harald> which I don't want in this older release. With

    Harald>  svn merge -r 329:331 svn commit

    Harald> I can merge the remaining fixes into the older 4.8 version.

Well, my git-svn clone from SF NutOS misses some parts. With the present
downtime, I can't update. But I am quite sure that all these information is
available with git-svn.

    Harald> Just a few steps with simple revision numbers. With Git this
    Harald> might not become much harder (except those lengthy hashes
    Harald> instead of nice rev-numbers). But isn't it significantly more
    Harald> effort with git-svn? Do you have extra time to handle this?

Working with git svn for quite some time now, I don't see the extra effort.

Bye
-- 
Uwe Bonnes                bon-1JbLm1bU5j5ZIx36JBfelj3+ndqKAYMe9FMPySWZwLkb1SvskN2V4Q@public.gmane.org

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
_______________________________________________
http://lists.egnite.de/mailman/listinfo/en-nut-discussion
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.