Menu
▾
▴
gnuplot-beta
|
From: <es...@th...> - 2017-11-01 21:22:50
|
I've uploaded a fresh version of the conversion machinery where you can fetch it at wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz This version contains a new script, 'forcepush'. After running reconvert, you can run forcepush to nuke the the SourceForge git repository and replace it with the new conversion. (You must have Tcl and Expect installed for this to work.) The script does assume that your local username is the sane as your SourceForge one, because I'm 'esr' both places. If this is a problem for anyone, I'm sure we can modify the "nuke" and "forcepush" scripts to generalize them. The entire conversion and replacement process is now implemented and documented by the three scripts reconvert, nuke, and forcepush. It can be run at any time by anyone with the right SourceForge credentials. When doing repo conversions, I think it's important to show the work so all its assumptions are auditable. Also, we are now far enough along in the process that if I have to run off to focus exclusively on something else, somebody (most likely Dan Sebald or HBB) would be able to finish the job. So, this is my major deliverable; the rest is polishing. Things still to be done: 1. The EMPTIES file in the conversion tarball needs to have real log messages filled in for all those "*** empty log message ***" instances (but don't touch the Check-Text headers; those are a safety measure in case the commit dates drift, they should prevent clobbering of the comment text in nearby commits). A relatively easy way to do this: bring up EMPTIES in your favorite editor, then run gitk on a repo conversion. Looking at the diffs gitk displays per commit should make it easy to write a useful change comment. Note that the topmost text box in the lower half of the gitk display is for text search; if you type "*** empty log message ***" into it, you can use the up and down arrows off to the left to quickly move between empty comments. If all of you mail your EMPTIES changes back to me I'll take care of collating them. If the process runs long I might set up a public repo for the conversion stuff. 2. The final disposition of the 3.7.x branch needs to be decided. I think it is soaking up more effort than it is worth and should be dropped. I'm pretty sure Ethan agrees. We're almost done. Let's get this wrapped up. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> Where rights secured by the Constitution are involved, there can be no rule making or legislation which would abrogate them. -- Miranda vs. Arizona, 384 US 436 p. 491 |
|
From: Ethan A M. <sf...@us...> - 2017-11-02 00:12:11
|
On Wednesday, November 1, 2017 2:22:43 PM PDT Eric S. Raymond wrote: > I've uploaded a fresh version of the conversion machinery where you > can fetch it at > > wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz For me, reconvert dIes before finishing: reposurgeon% # The 4.0 branch Suggestions? > This version contains a new script, 'forcepush'. After running > reconvert, you can run forcepush to nuke the the SourceForge git > repository and replace it with the new conversion. (You must > have Tcl and Expect installed for this to work.) > > The script does assume that your local username is the sane as your > SourceForge one, because I'm 'esr' both places. If this is a > problem for anyone, I'm sure we can modify the "nuke" and "forcepush" > scripts to generalize them. > The entire conversion and replacement process is now implemented and > documented by the three scripts reconvert, nuke, and forcepush. It > can be run at any time by anyone with the right SourceForge > credentials. > > When doing repo conversions, I think it's important to show the work > so all its assumptions are auditable. Also, we are now far enough > along in the process that if I have to run off to focus exclusively on > something else, somebody (most likely Dan Sebald or HBB) would be able > to finish the job. Sounds good. > So, this is my major deliverable; the rest is polishing. Thanks. Really, thanks. > Things still to be done: > > 1. The EMPTIES file in the conversion tarball needs to have real log > messages filled in for all those "*** empty log message ***" instances > (but don't touch the Check-Text headers; those are a safety measure > in case the commit dates drift, they should prevent clobbering of the > comment text in nearby commits). > > A relatively easy way to do this: bring up EMPTIES in your favorite > editor, then run gitk on a repo conversion. Looking at the diffs > gitk displays per commit should make it easy to write a useful change > comment. Note that the topmost text box in the lower half of the > gitk display is for text search; if you type "*** empty log message > ***" into it, you can use the up and down arrows off to the left > to quickly move between empty comments. Not going to happen. If I had nothing to say about a commit at the time, I certainly don't have anything to say about it now. Is there a command to replace all of these with the Jedi mind trick "This is not the commit you are looking for" > If all of you mail your EMPTIES changes back to me I'll take care of > collating them. If the process runs long I might set up a > public repo for the conversion stuff. > > 2. The final disposition of the 3.7.x branch needs to be decided. I > think it is soaking up more effort than it is worth and should be > dropped. I'm pretty sure Ethan agrees. Yes. > We're almost done. Let's get this wrapped up. !! Ethan |
|
From: Ethan A M. <sf...@us...> - 2017-11-02 00:16:13
|
[trying again] My mailer ate the embedded traceback. On Wednesday, November 1, 2017 2:22:43 PM PDT Eric S. Raymond wrote: > I've uploaded a fresh version of the conversion machinery where you > can fetch it at > > wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz For me, reconvert dIes before finishing: reposurgeon% # The 4.0 branch reposurgeon% blob <FUBAR reposurgeon% /#include gp_time.h/ mailbox_in --create <NEWCOMMIT reposurgeon% /#include gp_time.h/ assign v40root --singleton Traceback (most recent call last): File "/usr/local/bin/reposurgeon", line 12393, in <module> main() File "/usr/local/bin/reposurgeon", line 12369, in main interactive() File "/usr/local/bin/reposurgeon", line 12358, in interactive interpreter.cmdloop() File "/usr/lib64/python2.7/cmd.py", line 141, in cmdloop line = self.precmd(line) File "/usr/local/bin/reposurgeon", line 7960, in precmd line = self.set_selection_set(line) File "/usr/local/bin/reposurgeon", line 7996, in set_selection_set if self.chosen().named(self.line): File "/usr/local/bin/reposurgeon", line 5750, in named key=len, reverse=True): # longest name first TypeError: object of type 'NoneType' has no len() Suggestions? > This version contains a new script, 'forcepush'. After running > reconvert, you can run forcepush to nuke the the SourceForge git > repository and replace it with the new conversion. (You must > have Tcl and Expect installed for this to work.) > > The script does assume that your local username is the sane as your > SourceForge one, because I'm 'esr' both places. If this is a > problem for anyone, I'm sure we can modify the "nuke" and "forcepush" > scripts to generalize them. > The entire conversion and replacement process is now implemented and > documented by the three scripts reconvert, nuke, and forcepush. It > can be run at any time by anyone with the right SourceForge > credentials. > > When doing repo conversions, I think it's important to show the work > so all its assumptions are auditable. Also, we are now far enough > along in the process that if I have to run off to focus exclusively on > something else, somebody (most likely Dan Sebald or HBB) would be able > to finish the job. Sounds good. > So, this is my major deliverable; the rest is polishing. Thanks. Really, thanks. > Things still to be done: > > 1. The EMPTIES file in the conversion tarball needs to have real log > messages filled in for all those "*** empty log message ***" instances > (but don't touch the Check-Text headers; those are a safety measure > in case the commit dates drift, they should prevent clobbering of the > comment text in nearby commits). > > A relatively easy way to do this: bring up EMPTIES in your favorite > editor, then run gitk on a repo conversion. Looking at the diffs > gitk displays per commit should make it easy to write a useful change > comment. Note that the topmost text box in the lower half of the > gitk display is for text search; if you type "*** empty log message > ***" into it, you can use the up and down arrows off to the left > to quickly move between empty comments. Not going to happen. If I had nothing to say about a commit at the time, I certainly don't have anything to say about it now. Is there a command to replace all of these with the Jedi mind trick "This is not the commit you are looking for" > If all of you mail your EMPTIES changes back to me I'll take care of > collating them. If the process runs long I might set up a > public repo for the conversion stuff. > > 2. The final disposition of the 3.7.x branch needs to be decided. I > think it is soaking up more effort than it is worth and should be > dropped. I'm pretty sure Ethan agrees. Yes. > We're almost done. Let's get this wrapped up. !! Ethan |
|
From: Eric S. R. <es...@th...> - 2017-11-02 19:08:20
|
Daniel J Sebald <dan...@ie...>: > I'm certain HBB would have no problems running the "construct_cvs2git_repo" > script, so I would propose that HBB and I take a look at that cvs2git result > over the course of a day (I'm already pretty confident) and declare "It's a > go", then Eric apply reposurgeon, restoring the items I removed from > ./reconvert that are of significance, then post the BETA release to > sourceforge. If everyone's then happy with the beta version, we'd be done. Sorry, not interested in going through yet another round of complications - unless you think you have fixes or at least good bug characterizations for cvs-fast-export or reposurgeon. Those I'd take. For me, messing with cvs2git has negative value. I can't use it in my standard conversion workflow, it makes the refinement cycles too slow. At some point, somebody in your crew is going to have to decide you'll stop screwing with the conversion and cut over to using it. You've long since overshot the amount of effort Ethan and I think is appropriate. Remember, wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz The last change I made was to clean up and parametrize the repository-nuker script. After three weeks of this I think it's time for me to bow out and pay attention to projects I've been neglecting. You guys gave a deadline to meet and a policy decision to make. -- <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-11-02 19:44:27
|
On 11/02/2017 02:08 PM, Eric S. Raymond wrote: > Daniel J Sebald <dan...@ie...>: >> I'm certain HBB would have no problems running the "construct_cvs2git_repo" >> script, so I would propose that HBB and I take a look at that cvs2git result >> over the course of a day (I'm already pretty confident) and declare "It's a >> go", then Eric apply reposurgeon, restoring the items I removed from >> ./reconvert that are of significance, then post the BETA release to >> sourceforge. If everyone's then happy with the beta version, we'd be done. > > Sorry, not interested in going through yet another round of > complications - unless you think you have fixes or at least good bug > characterizations for cvs-fast-export or reposurgeon. Those I'd take. > > For me, messing with cvs2git has negative value. I can't use it in my > standard conversion workflow, it makes the refinement cycles too slow. I wrote the script so that cvs2git is run once and the refinement cycle is running reposurgeon on that git repo. Perhaps things slow down because the source is a git repo as opposed to a cvs repo. I just finished a script that loops through every main CVS version name and diffs against the cvs2git+reposurgeon version. Things check out well. You did write git support into reposurgeon, and the combo does look nice. > At some point, somebody in your crew is going to have to decide you'll > stop screwing with the conversion and cut over to using it. You've > long since overshot the amount of effort Ethan and I think is > appropriate. > > Remember, > > wget http://www.catb.org/~esr/gnuplot-conversion.tar.gz > > The last change I made was to clean up and parametrize the repository-nuker > script. After three weeks of this I think it's time for me to bow out and > pay attention to projects I've been neglecting. You guys gave a deadline > to meet and a policy decision to make. Sorry Eric, I understand the frustration. My view, though, is that the source of time involved here is the fact cvs-fast-export results required so much manual grafting with reposurgeon. Had I known that was involved at the start, I would have suggested a pause. I myself had to dig through a lot of repo-conversions to assist in finding the correct branch-points. That said, my interest is balancing best conversion with reasonable effort. Ethan and HBB make the call here, as I see it. Thanks for your effort, Dan |
