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 <[email protected]
>:

> 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