Menu
▾
▴
gnuplot-beta
|
From: sfeam <sf...@us...> - 2017-10-07 18:32:08
|
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. I don't really care much where the repository lives, but unless the associated gnuplot web site, bug trackers, mailing lists, etc are also moved it would seem simplest to continue using SourceForge. If no one steps up, then I'm afraid gnuplot development will be offline indefinitely. I will try to put out a 5.2.1 release before the deadline so that at least the current state of development is captured. I'll also make and keep an rsync backup. Please feel free to contact me privately if you don't want to reply here, but everyone reading this has a stake in the project and is welcome to offer opinions, suggestions, or whatever help you can. Ethan ---------- Forwarded Message ---------- Subject: CVS support at SourceForge and Nov. 30 Date: Saturday, 07 October 2017, 16:20:47 From: SourceForge Support <cvs...@so...> Greetings project admin, We have been planning to discontinue CVS support here at SourceForge for several years now, and that time has finally arrived. Since your project is making use of CVS for your source version control, you should now convert your repository over to another version control system. The current plan is to stop allowing CVS commits by November 30th. To be able to continue making source code changes you’ll need to have your CVS repo converted by then. The ssh access method will stop working, but read-only access via both pserver, rsync, and interactive shell will continue to be available past the cutoff date (we haven’t determined if or when the read-only support will end). This means that you will have plenty of time to convert your data to a new SCM format, even well past the cutoff date. If you don’t have a particular SCM choice in mind, we recommend choosing Subversion (SVN) since it has a workflow that is most similar to that of CVS. You might also want to choose Git, which is very popular these days, though it does have a steeper learning curve compared to switching to Subversion. You can even give each one a try and keep the one you like best. Don’t be afraid to experiment. For information on how to convert your repository from CVS to SVN or Git, visit the following web page: https://sourceforge.net/p/forge/documentation/CVS/ The page also documents the rsync backup method. We hope that your conversion goes smoothly. You can let us know if you run into any issues by replying to this email. Sincerely, SourceForge Support ----------------------------------------- |
|
From: Achim G. <Str...@ne...> - 2017-10-07 19:25:34
|
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). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves |
|
From: Daniel J S. <dan...@ie...> - 2017-10-07 21:05:22
|
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. Can you point to some examples of strange commits in this record to give us an idea? 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. 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. 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) Dan |
|
From: Mojca M. <moj...@gm...> - 2017-10-07 23:05:53
|
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) - 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. > 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). > 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. 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. Mojca #---------------------------- export DIR=$PWD export GP_CVS=$DIR/cvs/gnuplot/gnuplot mkdir -p $DIR/cvs mkdir -p $DIR/git rsync -aO --delete rsync://gnuplot.cvs.sourceforge.net/cvsroot/gnuplot/ $DIR/cvs/gnuplot cd $DIR/cvs/gnuplot/gnuplot chmod 755 missing,v config/djconfig.sh,v # set 644 to all non-executable files find . ! -perm /111 -type f -exec chmod 644 {} \; # set 755 to all executable files find . -perm 111 -type f -exec chmod 755 {} \; # remove pdffigures.tex (always complaining) # rm docs/pdffigures.tex,v cd $DIR # update from CVS git cvsimport -C $DIR/git/gnuplot.git -p x -d $DIR/cvs/gnuplot gnuplot # push any changes back to github cd $DIR/git/gnuplot.git git push -q github --all #git push github --tags |
|
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 |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-08 13:31:15
|
Am 08.10.2017 um 02:15 schrieb Daniel J Sebald: > On 10/07/2017 06:05 PM, Mojca Miklavec wrote: >> I decided to delete "missing" and "config/djconfig.sh" on purpose >> because I had problems whenever I tried to build gnuplot. For "missing" that might make some sense, since that file should never have been checked in to begin with --- it's supposed to be supplied by automake. But I cannot imagine how a script used only to build gnuplot for MS-DOS could ever, possibly disrupt operations on other platforms, where it will never be used for anything. >> 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? The tools offered by Eric S. Raymond do this automatically. They build .gitignore files to track the .cvsignore changes fully, including entries to make git ignore all those files that CVS ignores by default. >> 1.) Wrong date extraction for $Id fields That should solve itself as we remove the $Id entries from the source --- that's if we do go for git instead of SVN. >> 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. This is mainly a problem only for your current situation, where CVS is the master repository, and git only used to track it. What we're up to now is to make a git repository that's to be come the master itself. >> 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. The problem goes deeper than that. There is, ultimately, no such thing as a multi-file commit in CVS (i.e. no "change sets"). Even a single client-side invocation of 'cvs ci' is to the server just a loose sequence of individual file commits that just happen to be close in time, and with the same check-in description. Tools try to stitch those sequences back together again, but they cannot be perfet. And that's before you come to users or cvs clients who, for whatever reason, really do perform multiple check-ins one by one even if they do form a coherent group. >> 4.) If one deletes a folder in CVS, the files are probably gone >> forever and one doesn't get them in conversion. The files are still there in the CVS archive. There is, e.g., a folder doc/Attic/ps/Attic in the archive that holds the deleted contents of the deleted folder doc/ps. At least one of the tools on offer says it cannot use the contents of that folder, though. >> 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). I think that means the transformation really has to be done in a case-sensitive environment; probably Linux. We shouldn't accept lossy conversion if at all avoidable. > 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. Oh hell no. Turning all 1.7 MB of ChangeLog in to a single gargantuan log message would serve no purpose other than to annoy casual viewers. If we can't get ChangeLog mapped into the check-in messages entry by entry, then it has to stay out of there. ChangeLog entries and check-in comments are, by design, separate documentation streams, serving different purposes. Check-in messages are to keep others appraised of what a change is about, whereas ChangeLog is for looking up details during the work, without having to ask the server all the time. Sometimes a single ChangeLog entry will cover multiple changesets (because a single person checked in multiple changes in a single day), sometimes a single changeset will affect multiple ChangeLog entries (e.g. if a previous entry was corrected later). ChangeLog entries are supposed to be more detailed, mentioning exact locations of changes, and describing what exactly was changed, in which files, and how. Check-in comments, OTOH, are usually kept short, to the point of terseness. Most are a single line, and they only describe what the change was for, but not how it was achieved. Git users advocate a similar use by splitting a commit message into a single-line summary (equivalent to typical CVS check-in comments), and the longer description below that, after a blank line. So if ChangeLog entries can be moved into the log, they could become the bottom part of individual log entries. If they can't, so be it. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-09 01:55:04
|
On 10/08/2017 08:31 AM, Hans-Bernhard Bröker wrote:
> Am 08.10.2017 um 02:15 schrieb Daniel J Sebald:
>> On 10/07/2017 06:05 PM, Mojca Miklavec wrote:
[snip]
> Git users advocate a similar use by splitting a commit message into a
> single-line summary (equivalent to typical CVS check-in comments), and
> the longer description below that, after a blank line. So if ChangeLog
> entries can be moved into the log, they could become the bottom part of
> individual log entries. If they can't, so be it.
The message is actually sort of there already via this cvsimport
conversion. I understand now that the CVS is file-atomic changes and
cvsimport is looking for groups of changes with very near the same time
stamp, but it seems for the most part cvsimport is associating the
change to ChangeLog with the pertinent group of changes. For example,
here is the first diff hunk of the most recent changeset in the test
repository:
sebald@ ~/gnuplot/test_repository/gnuplot $ git diff 1455f9768f8 0a3035e39a1
diff --git a/ChangeLog b/ChangeLog
index 45b8ac3..bd497d8 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,14 @@
+2017-10-06 Hhhh-Bbbb <xxx...@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
+
2017-10-06 Bbbb Mmmm <xxx...@xx...>
* config/mingw/Makefile: Add helpfiles to "all" target, including
If one looks at the repository in a viewer like gitg, the added lines
are color coded. Given that ChangeLog is alphabetically often the first
file, one ostensibly sees short-description/detailed-file-changes next
to one another in the repository viewer.
I agree with the advocated format: a one line short description followed
by a starred (*) list of files, then colon (:) and brief description of
what change in the file. (Pagers know how to color code that format.)
The descriptions have to have enough detail and key words to be useful;
not something like, "Changed some code that was bad". People might find
it a pain to write a detailed message, but there is a non-obvious
benefit to writing the changeset message. Looking at staged diff-hunks
to be checked in while writing the message forces one to think a bit
more and catches a lot of bugs and less-than-optimal constructs (for me
anyway). As I see it, writing the message results in better quality
changesets.
Dan
|
|
From: Bastian M. <bma...@we...> - 2017-10-07 20:04:32
|
Hello Ethan, In the past we had a few discussions on migrating away from CVS on the list - with different opinions on Git, Hg, or Subversion. Personally, I am not unhappy about the end of CVS support by SF, but I hardly have experience with repository conversion myself. Eric S. Raymond and Allin Cottrel kindly offered help to convert about two years ago. I am attaching a copy of one of their emails below. Bastian > -----Ursprüngliche Nachricht----- > Von: Eric S. Raymond [mailto:es...@th...] > Gesendet: Montag, 23. November 2015 23:25 > An: Allin Cottrell <cot...@wf...> > Cc: gnu...@li... > Betreff: Re: CVS woes > > Allin Cottrell <cot...@wf...>: > > Any plans for gnuplot to migrate to git? That seems to be _much_ > > better supported at sourceforge. I recently converted gretl > > (econometrics software on sourceforge) from CVS to git and it has been > > trouble-free since. If there's interest I can send my recipe for the > > transition. (There are several "how-to"s out there, but they're not > > all up to date.) > > I still lurk on this list because I offered to do a git conversion a couple years > back. I'm a former GNUPlot contributor and now maintain cvs-fast-export; I'm > the author of one of those how-tos. > > The maintainers weren't interested, last time. We'll see if anything has > changed. It should; in 2015 still using CVS has gone beyond quaint and retro > into embarrassing, do-you-never-want-to-have-new-contributors > territory. > -- > <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> > > -----Ursprüngliche Nachricht----- > Von: sfeam via gnuplot-beta [mailto:gnu...@li...] > Gesendet: Samstag, 7. Oktober 2017 20:31 > An: gnu...@li... > Betreff: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30) > > 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. > > I don't really care much where the repository lives, but unless the associated > gnuplot web site, bug trackers, mailing lists, etc are also moved it would seem > simplest to continue using SourceForge. > > If no one steps up, then I'm afraid gnuplot development will be offline > indefinitely. I will try to put out a 5.2.1 release before the deadline so > that at least the current state of development is captured. > I'll also make and keep an rsync backup. > > Please feel free to contact me privately if you don't want to reply here, but > everyone reading this has a stake in the project and is welcome to offer > opinions, suggestions, or whatever help you can. > > Ethan > > ---------- Forwarded Message ---------- > > Subject: CVS support at SourceForge and Nov. 30 > Date: Saturday, 07 October 2017, 16:20:47 > From: SourceForge Support <cvs...@so...> > > Greetings project admin, > > We have been planning to discontinue CVS support here at SourceForge for > several years now, and that time has finally arrived. Since your project is > making use of CVS for your source version control, you should now convert your > repository over to another version control system. > > The current plan is to stop allowing CVS commits by November 30th. To be able > to continue making source code changes you’ll need to have your CVS repo > converted by then. The ssh access method will stop working, but read-only > access via both pserver, rsync, and interactive shell will continue to be available > past the cutoff date (we haven’t determined if or when the read-only support > will end). This means that you will have plenty of time to convert your data to a > new SCM format, even well past the cutoff date. > > If you don’t have a particular SCM choice in mind, we recommend choosing > Subversion (SVN) since it has a workflow that is most similar to that of CVS. You > might also want to choose Git, which is very popular these days, though it does > have a steeper learning curve compared to switching to Subversion. You can > even give each one a try and keep the one you like best. Don’t be afraid to > experiment. > > For information on how to convert your repository from CVS to SVN or Git, visit > the following web page: https://sourceforge.net/p/forge/documentation/CVS/ > > The page also documents the rsync backup method. > > We hope that your conversion goes smoothly. You can let us know if you run > into any issues by replying to this email. > > Sincerely, > > SourceForge Support > > ----------------------------------------- > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most engaging > tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Allin C. <cot...@wf...> - 2017-10-07 20:33:32
|
On Sat, 7 Oct 2017, Bastian Märkisch wrote: > Hello Ethan, > > In the past we had a few discussions on migrating away from CVS on > the list - with different opinions on Git, Hg, or Subversion. > Personally, I am not unhappy about the end of CVS support by SF, > but I hardly have experience with repository conversion myself. > > Eric S. Raymond and Allin Cottrel kindly offered help to convert > about two years ago. I am attaching a copy of one of their emails > below. My offer of help still stands (and I do have fairly recent successful experience with CVS -> git at sourceforge), but if Mr Raymond's also still stands his expertise in this sort of thing greatly exceeds mine. Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2017-10-07 20:08:36
|
On 10/07/2017 01:30 PM, sfeam via gnuplot-beta wrote: > 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. First, building the git repository sans change history is simple. Just get a fresh CVS checkout and build a git repository from scratch. So there's that option to fall back on. One big question is whether there is a simple way to take the whole CVS data base and convert all the change history into a git repository with associated changesets. I think we've discussed before that the ChangeLog contents probably can't be sliced and diced into all the associated changesets--would have been nice, but at least we'll keep the ChangeLog file. [Or, for someone interested in taking on the transfer, I'll write below something that could be done.] There will no longer be a ChangeLog file. Instead all the per-changeset comments will be inherent in the changeset itself. That means that the person writing the changeset also writes the comments similar to the format used in ChangeLog then exports the whole changeset as a diff-file which has the comment at the top. That can be edited by the maintainers and the pushed into the canonical repository. That actually can save maintainers a lot of work. You'll like git (or mercurial), though, once used to it. It's not too difficult to use if utilizing only the simple commands, or working with the repository via gitg or something similar is easy. But the diff tools and so on are much nicer than CVS. Another question is SourceForge's support for an HTML interface to the git repository. It's nice to have an HTML-viewable log of what's going on rather than have to pull all the latest changesets. Do maintainers want to go all out with pull-requests, etc.? Probably not, seeing as changes are sort of funneled down to a few people for review, rather than having a whole large team of players committing to the canonical repository. So, in that respect, SourceForge's support for pull-requests isn't that critical. Just a nice log and difference viewer is good. Staying with SourceForge is fine with me, if that criteria can be met. For any volunteer thinking about taking on the transference from CVS to git, my idea of what to do with the old ChangeLog is the following: The nice thing about git changesets is that one can do git log and then use the usual unix-like vi searching through the pager-log it generates. I wonder if as the very first changeset in the new repository (or even if there is a comment associated with the "git init" process) that we take the whole contents of the current ChangeLog and copy that as the initial comment. It will be big, but at least we can then do a git log and that whole long ChangeLog history is right there at hand for searching purposes along with all the change-logs that come after it. Dan > So I am making a plea for a volunteer to step up and transfer the project files > to some git repository. > > I don't really care much where the repository lives, but unless the associated > gnuplot web site, bug trackers, mailing lists, etc are also moved it would > seem simplest to continue using SourceForge. > > If no one steps up, then I'm afraid gnuplot development will be offline > indefinitely. I will try to put out a 5.2.1 release before the deadline so > that at least the current state of development is captured. > I'll also make and keep an rsync backup. > > Please feel free to contact me privately if you don't want to reply here, > but everyone reading this has a stake in the project and is welcome > to offer opinions, suggestions, or whatever help you can. > > Ethan > > ---------- Forwarded Message ---------- > > Subject: CVS support at SourceForge and Nov. 30 > Date: Saturday, 07 October 2017, 16:20:47 > From: SourceForge Support <cvs...@so...> > > Greetings project admin, > > We have been planning to discontinue CVS support here at SourceForge for several years now, and that time has finally arrived. Since your project is making use of CVS for your source version control, you should now convert your repository over to another version control system. > > The current plan is to stop allowing CVS commits by November 30th. To be able to continue making source code changes you’ll need to have your CVS repo converted by then. The ssh access method will stop working, but read-only access via both pserver, rsync, and interactive shell will continue to be available past the cutoff date (we haven’t determined if or when the read-only support will end). This means that you will have plenty of time to convert your data to a new SCM format, even well past the cutoff date. > > If you don’t have a particular SCM choice in mind, we recommend choosing Subversion (SVN) since it has a workflow that is most similar to that of CVS. You might also want to choose Git, which is very popular these days, though it does have a steeper learning curve compared to switching to Subversion. You can even give each one a try and keep the one you like best. Don’t be afraid to experiment. > > For information on how to convert your repository from CVS to SVN or Git, visit the following web page: https://sourceforge.net/p/forge/documentation/CVS/ > > The page also documents the rsync backup method. > > We hope that your conversion goes smoothly. You can let us know if you run into any issues by replying to this email. > > Sincerely, > > SourceForge Support > > ----------------------------------------- > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Daniel J S. <dan...@ie...> - 2017-10-07 20:20:18
|
On 10/07/2017 02:32 PM, Daniel J Sebald wrote: > For any volunteer thinking about taking on the transference from CVS to > git, my idea of what to do with the old ChangeLog is the following: The > nice thing about git changesets is that one can do > > git log > > and then use the usual unix-like vi searching through the pager-log it > generates. I wonder if as the very first changeset in the new > repository (or even if there is a comment associated with the "git init" > process) that we take the whole contents of the current ChangeLog and > copy that as the initial comment. It will be big, but at least we can > then do a > > git log > > and that whole long ChangeLog history is right there at hand for > searching purposes along with all the change-logs that come after it. I would add that if the CVS-to-git conversion process means that we couldn't put the ChangeLog's comment as the first entry, I think we could branch from the initial repository with a changeset consisting of the ChangeLog history as the first comment, and then rebase all the changesets onto that branch. Maybe it doesn't make a difference where the ChangeLog contents appears in the log if all the comments for individual CVS changes are empty. Dan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-07 20:22:46
|
Am 07.10.2017 um 20:30 schrieb sfeam via gnuplot-beta: > So I am making a plea for a volunteer to step up and transfer the project files > to some git repository. Going all the way to Git might not be optimal for us. SVN is closer in philosophy to CVS. But as the primary maintainer for the last several years, that decision is clearly yours. > I don't really care much where the repository lives, but unless the associated > gnuplot web site, bug trackers, mailing lists, etc are also moved it would > seem simplest to continue using SourceForge. I vote to keep it on SourceForge. They offer both SVN and git, and IMHO it makes sense to keep it all in one place. > If no one steps up, then I'm afraid gnuplot development will be offline > indefinitely. I'd hate to see that happen. Eric S. Raymond has offered (twice) to help us with such a repository move, but I fear this rather short notice by SF may overload his ability to help all affected projects in time. If that helps, I can offer to share the workload with Mr. Raymond, to whatever extent that even makes sense. I'll be transforming another (smaller) project myself, so I'll have to learn how this is done, anyway. I've already begun experimenting with the tools in question. |
|
From: Mojca M. <moj...@gm...> - 2017-10-09 07:33:28
|
On 7 October 2017 at 22:22, Hans-Bernhard Bröker wrote: > Am 07.10.2017 um 20:30 schrieb sfeam via gnuplot-beta: > >> So I am making a plea for a volunteer to step up and transfer the project >> files >> to some git repository. > > Going all the way to Git might not be optimal for us. SVN is closer in > philosophy to CVS. Each conversion from one technology to another is time consuming and lossy in some way or another. CVS is already "stone age" technology and has been deprecated and inherently broken in my point of view. For ages. SVN is at least not broken, it's still being actively developed, it still has its niche use and might be better for particular type of use(rs). But it's already declining and numerous projects migrate from subversion to GIT (or Hg). With current instability of sourceforge, another downtime might again mean inability to continue regular development for a few weeks (something that already happened in the past). With Git you can both keep committing locally and/or switch to a backup server location is seconds. And if someone really hates git, it's still possible to use the "subversion layer" locally (at least GitHub offers that functionality). While there was less incentive to migrate to another technology if gnuplot was using SVN at this moment, there's little point in replacing one dead technology with another one that's already in decline. To me that's like replacing a 56k modem with 1 Mbit ADSL when you have optic fiber in your backyard :) >> I don't really care much where the repository lives, but unless the >> associated >> gnuplot web site, bug trackers, mailing lists, etc are also moved it would >> seem simplest to continue using SourceForge. > > I vote to keep it on SourceForge. They offer both SVN and git, and IMHO it > makes sense to keep it all in one place. That's up to mainly Ethan to decide. I'm not a big fan of SourceForge and prefer any other hosting provider, but if the repo is in git, at least one can get a nice mirror at GitHub. SourceForge is very user-unfriendly as far as browsing commit history is concerned. The only thing that's missing on, say, GitHub, are the mailing lists, but the existing lists can stay. Here are some huge advantages of GitHub that I wanted to point out. - If someone without commit rights creates a pull request, all it takes is hitting a button to accept the changes (of course once you have tested them). - With a pull request, the changes don't get outdated as fast. When I submitted something to the existing bug tracker, it took 5 years to accept it. At any given moment inbetween the patch was most likely outdated and needed to be manually fixed in order to apply cleanly. With a pull request, git takes care of making sure that the patch can still be applied even if the files in question change in the meantime. - It is easy to set up Travis builds, so that gnuplot gets rebuilt on several machines after each commit and for each pull request. Then you can immediately see if a submitted patch breaks something. - You wanted to keep the info about the author of the patch. If you keep using existing tracker, you'll need to fix that info manually and many committers would forget to do it. With pull requests, you get the author info correct automatically. Of course there are other providers, not only GitHub, many of them much better than SF. Mojca |
|
From: Daniel J S. <dan...@ie...> - 2017-10-08 06:41:07
|
On 10/07/2017 02:32 PM, Daniel J Sebald wrote: > On 10/07/2017 01:30 PM, sfeam via gnuplot-beta wrote: [snip] > Another question is SourceForge's support for an HTML interface to the > git repository. It's nice to have an HTML-viewable log of what's going > on rather than have to pull all the latest changesets. Do maintainers > want to go all out with pull-requests, etc.? Probably not, seeing as > changes are sort of funneled down to a few people for review, rather > than having a whole large team of players committing to the canonical > repository. So, in that respect, SourceForge's support for > pull-requests isn't that critical. Just a nice log and difference > viewer is good. Staying with SourceForge is fine with me, if that > criteria can be met. Here are a couple examples of HTML interface to repositories on SourceForge; one SVN, one git: SVN https://sourceforge.net/p/skychart/code/3668/log/ git https://sourceforge.net/p/maxima/website/commit_browser Neither are the most elegant such interface I've seen, but the basic elements are there, i.e., a list of changes and a means to get the diff hunks for that change. SVN HTML actually looks a little better in the sense that it allows viewing diff hunks for all changed files at once, and git HTML seems kind of slow to load. Scrolling through all the changes is much faster than looking at diff hunks for only one file at a time for dozens of files. Dan |
|
From: Bastian M. <bma...@we...> - 2017-10-08 13:54:46
|
According to the DVCS migration HOWTO http://www.catb.org/~esr/reposurgeon/dvcs-migration-guide.html we need a list of committers. Please find below my first attempt on that. Commiter IDs are taken from the openhub summary https://www.openhub.net/p/gnuplot/contributors, full names and emails from the ChangeLog, and timezones are guesswork mostly. Please send additions or corrections either to this list or directly to me. Bastian -- amai = Alexander Mai <st0...@hr...> Europe/Berlin broeker = Hans-Bernhard Broeker <br...@ph...> Europe/Berlin cgaylord = Clark Gaylord <cga...@vt...> US/Eastern janert = Philipp K. Janert <ja...@ie...> US/Pacific joze = Johannes Zellner <joh...@ze...> juhaszp = Peter Juhasz <ju...@us...> lhecking = Lars Hecking <lhe...@us...> lhecking = Lars Hecking <lhe...@nm...> Europe/Dublin lodewyck = Jérôme Lodewyck <lod...@us...> markisch = Bastian Maerkisch <bma...@we...> Europe/Berlin mikulik = Petr Mikulik <mi...@ph...> Europe/Prague persquare = Per Persson <per...@ma...> sfeam = Ethan A Merritt <merritt@u.washington.edu> US/Pacific tlecomte = Timothee Lecomte <tim...@en...> Europe/Paris vanzandt = James R. Van Zandt <jr...@va...> vanzandt = James R. Van Zandt <jr...@de...> uid26705 = Petr Mikulik <mi...@ph...> uid93776 = Ethan A Merritt <merritt@u.washington.edu> > Gesendet: Samstag, 07. Oktober 2017 um 22:22 Uhr > Von: "Hans-Bernhard Bröker" <HBB...@t-...> > An: gnuplot-beta <gnu...@li...> > Betreff: Re: A plea for volunteers (Fwd: CVS support at SourceForge ends Nov. 30) > > Am 07.10.2017 um 20:30 schrieb sfeam via gnuplot-beta: > > > So I am making a plea for a volunteer to step up and transfer the project files > > to some git repository. > > Going all the way to Git might not be optimal for us. SVN is closer in > philosophy to CVS. But as the primary maintainer for the last several > years, that decision is clearly yours. > > > I don't really care much where the repository lives, but unless the associated > > gnuplot web site, bug trackers, mailing lists, etc are also moved it would > > seem simplest to continue using SourceForge. > > I vote to keep it on SourceForge. They offer both SVN and git, and IMHO > it makes sense to keep it all in one place. > > > If no one steps up, then I'm afraid gnuplot development will be offline > > indefinitely. > > I'd hate to see that happen. > > Eric S. Raymond has offered (twice) to help us with such a repository > move, but I fear this rather short notice by SF may overload his ability > to help all affected projects in time. If that helps, I can offer to > share the workload with Mr. Raymond, to whatever extent that even makes > sense. > > I'll be transforming another (smaller) project myself, so I'll have to > learn how this is done, anyway. I've already begun experimenting with > the tools in question. |
|
From: Allin C. <cot...@wf...> - 2017-10-08 14:49:44
|
On Sun, 8 Oct 2017, Daniel J Sebald wrote: > On 10/07/2017 02:32 PM, Daniel J Sebald wrote: >> On 10/07/2017 01:30 PM, sfeam via gnuplot-beta wrote: > [snip] >> Another question is SourceForge's support for an HTML interface to the git >> repository. It's nice to have an HTML-viewable log of what's going on >> rather than have to pull all the latest changesets. Do maintainers want to >> go all out with pull-requests, etc.? Probably not, seeing as changes are >> sort of funneled down to a few people for review, rather than having a >> whole large team of players committing to the canonical repository. So, in >> that respect, SourceForge's support for pull-requests isn't that critical. >> Just a nice log and difference viewer is good. Staying with SourceForge is >> fine with me, if that criteria can be met. > > Here are a couple examples of HTML interface to repositories on SourceForge; > one SVN, one git: > > SVN > https://sourceforge.net/p/skychart/code/3668/log/ > > git > https://sourceforge.net/p/maxima/website/commit_browser > > Neither are the most elegant such interface I've seen, but the basic elements > are there, i.e., a list of changes and a means to get the diff hunks for that > change. SVN HTML actually looks a little better in the sense that it allows > viewing diff hunks for all changed files at once [...] You get that in the HTML git viewer if you click on the commit ID -- if I'm understanding you right. (You see diff hunks for all files affecting by the given commit.) Allin |
|
From: Daniel J S. <dan...@ie...> - 2017-10-09 02:06:35
|
On 10/08/2017 09:49 AM, Allin Cottrell wrote: > On Sun, 8 Oct 2017, Daniel J Sebald wrote: > >> On 10/07/2017 02:32 PM, Daniel J Sebald wrote: >>> On 10/07/2017 01:30 PM, sfeam via gnuplot-beta wrote: >> [snip] >>> Another question is SourceForge's support for an HTML interface to >>> the git repository. It's nice to have an HTML-viewable log of what's >>> going on rather than have to pull all the latest changesets. Do >>> maintainers want to go all out with pull-requests, etc.? Probably >>> not, seeing as changes are sort of funneled down to a few people for >>> review, rather than having a whole large team of players committing >>> to the canonical repository. So, in that respect, SourceForge's >>> support for pull-requests isn't that critical. Just a nice log and >>> difference viewer is good. Staying with SourceForge is fine with me, >>> if that criteria can be met. >> >> Here are a couple examples of HTML interface to repositories on >> SourceForge; one SVN, one git: >> >> SVN >> https://sourceforge.net/p/skychart/code/3668/log/ >> >> git >> https://sourceforge.net/p/maxima/website/commit_browser >> >> Neither are the most elegant such interface I've seen, but the basic >> elements are there, i.e., a list of changes and a means to get the >> diff hunks for that change. SVN HTML actually looks a little better >> in the sense that it allows viewing diff hunks for all changed files >> at once [...] > > You get that in the HTML git viewer if you click on the commit ID -- if > I'm understanding you right. (You see diff hunks for all files affecting > by the given commit.) Ah, yes there it is, but where is a convenient commit ID? I can click on the Parent ID and the Child ID and get a whole list of diff hunks. But it would be nice if there were an ID for the current highlighted changeset in the--what looks to be--flash window list. Can you click on the ID at the front of the list of changesets? That doesn't seem to work for me; maybe my version of Flash isn't working properly. Dan |
|
From: Hans-Bernhard B. <HBB...@t-...> - 2017-10-08 18:02:27
|
Am 08.10.2017 um 01:05 schrieb Mojca Miklavec: > 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). Using Eric S. Raymond's reposurgeon and cvs2svn to experiment with, I found a further complication that's missing from that existing github mirror: the "faq" module in our CVS repository. This means we have two modules in our repository, causing tools to actually generate the "gnuplot" path component again, and later failing many of their comparisons because of it. E.g. reposurgeon's "make branchescompare" complains that none of the branches or tags of the generated git repository have the 'faq' directory. So: what are we to do with the "faq" module? |
|
From: sfeam <sf...@us...> - 2017-10-08 18:18:09
|
On Sunday, 08 October 2017 20:02:12 Hans-Bernhard Bröker wrote: > Am 08.10.2017 um 01:05 schrieb Mojca Miklavec: > > > 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). > > Using Eric S. Raymond's reposurgeon and cvs2svn to experiment with, I > found a further complication that's missing from that existing github > mirror: the "faq" module in our CVS repository. This means we have two > modules in our repository, causing tools to actually generate the > "gnuplot" path component again, and later failing many of their > comparisons because of it. > > E.g. reposurgeon's "make branchescompare" complains that none of the > branches or tags of the generated git repository have the 'faq' directory. > > So: what are we to do with the "faq" module? It's pretty horribly out of date, so dropping it altogether to be rewritten at some later date is an attractive, and simple, option. Keeping it in a separate module seems an unnecessary complication. Whether we keep the current document or trash it and start over, either way it could move to the docs directory. Ethan |
|
From: sfeam <sf...@us...> - 2017-10-09 03:48:11
|
On Sunday, 08 October 2017 15:54:36 Bastian Märkisch wrote: > According to the DVCS migration HOWTO http://www.catb.org/~esr/reposurgeon/dvcs-migration-guide.html > we need a list of committers. Please find below my first attempt on that. Commiter IDs > are taken from the openhub summary https://www.openhub.net/p/gnuplot/contributors, > full names and emails from the ChangeLog, and timezones are guesswork mostly. Please send > additions or corrections either to this list or directly to me. > > Bastian > > -- > amai = Alexander Mai <st0...@hr...> Europe/Berlin > broeker = Hans-Bernhard Broeker <br...@ph...> Europe/Berlin > cgaylord = Clark Gaylord <cga...@vt...> US/Eastern > janert = Philipp K. Janert <ja...@ie...> US/Pacific > joze = Johannes Zellner <joh...@ze...> > juhaszp = Peter Juhasz <ju...@us...> > lhecking = Lars Hecking <lhe...@us...> > lhecking = Lars Hecking <lhe...@nm...> Europe/Dublin > lodewyck = Jérôme Lodewyck <lod...@us...> > markisch = Bastian Maerkisch <bma...@we...> Europe/Berlin > mikulik = Petr Mikulik <mi...@ph...> Europe/Prague > persquare = Per Persson <per...@ma...> > sfeam = Ethan A Merritt <merritt@u.washington.edu> US/Pacific > tlecomte = Timothee Lecomte <tim...@en...> Europe/Paris > vanzandt = James R. Van Zandt <jr...@va...> > vanzandt = James R. Van Zandt <jr...@de...> > uid26705 = Petr Mikulik <mi...@ph...> > uid93776 = Ethan A Merritt <merritt@u.washington.edu> > Thanks. I have a question though. We have a much longer list of contributors (as opposed to committers) because the project workflow historically had a large number of contributors funneling contributions through a small number of people with cvs commit privilege. I found 168 unique contributors listed in the ChangeLog files, compared to the 14 committers in your list above. Will the names of the true contributors be lost in the conversion process? That would be sad. [list of Email addresses redacted, but I can send it privately if it will help] Ethan |
|
From: Mojca M. <moj...@gm...> - 2017-10-09 05:15:38
|
On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote:
>
> I have a question though.
> We have a much longer list of contributors (as opposed to committers) because
> the project workflow historically had a large number of contributors funneling
> contributions through a small number of people with cvs commit privilege.
>
> I found 168 unique contributors listed in the ChangeLog files,
> compared to the 14 committers in your list above.
> Will the names of the true contributors be lost in the conversion process?
> That would be sad.
They are actually "lost" is CVS already, while they are (and will)
still (be) in ChangeLog.
What one *can* do with cvs2git conversion is to start with something
that looks like a reasonable conversion already and then make a map
<commit-shasum> <author>
for all commits where the author doesn't match the committer. Then one
can run a script that changes the author of each individual commit.
Mojca
PS: w.r.t. the question of what could go wrong with my conversion,
this is what the "git cvsimport" complains about:
revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.117.2.7 of file src/mouse.c is tagged but not present
revision 1.31.2.1 of file src/datafile.h is tagged but not present
revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
revision 1.31.2.1 of file src/datafile.h is tagged but not present
revision 1.117.2.7 of file src/mouse.c is tagged but not present
revision 1.50.2.9 of file config/makefile.mgw is tagged but not present
revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.3 of file docs/pdffigures.tex is tagged but not present
revision 1.464.2.38 of file src/graphics.c is tagged but not present
revision 1.464.2.38 of file src/graphics.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
revision 1.29 of file src/contour.c is tagged but not present
Skipping #CVSPS_NO_BRANCH
|
|
From: sfeam <sf...@us...> - 2017-10-09 06:24:12
|
On Monday, 09 October 2017 07:15:29 Mojca Miklavec wrote: > On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote: > > > > I have a question though. > > We have a much longer list of contributors (as opposed to committers) because > > the project workflow historically had a large number of contributors funneling > > contributions through a small number of people with cvs commit privilege. > > > > I found 168 unique contributors listed in the ChangeLog files, > > compared to the 14 committers in your list above. > > Will the names of the true contributors be lost in the conversion process? > > That would be sad. > > They are actually "lost" is CVS already, while they are (and will) > still (be) in ChangeLog. True. So as long as the original commit dates are retained in some form, the modified files can still be mapped to the ChangeLog description and hence the original author. OK. Ethan > > What one *can* do with cvs2git conversion is to start with something > that looks like a reasonable conversion already and then make a map > > <commit-shasum> <author> > > for all commits where the author doesn't match the committer. Then one > can run a script that changes the author of each individual commit. > > Mojca > > > PS: w.r.t. the question of what could go wrong with my conversion, > this is what the "git cvsimport" complains about: > > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.117.2.7 of file src/mouse.c is tagged but not present > revision 1.31.2.1 of file src/datafile.h is tagged but not present > revision 1.50.2.9 of file config/makefile.mgw is tagged but not present > revision 1.31.2.1 of file src/datafile.h is tagged but not present > revision 1.117.2.7 of file src/mouse.c is tagged but not present > revision 1.50.2.9 of file config/makefile.mgw is tagged but not present > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.464.2.38 of file src/graphics.c is tagged but not present > revision 1.464.2.38 of file src/graphics.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > Skipping #CVSPS_NO_BRANCH |
|
From: Eric S. R. <es...@th...> - 2017-10-09 06:27:06
|
Mojca Miklavec <moj...@gm...>: > On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote: > > > > I have a question though. > > We have a much longer list of contributors (as opposed to committers) because > > the project workflow historically had a large number of contributors funneling > > contributions through a small number of people with cvs commit privilege. > > > > I found 168 unique contributors listed in the ChangeLog files, > > compared to the 14 committers in your list above. > > Will the names of the true contributors be lost in the conversion process? > > That would be sad. > > They are actually "lost" is CVS already, while they are (and will) > still (be) in ChangeLog. That is correct. > What one *can* do with cvs2git conversion is to start with something > that looks like a reasonable conversion already and then make a map > > <commit-shasum> <author> > > for all commits where the author doesn't match the committer. Then one > can run a script that changes the author of each individual commit. My tools can do something similar. The problem is making that map. Somebody would have to grovel through every single change file making a list of entries of the form <date> <author> <files> Possibly a script could be written to do this. I'd then have to write a Python extension of reposurgeon that would walk through the commit list looking for an exact match of file list and a rough match of date - as I previously noted, CVS dates aren't reliable. > PS: w.r.t. the question of what could go wrong with my conversion, > this is what the "git cvsimport" complains about: The git maintainers' conversion engine is seriously buggy and should not be trusted on any repository with a nontrivial branch structure. I've tried to get them to use cvs-fast-export, but there's an incremental- conversion feature they're attached to that their engine pretends to do. They're attached to the pretense and are willing to accept buggy conversions to get it. Yes, this is infuriating. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> My work is funded by the Internet Civil Engineering Institute: https://icei.org Please visit their site and donate: the civilization you save might be your own. |
|
From: Daniel J S. <dan...@ie...> - 2017-10-09 06:31:06
|
On 10/09/2017 12:15 AM, Mojca Miklavec wrote: > On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote: >> >> I have a question though. >> We have a much longer list of contributors (as opposed to committers) because >> the project workflow historically had a large number of contributors funneling >> contributions through a small number of people with cvs commit privilege. >> >> I found 168 unique contributors listed in the ChangeLog files, >> compared to the 14 committers in your list above. >> Will the names of the true contributors be lost in the conversion process? >> That would be sad. > > They are actually "lost" is CVS already, while they are (and will) > still (be) in ChangeLog. > > What one *can* do with cvs2git conversion is to start with something > that looks like a reasonable conversion already and then make a map > > <commit-shasum> <author> > > for all commits where the author doesn't match the committer. Then one > can run a script that changes the author of each individual commit. This is what I was wondering about, i.e., an iterative approach where it might not be correct on the first pass but then somehow run a script or program that cross-references comments and adds or removes author info to keep everything in sync. I thought that the git database was encoded such that changing authorship wouldn't be so easy unless there is a git command that does so. > Mojca > > > PS: w.r.t. the question of what could go wrong with my conversion, > this is what the "git cvsimport" complains about: > > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.117.2.7 of file src/mouse.c is tagged but not present > revision 1.31.2.1 of file src/datafile.h is tagged but not present > revision 1.50.2.9 of file config/makefile.mgw is tagged but not present > revision 1.31.2.1 of file src/datafile.h is tagged but not present > revision 1.117.2.7 of file src/mouse.c is tagged but not present > revision 1.50.2.9 of file config/makefile.mgw is tagged but not present > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.3 of file docs/pdffigures.tex is tagged but not present > revision 1.464.2.38 of file src/graphics.c is tagged but not present > revision 1.464.2.38 of file src/graphics.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > revision 1.29 of file src/contour.c is tagged but not present > Skipping #CVSPS_NO_BRANCH Hmmm, this probably comes about because of misalignment of changeset groupings and the converters revision count. That is, the CVS tag numbers are translated in a way that doesn't agree with the original file versions. Do all these complaints come at the very end? That is, is the last version of, say file src/graphics.c, 1.464.2.37? This makes me think that none of the tags after conversion will be reliable. That's a pretty crucial issue, i.e., the ability to reconstruct program versions older than the conversion date/time. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-10-09 07:03:40
|
On 10/09/2017 01:30 AM, Daniel J Sebald wrote: > On 10/09/2017 12:15 AM, Mojca Miklavec wrote: >> On 9 October 2017 at 05:46, sfeam via gnuplot-beta wrote: [snip] > This makes me think that none of the tags after conversion will be > reliable. That's a pretty crucial issue, i.e., the ability to > reconstruct program versions older than the conversion date/time. Maybe a script that retrieves a tag-name version from both the original CVS repository and the translated repository then does a diff between the two directories? That seems like something that can be automated. Any discrepancy has to fixed somehow, then rerun until all versions match file-by-file. Dan |
