On Sun, 31 May 2020 at 05:50, Craig Russell <apache....@gmail.com> wrote: > > > > > On May 30, 2020, at 6:21 PM, Sam Ruby <ru...@intertwingly.net> wrote: > > > > On Sat, May 30, 2020 at 3:08 PM Craig Russell <apache....@gmail.com > > <mailto:apache....@gmail.com>> wrote: > >> > >>> On May 29, 2020, at 3:17 AM, sebb <seb...@gmail.com> wrote: > >>> > >>> On Fri, 29 May 2020 at 00:49, Craig Russell <apache....@gmail.com> wrote: > >>>> > >>>> It looks like the best approach is to do the svn operations in two steps: > >>>> > >>>> 1. Update the svn foundation/members.txt based on the request (active, > >>>> emeritus, deceased) which is already in place. > >>>> 2. Perform the moves in svn documents > >>>> (emeritus-request-received>emeritus-request-rescinded, > >>>> emeritus-request-received->emeritus) which is new code to be written. > >>>> > >>>> These are two different svn repositories so they need to be in two svn > >>>> commits anyway. > >>> > >>> Not AFAIK. All the ASF documents are in the same SVN repo, which is > >>> rooted at: > >>> > >>> https://svn.apache.org/repos/private > >> > >> Thanks for that. I have each repository checked out and didn't think to > >> look to see if they shared a root. > >>> > >>>> And if the operations are retried on failure there is nothing to be done > >>>> to coordinate the two operations. Meanwhile, I am sure that I do not > >>>> know how to make the roster ruby/svn code retriable. > >>> > >>> A problem arises if the second request fails even after retry. > >>> There will be an outstanding change which has to be performed at some > >>> later stage. > >> > >> So if I understand you, we can do both updates with the same svn commit, > >> and should do so to avoid a partial commit that then needs to be corrected > >> by hand. > > > > Correct. In fact, if the commit is ONLY intended to have the move, it > > can be done via a single svn move command where both the source and > > destination are specified as URLs. > > In case of deceased, there is only the update of members.txt. Current code is > just fine. > > In case of emeritus, there are the update of members.txt and move of the > request from emeritus-requests-received to emeritus. This is the case where > I'd like to insert an svn command into the anonymous update function. > > In case of rescind, there is only the move of the request from > emeritus-requests-received to emeritus-requests-rescinded. In this case, > there is no need for the update function, just an svn command. > > > > http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.move.html > > <http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.move.html> > > I know svn and know how to use the mv command. What I don't know is how to > issue an svn command from within the anonymous function that is processing > the members.txt file. > > > >>>> I plan to start on figuring out how to do svn move from emeritus to > >>>> emeritus-request-rescinded. > >>> > >>> Do you mean emeritus-request => emeritus-request-rescinded ? > >> > >> Yes. So I'm thinking that we should adapt the memstat.json.rb code to > >> accept another url parameter with the file name that we already know, and > >> send that file name to the _svn.update method. > >> > >> As long as we're looking at this method, isn't it a bit badly named? Its > >> purpose is specifically to modify the members.txt file to move an entry > >> from one place to another, so shouldn't it have a more specific name, like > >> update_members_info? > >> > >> Anyway, we now need to pass the emeritus_file_name from memstat.json.rb to > >> the update method. And then have the update method use that file name to > >> move the file from one emeritus directory to another, depending on the > >> action: > >> emeritus: move the file from emeritus-requests-received to emeritus > >> rescind: move the file from emeritus-requests-received to > >> emeritus-requests-rescinded > >> active: move the file from emeritus to emeritus-rescinded > >> > >> I'd like to understand how this method call works: > >> _svn.update members_txt, message: message do |dir, text| > >> > >> Specifically, where did dir and text come from and why are they enclosed > >> in |...|? > > > > the ```do |args|.... end``` effectively defines an anonymous function. > > The parameters to that function are enclosed in vertical bars. Ruby > > calls this anonymous function a block. > > > > There are two syntaxes for calling blocks. In this case, the block is > > called via a yield statement. A more complete description can be > > found here: > > > > https://mixandgo.com/learn/mastering-ruby-blocks-in-less-than-5-minutes > > <https://mixandgo.com/learn/mastering-ruby-blocks-in-less-than-5-minutes> > > Very helpful. Thanks. > > > > > > Taking a step back, what is happening here is that the update method > > does a checkout into a temporary directory, reads the current contents > > of the file in question and passes that directory and contents to the > > anonymous function which returns new contents. A commit is then > > attempted. > > > > Making the code that converts old contents into new contants a block > > means that the overall process (starting with the creating of a > > temporary directory to commit potentially common code that is > > independent of the update operation being attempted. > > So now I just need an example of svn code executed with no update block and > some code executed inside the update block.
If I've understood correctly, the two svn commands are: + svn update of a file. This is an svn commit. + svn move of a file. This can either be applied to the repo directly, or can be done in the local workspace, followed by a commit. The svn client cannot do two different commands at once, so the only choice here is a local move followed by commit. It looks like svn may be able to commit from two workspaces at once. If not, some way must be found to checkout the two files into the same directory structure, i.e. from their common parent. To reduce the size of the checkout would need a sparse checkout of some kind. I don't think the current _svn.update method can be used to do this. There would need to be a new method. An alternative would to use svnmucc, which would allow commit (put) as well as a remote move in the same commit. This would need a new library method. > Thanks, > Craig <snip...>
