bug-gnubg
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AW: Development - an outsider’s perspective


From: Øystein Schønning-Johansen
Subject: Re: AW: Development - an outsider’s perspective
Date: Tue, 3 Jan 2023 10:31:51 +0100

Happy new year to all!

I agree that converting from cvs to git is a good idea. However, GitHub as the git repo provider may not be the best, and I think that should be discussed. (I do love GitHub, and I use it for all my personal projects, but there are some issues ... )

What I rather suggest is that we take a chat with savannah hackers. There must be other GNU projects that also have the desire to convert from cvs to git.

Best regards,
-Øystein

PS:
There's a lot of things I would love to do with the code base:
- Move to git
- Get rid of Hungarian naming variables and have better abstract types. Like there should be a type for board position, move, dice roll, etc.
- Separate the engine from the GUI (This s a huge task that require a lot of redesign)
- Get the GUI part compatible to GTK4 (This is easier if the above point is done)
- (lot's of other stuff)


tir. 3. jan. 2023 kl. 00:17 skrev Philippe Michel <philippe.michel7@free.fr>:
Hello Carsten,

I agree that using git would have many advantages. I had tried to
convert the repository (with cvs-fast-export) some time ago, but I'm not
too familiar with git and wasn't sure the result was right. The
documentation of cvs-fast-export gives a lot of warnings... On the other
hand the structure of the gnubg repository seems relatively simple: it
must have been 10 years or so that branches have not been used.

> About a migration to git: I tried two different tools with different results:
>
> a) cvs-fast-export, from https://gitlab.com/esr/cvs-fast-export
> b) cvs2git, part of cvs2svn, from https://github.com/mhagger/cvs2svn

> For a) you can see the result here:
> https://github.com/carsten-wenderdel/gnubg-fast-export

> - When converting both modules “gnubg” and “gnubg-nn” it moved the
> latter as a folder “nn” into the “gnubg” folder. That’s strange, but
> if those two modules/folders don’t reference each other, it shouldn’t
> harm. Also once in git, those folders can be moved without losing the
> history.

I converted the gnubg and gnubg-nn subdirectories in separate git repos.
This seemed more natural to have gnubg at the root of its repo.

> - It didn’t convert the tags properly. We could add tags manually, but
> still not good.

I don't see anything wrong at your github URL. The tags are present and
switching to one of them seems to show the right version of the files.

FWIW, what I did was :

rsync -av rsync://cvs.savannah.gnu.org/sources/gnubg/ gnubg-full-cvs/

cvsconvert -v -A authormap gnubg-full-cvs/gnubg

Then, in the created gnubg-full-cvs-gnubg-nn-git directory :

git gc --aggressive
git checkout master

At this point "git tag" shows the tags, "git checkout <some tag>" shows
the right files as far as I can see.

> Another open question: As “author” git would always use the user
> handle of the CVS committer. Do we want to have full name and email
> address instead? That’s possible if those tools would be fed with a
> file mapping those user handles (like “plm”) to full name / email
> address.
> As with CVS committer and author often were different people this
> might not be wanted though.

As the command I gave earlier show, I think it would be preferable to
have real names and adresses rather than savannah handles, but I don't
understand your last sentence. I think most of the time the committer
was the author of the change ; the latter may sometimes have been an
occasionnal contributor who may or not have been credited in the
comment, but using names and adresses would allow to do it more
systematically in the future, wouldn't it ?

> Still hoping to hear more opinions!

What puzzles me most in your suggestions is this :

> > So my suggestion is to first move the repository to GitHub.

Moving to gitub doesn't seem especially urgent to me. First task would
be ensure that the conversion to a git repo is done right. Your report
shows some uncertainties in this regard.

Then I would find it natural to clone it to savannah (and, I suppose,
have the cvs repository made unavailable or at least read-only). That
would already allow anyone interested to easily clone the repository
locally, to github, or elsewhere.

Only then could it be envisaged to move the reference origin (and
possibly everything else, bug reporting, binaries distribution, mailing
list) elsewhere.

I must be out of touch with the modern open source ecosystem but

> Some developers care about their contribution statistics on GitHub

came as a surprise to me.

A significant enough contribution to have one's name in a documentation,
readme, changelog? Great! Bug reports and occasionnal suggestions for
something I use? Obviously! But going in priority where there are
counters to inflate ???


reply via email to

[Prev in Thread] Current Thread [Next in Thread]