[En-Nut-Discussion] RFC: Moving to github

Harald Kipp harald.kipp at egnite.de
Wed Jul 22 19:14:13 CEST 2015


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



More information about the En-Nut-Discussion mailing list