Menu
▾
▴
Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30)
|
From: Daniel J S. <dan...@ie...> - 2017-10-08 00:15:59
|
On 10/07/2017 06:05 PM, Mojca Miklavec wrote: > On 7 October 2017 at 23:05, Daniel J Sebald wrote: >> On 10/07/2017 02:25 PM, Achim Gratz wrote: >>> >>> sfeam via gnuplot-beta writes: >>>> >>>> Well guys, it's been fun. >>>> >>>> SourceForge has announced that they will shut down CVS support next >>>> month. >>>> I have little time available to deal with this, and minimal prior >>>> experience with git. >>>> >>>> So I am making a plea for a volunteer to step up and transfer the >>>> project files >>>> to some git repository. >>> >>> >>> There's already an unofficial repository (not that I'd endorse GitHub): >>> https://github.com/gnuplot/gnuplot >>> >>> As noted on that page, this uses cvsimport to do the mirroring, which >>> sometimes produces somewhat strange commits on the Git side. You might >>> want to get in touch with Eric S. Raymond if you want the CVS repo >>> cleaned and converted with some more care into Git (he's done that >>> before for other projects). >> >> >> I did >> >> mkdir temp_repository; cd temp_repository >> git clone https://github.com/gnuplot/gnuplot.git >> cd gnuplot >> gitg >> >> and things look reasonable as far as change history, tags and branches. > > Some tags are missing, but that's easy to fix (I think I disabled that > because a removed a number of useless tags, but I'm no longer sure). > >> Can you point to some examples of strange commits in this record to give us >> an idea? > > I cannot remember all the details. > > I remember various problems I had and I made several attempts to > change the repository in the past after some new commits came in. The > script I use for conversion at the moment is at the bottom. The fact > that I need(ed?) to delete some files (docs/pdffigures.tex in > particular) is strange. > > I decided to delete "missing" and "config/djconfig.sh" on purpose > because I had problems whenever I tried to build gnuplot. > > I had to change quite some file permissions (otherwise git would > always complain about some changes in my local tree). > > Even if this conversion would serve as a starting point, here's still > a TODO list: > - "convert" .cvsignore to .gitignore (this could either be done > "properly" for all commits or just for the last commit) Properly for all commits sounds difficult. I suppose the two files have pretty much the same form, given no comment characters or anything are in .cvsignore; it's just a list of files. Could we somehow create a link from .gitignore to .cvsignore for older entries and then starting with the new entries remove the link and rename .cvsignore to .gitignore? Even if such a thing can't be done, no one is going to use the new repository retroactively in CVS for editing/developing purposes, so wouldn't have any use for .cvsignore. Moving .cvsignore to .gitignore as one of the first new changesets might do. > - remove all the expansion strings ($Id) > - collect a list of names with emails from contributors to the sources > (perhaps along with timezones) and replace cvs usernames and > timestamps with proper names and emails > > I can name a few other problems I had at various points, but I'm not > sure if any of those apply to my copy of gnuplot's repo. > 1.) Wrong date extraction for $Id fields > 2.) It's explicitly suggested that one should not use incremental > updates of the repository, but rather create a single conversion. I > don't know what consequences that might have. > 3.) I remember seeing the same cvs commit (which needed a couple of > minutes to be uploaded to the server) split in two git commits just > because of the varying timestamp. > 4.) If one deletes a folder in CVS, the files are probably gone > forever and one doesn't get them in conversion. > 5.) I had some issues with files that only differed in case and I got > "lossy conversion" (files lost) on my Mac (this conversion is done on > Linux though). > 6.) I forgot a "--delete" switch in rsync calls, so some files > persisted in the git repository even after being deleted from CVS. > 7.) Not sure if file permissions are ok. Under CVS they kept changing. > The expression I used tried to fix permissions, but not sure if that's > all correct. OK, you've got the lead so far. :-) Regarding 2, there should be no incremental CVS-to-git (SVN?) conversions. I suggest one conversion to a new repository, then it's new-repo-only from there on out. The normal process that has been used for CVS will be discontinued soon anyway, so even someone continuing with CVS offline means extra work of changing the process slightly. I would say, though, that once the conversion to a new repository is done that there be no new commits for a week. That way everyone will have a chance to get a local copy and experiment with their favorite tools and if someone discovers something not-so-good about the conversion it will give a chance to scrap the repository and redo it. >> I'm wondering now about my suggestion of putting all the ChangeLog files >> into a changelog comment so that it can be included in the >> >> git log >> >> command. The reason is that there are, in fact, entries for all the >> changesets (where they came from, I don't know, they don't exactly match the >> ChangeLog). So mixing those in with the equivalent ChangeLog comment might >> create a confusing duplication. > > While that can theoretically be done: who is going to do the work? See > also my next comment and a link to xkcd (to predict what happens > next). I don't think I explained that well enough. I didn't mean to do the work of slice-and-dice all the individual entries of ChangeLog.0 through ChaneLog.5 and ChangeLog. What I meant was that all the ChangeLog.0 through ChangeLog are concatenated into one big comment and that comment is the first entry of creating the new repository. So it might be something like the following just after conversion: > git log commit 0a3035e39a1f9402a474d0ea9300deac4cd9ef33 Author: bbbbbb <bbbbbb> Date: Fri Oct 6 18:35:09 2017 +0000 Use <sys/wait.h> if available. Provide centralized fall-back of WEXITSTATUS if <sys/wait.h> does not supply it. commit 1455f9768f84f061aade6a9d52c29dfd92f621db Author: mmmmmm <mmmmmm> Date: Fri Oct 6 07:52:24 2017 +0000 Add menu items to edit gnuplot.ini and wgnuplot.ini [...ETC...] commit 123865547396c309b593f0395cb0ef6fa552329a Author: cccccc <cccccc> Date: Sat Oct 7 01:02:03 2017 +0000 2017-10-06 bbbbbb <bbbbbb> * src/command.c: Move WEXITSTATUS fall-back definition away from here. * src/syscfg.h: Include <sys/wait.h>, if it exists. (WEXITSTATUS): Provide fall-back definition, if none in <sys/wait.h>. Move MS Windows specific replacement from command.c to here. * configure.ac: Add call to AC_HEADER_SYS_WAIT 2017-10-06 mmmmmm <mmmmmm> * config/mingw/Makefile: Add helpfiles to "all" target, including the japanese version. Remove helpfile from default target. * config/mingw/Makefile: Default to Mingw-w64 and Direct2D v1.1. Note that building using Mingw32 currently does not work anyway due to missing headers libraries for newer Windows APIs. [...BIG LONG COMMIT MESSAGE...] 1998-04-09 hhhhhh <hhhhhh> * ChangeLog: New file. * gplt_x11.c (prepare_plot): Remove unused definition term_icon[10]. * set.c (set_arrow, set_linestyle): Replace aggregate initialisation for non-ANSI compilers. * Makefile.in: General cleanup. Add full support for GNU auto* tools. * missing: New file required for full GNU auto* tools support. Taken from automake 1.3 distribution. * acinclude.m4: New macros gp_PROG_CPP_STRINGIFY, taken from egcs, and AM_MISSING_PROG, from automake 1.3 distribution. Fixes in gp_CHECK_LIB_PATH and gp_CHECK_HEADER. * aclocal.m4: Regenerated from acinclude.m4 with aclocal. But note how the conversion-created comments are chronological, and the ChangeLog-created comment is chronological, but the two groups cover the same range, which would be confusing. In any case, my point is that the above would put all the history into one location, good for searching "git log". The ChangeLog files could then be excluded. Maybe something creative comes to mind. But it's not that much work to grep ChangeLog files so old history is always search-able in any case. The interesting observance of the repository is that the commit messages from ChangeLog are effectively sliced-and-diced. The reason is that the first diff-hunk of most changesets is the ChangeLog, i.e., the most-recently added comment. So, just look within the changeset diffs to get the pertinent ChangeLog message. That doesn't do anything for searching, however. >> Let's compare an example. The first in the >> list (via "git log") is >> >> commit 0a3035e39a1f9402a474d0ea9300deac4cd9ef33 >> Author: broxxxx <broxxxx> >> Date: Fri Oct 6 18:35:09 2017 +0000 >> >> Use <sys/wait.h> if available. >> Provide centralized fall-back of WEXITSTATUS if <sys/wait.h> does not >> supply it. >> >> whose changed files (via gitg) are >> >> ▶15 ChangeLog >> ▶4 configure.ac >> ▶6 src/command.c >> ▶20 src/syscfg.h >> >> While the entry in ChangeLog is as follows (I put 'x' in for email address >> to keep out of the content): >> >> 2017-10-06 xxxxxxxxx xxxxxxx <xx...@xx...> >> >> * src/command.c: Move WEXITSTATUS fall-back definition away from >> here. >> >> * src/syscfg.h: Include <sys/wait.h>, if it exists. >> (WEXITSTATUS): Provide fall-back definition, if none in >> <sys/wait.h>. Move MS Windows specific replacement from command.c >> to here. >> >> * configure.ac: Add call to AC_HEADER_SYS_WAIT >> >> Moving forward, the changeset comments should look more like the second >> example from the ChangeLog, as that highlights nicely in vi-based pagers. > > That's something that maintainers should strongly encourage (or > enforce?) among themselves. Yes, and I think that maintainers can touch-up the message associated with an exported changeset because it is an ASCII diff file (posted to SourceForge bug reports) with a little extra detail near the top. > Guidelines can be found under: > https://xkcd.com/1296/ > > For another project we tried to enforce another rule: keep the commit > history linear (unless branches are needed of course, but we try to > rebase pull requests instead of merging them and developers are > discouraged to do rebasing on master as well). > >> Currently in the translated repository, there are but a few users making >> commits. Going forward, the names of the user who creates the original >> changeset will end up in that Author location even though one of the >> maintainers pushes the changes to the repository when ready. (That name is >> a configuration parameter in a person's OS account via the hidden file >> .gitconfig) > > I like that anyway. Me too; just noting what maintainers should expect from a change to git. Dan |
