Menu
▾
▴
Re: Status update - version 5.2.2, cvs->git conversion, plans
|
From: Daniel J S. <dan...@ie...> - 2017-11-16 10:24:12
|
On 11/16/2017 12:17 AM, sfeam via gnuplot-beta wrote: > Version 5.2.2 > ============= > > A tarball for release 5.2.2 is now in the usual place on sf.net: > https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.2/ > This will be the last gnuplot release prepared from the CVS repository. > > Anything you commit to cvs between now and whenever sourceforge pulls > the plug on it will not make it into future gnuplot releases. > > cvs->git conversion > =================== > > A snapshot of the cvs repository from 04-November-2017 was converted > to git with the help of Eric S Raymond [Thanks!] > Since then we have been evaluating the state of the converted source tree. > At the moment there are two copies on sf.net, one slightly cleaner than > the other. A handful of commits have gone in to these, but it remains > true that the existing git content on sf.net may be wiped clean and > re-created from the 04-Nov-2017 snapshot if we find that there were > annoying but correctable errors from the previous conversion[s]. > So far the "correctable" part has been a sticking point. > > plans > ===== > > I will be travelling for most of the next month, so I would prefer that > we make a yes/no decision by next Monday (20 November) as to whether the > current converted code base is good enough to work with. If it is not, > then the repository is likely to remain volatile until at least the end > of the year. You'll be able to read from it, but if you make copies > you may have to rebase or re-clone if we do the entire conversion over > again. > > But really I think it all looks promising. > Not perfect but "good enough". I've sent a script file in a previous post that can be used to compare CVS versions to git versions, about two dozen of them. One can see precisely what the differences are (almost all log/RCSid related). I described in detail the major discrepancy I've found surrounding version 4.6.3 in a previous post. I've also pointed out in detail that the git repository goes out of synch with the CVS repository very early on. Rather than bringing branches in synch at the branch points, the best thing would be to bring the master branch in synch as early as possible. Retaining the early tags in git repository would have assisted in comparing earliest tagged versions between the repositories and identifying where the earliest differences are. (Just add to the list of files in the automated script file I sent previously.) I'm not sure where the notion that 3.7 branch series is corrupted and doesn't match a tarball is originating from. I'd prefer someone attach a diff file to illustrate the differences before discarding anything. Here's the clone that I have: [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = https://git.code.sf.net/p/gnuplot/git-main fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master and I've downloaded gnuplot-3.7.3.tar.gz from gnuplot's download site. What follows is the differences (all RCSid/Log details in the comments section, i.e., not important as the code itself is the same.): sebald@ ~/gnuplot/git_repository $ diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/ ~/src/gnuplot-3.7.3/ diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/docs/old/ChangeLog.old /home/sebald/src/gnuplot-3.7.3/docs/old/ChangeLog.old --- gnuplot-git/docs/old/ChangeLog.old 2017-11-11 14:34:39.319799009 -0600 +++ /home/sebald/src/gnuplot-3.7.3/docs/old/ChangeLog.old 1998-11-16 07:07:33.000000000 -0600 @@ -8,7 +8,10 @@ * working. This means that the revision numbers in the individual files * do not agree with the one in the log. I hope to fix this some time soon. * - * $Log: version.c,v $ + * $Log: ChangeLog.old,v $ + * Revision 1.1 1998/11/16 13:07:33 lhecking + * Moved from version.c. + * * * I have moved these entries from version.c. All future code changes * should be logged in ChangeLog. Lars Hecking diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/docs/old/makefile.r /home/sebald/src/gnuplot-3.7.3/docs/old/makefile.r --- gnuplot-git/docs/old/makefile.r 2017-11-16 03:19:23.971387193 -0600 +++ /home/sebald/src/gnuplot-3.7.3/docs/old/makefile.r 2002-01-26 12:55:02.000000000 -0600 @@ -1,7 +1,10 @@ -# $Id: makefile.r,v 1.1 1998/12/09 17:24:30 lhecking Exp $ +# $Id: makefile.r,v 1.1.2.1 2002/01/26 18:55:02 lhecking Exp $ # # $Log: makefile.r,v $ +# Revision 1.1.2.1 2002/01/26 18:55:02 lhecking +# Support for pdf and W3C Scalable Vector Graphics output. +# # Revision 1.1 1998/12/09 17:24:30 lhecking # Moved from ../.. # diff -ur '--exclude=.git' -I '\$[A-Z]*[a-z]*' gnuplot-git/docs/old/README.3p5 /home/sebald/src/gnuplot-3.7.3/docs/old/README.3p5 --- gnuplot-git/docs/old/README.3p5 2017-11-16 03:19:23.919387193 -0600 +++ /home/sebald/src/gnuplot-3.7.3/docs/old/README.3p5 1998-11-16 07:01:23.000000000 -0600 @@ -1,9 +1,12 @@ This is a bugfix to version 3.4. -# $Id: README.3p5,v 1.1 1993/09/27 17:07:30 alex Exp $ +# $Id: README.3p5,v 1.1 1998/11/16 13:01:23 lhecking Exp $ # # $Log: README.3p5,v $ +# Revision 1.1 1998/11/16 13:01:23 lhecking +# Moved from top level dir. +# # Revision 1.1 1993/09/27 17:07:30 alex # gnuplot 3.5 release # Only in gnuplot-git/: .gitignore > Questions > ========= > > I'm still learning how to rethink my work flow for git, so please > help me out. For instance, does it make any sense to continue > to maintain the ChangeLog file? So far I'm having little success in > keeping it in sync with the git commit messages. Is there some > tool to help with that, or is the normal practice with git to rely > only on the commit messages? I know you can dump a log of commits, > so I guess one possibility is to use that to update the ChangeLog every > now and then (1 month intervals? 6 months?) but not try to touch it > for every commit. Advice? That's possible, but after a month of using git you'll likely wonder, Why update a ChangeLog? Typing "git log | less" is just as easy as "less ChangeLog" and the git command works in all subdirectories. Keep the same format for the git log messages as you've been using for the ChangeLog, i.e., -> One line of "short-log" -> List of files that have changed, just like CVS ChangeLog entries After you are used to git, move the ChangeLog files to some subdirectory "historic_cvs" or something. The entries still apply to the history, and the ChangeLog files can be searched but in a more cumbersome way than using gitk/qgit/gitg funnel searching. If you are happy with just looking at the diffs in the ChangeLog for every commit in the git repository, then deleting the ChangeLogs from the master is fine too. Somehow I think it is better just tucking the ChangeLog files in some subfolder. You'll need to come up with a work flow that incorporates what tools you are used to, e.g., any special editor for looking at patch files, etc. Things to keep in mind. 1) Ask the people submitting patches, via their git tools to include the file change info in their log messages, using the existing git repository changesets as examples. 2) Code submitters will generate their changeset and extract it into a patch file, changeset header and all. 3) One option is to apply that patch to your local repository and test. If you feel the patch is good, then push to the canonical version. If it isn't quite ready, you'll have to learn how to reset your local copy (i.e., toss out the applied changeset). 4) Say you aren't quite happy with the code in the changeset, but it is close or you want to clean up the person's changeset log message. One option is to edit the changeset/patch file directly. Sometimes convenient, but sometimes not if it is a complex change. 5) The changeset file that people submit will look exactly like a typical patch file, except at the top will be extra git SHA, author info, log message, etc. in "comments" section. So, another option is to not import the submitter's changeset, but instead just use the normal "patch" command as you are used to. (You may need -p0 or -p1 in the patch command to get rid of that first level a/ and b/ that git puts in place.) Hit the reset button within git-gui, gitg or qgit, and you will then see the changes that the submitter is proposing. This then makes the workflow something very similar to the way you would go about your own changesets. But then you'll need to learn how to commit the submitters changes and supply the author info from the submitters patch file. 6) Remember all of this is local, so if you make a mistake only recognized after doing a commit, you can easily reset that commit back to the staged file status prior to the erroneous commit and redo with corrections. Or, you may discard all changes with "git checkout". Once you have one or more changesets that you are satisfied with locally, then use "git push" to put them in the canonical repository. 7) You are going to eventually run into cases in which the commit that you make and push to the canonical repository will conflict with some changeset that another developer pushed, e.g., you edited some of the same files and same code lines as another user. That is, the diff-hunks of the changesets interfere with one another. Git tries its best to merge, but sometimes it is confused and you'll have to manually tell git how to resolve conflicts. You'll need a merge tool for best visualization of exactly what's happening. KDE might have a merge tool already setup, or look for "meld" which is pretty nice. Dan |
