> On Jun 1, 2020, at 4:52 PM, sebb <seb...@gmail.com> wrote: > > On Mon, 1 Jun 2020 at 23:30, Craig Russell <apache....@gmail.com > <mailto:apache....@gmail.com>> wrote: >> >> >> >>> On Jun 1, 2020, at 3:17 PM, sebb <seb...@gmail.com >>> <mailto:seb...@gmail.com>> wrote: >>> >>> On Mon, 1 Jun 2020 at 22:42, Craig Russell <apache....@gmail.com >>> <mailto:apache....@gmail.com> <mailto:apache....@gmail.com >>> <mailto:apache....@gmail.com>>> wrote: >>>> >>>> >>>> >>>>> On Jun 1, 2020, at 12:28 PM, sebb <seb...@gmail.com> wrote: >>>>> >>>>> On Mon, 1 Jun 2020 at 19:59, Craig Russell <apache....@gmail.com> wrote: >>>>>> >>>>>> I know there are more messages in this thread, but this is the most >>>>>> relevant for actually making a change in whimsy. >>>>>> >>>>>> IIUC, we want to allow _svn.update to take an array of references as the >>>>>> first argument, and using metadata from elsewhere, check out all of the >>>>>> arguments. >>>>> >>>>> Whilst it might be possible to do this in the existing method, I think >>>>> it would be better to create a new method. >>>>> This would also be easier to test and debug without breaking existing >>>>> code. >>>> >>>> Something like updateMultiple >>>> >>>> The first argument is an array of file/directory references. Each >>>> reference uses the same logic as in the current update method to either >>>> check out the directory or the file. And then after return from the >>>> callback, all of the file/directories would be committed. >>>> >>>> The yield callback would deliver an array of temp directories and an array >>>> of files, corresponding to the array of file/directory references in the >>>> first argument. The callback would have to remember which of the elements >>>> in the array to use. >>>> >>>> In our case here, we would use file[0] in the callback to get the >>>> checked-out members.txt. We would use dir[1] to get the checked-out >>>> Emeritus/emeritus-requests-received and dir[2] to get the checked-out >>>> Emeritus/emeritus directory. >>>> >>>> Would we even need both directories? >>> >>> I don't think rename works across separate workspaces. >> >> So we have a sparse checkout of Emeritus and then individual svn update of >> the emeritus-requests-received/stem.txt. Then svn mv from there to either >> emeritus or emeritus-requests-rescinded. >>> >>>> Would we/should we use Emeritus as the checked-out directory and use svn >>>> commands to check out and move files in the emeritus-requests-received and >>>> emeritus directories? >>> >>> Yes, the emeritus files need to have a shared parent in order to do >>> the rename, but >>> I don't think it particularly helps to change the shared parent from >>> /documents to /documents/Emeritus. >>> >>> AFAICT it only makes sense to create the extra level if the whole >>> subtree is to be checked out. >>> Do we really want to do that? >> >> Not needed just for move from one parent to another. >> >>> Surely we just want to do a sparse checkout of all the relevant >>> emeritus directories? >> >> Yes. >> >>> In which case this can be done from /documents just as easily as >>> /documents/Emeritus >> >> Except for readability of the tool. > > I think the difference will be marginal. > * checkout immediates of Emeritus > versus > * empty checkout of documents, followed by empty checkouts of up to 4 > emeritus dirs > > In each case you then need to checkout the affected paths
I agree. > > Introduction of the Emeritus parent will require changes elsewhere, so > it is not cost-free. I agree. Do you know of any other places where there is tooling except for the workbench that puts a new request into emeritus-request-received? > >>> >>> I suspect using svnmucc will be a lot easier than svn. >>> This is because the rename can be done remotely, i.e. no need to do a >>> checkout of any emeritus files. >>> The co-routine needs to update the file and pass back details of what >>> else to commit. >> >> I think the co-routine return should only pass back an array of results of >> updating files (members.txt). The updateMultiple would then replace the >> file(s) that were changed. And the commit would commit the changed file plus >> the checked-out directories. > > For the updateMultiple case, yes, but here I was referring to the > svnmucc alternative. > Since its co-routine does not actually do an svn move, it needs > instead to pass back what to rename. I have not looked at svnmucc. Do you still think that is a worthwhile investigation? Craig > >> Craig >>> >>>> Craig >>>> >>>>> >>>>>> The co-routine will make changes in some files (members.txt) and move >>>>>> files from one directory (documents/Emeritus/emeritus-requests-received) >>>>>> to another directory (documents/Emeritus/emeritus-requests-rescinded) >>>>>> and then commit all of them in one svn commit. >>>>> >>>>> Almost. >>>>> The co-routine does not do the commit; that is done by the caller. >>>>> >>>>>> Did I get that right? >>>>>> >>>>>> Craig >>>>>> >>>>>>> On Jun 1, 2020, at 5:19 AM, Sam Ruby <ru...@intertwingly.net> wrote: >>>>>>> >>>>>>> My feeling is mixed. >>>>>>> >>>>>>> I am not a fan of emeritus-* directories littering the >>>>>>> private/documents directory. Making them subfolders of an Emeritus >>>>>>> folder appeals to me. >>>>>>> >>>>>>> Like Sebb, I'd also think twice before considering moving members.txt. >>>>>>> >>>>>>> That being said, the idea of a single, atomic, commit appeals to me. >>>>>>> >>>>>>> Currently the following command returns an Access forbidden violation: >>>>>>> >>>>>>> svn checkout https://svn.apache.org/repos/private --depth empty >>>>>>> >>>>>>> It should be possible to make that work, with an ACL set up for ASF >>>>>>> members. Whether it is implemented as a new library function or via >>>>>>> new arguments to the existing function, it should be possible to >>>>>>> checkout out an empty copy of the entire private repository to a >>>>>>> temporary folder, and within that folder run svn update commands to >>>>>>> get the latest contents for individual files, then change the contents >>>>>>> of those file as well as other related svn add, svn move, or svn >>>>>>> delete commands, and then do a single svn commit. >>>>>>> >>>>>>> - Sam Ruby >>>>>>> >>>>>>> On Mon, Jun 1, 2020 at 7:41 AM sebb <seb...@gmail.com> wrote: >>>>>>>> >>>>>>>> On Sun, 31 May 2020 at 20:03, Craig Russell <apache....@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> The following is excerpted from memstat.json.rb. It assumes that we >>>>>>>>> have moved all of the emeritus files from subdirectories of documents >>>>>>>>> to subdirectories of documents/Emeritus. >>>>>>>>> >>>>>>>>> EMERITUS_DIR = ASF::SVN['documents/Emeritus'] >>>>>>>>> ... after the update of members.txt >>>>>>>>> # update the emeritus files >>>>>>>>> if @action == 'emeritus' >>>>>>>>> _svn.update (EMERITUS_DIR, 'Update emeritus file', env, _ do || >>>>>>>>> _.system "svn mv emeritus-requests-received/{@emeritusfilename} >>>>>>>>> emeritus" >>>>>>>>> end >>>>>>>>> elsif @action == 'rescind_emeritus' >>>>>>>>> _svn.update (EMERITUS_DIR, 'Update emeritus file', env, _ do || >>>>>>>>> _.system "svn mv emeritus-requests-received/{@emeritusfilename} >>>>>>>>> emeritus-requests-rescinded" >>>>>>>>> end >>>>>>>>> end >>>>>>>>> >>>>>>>>> >>>>>>>>> WDYT? >>>>>>>> >>>>>>>> I am not keen on moving things around. >>>>>>>> In particular, members.txt is likely to be used in lots of places. >>>>>>>> >>>>>>>> Note also the currently the emeritus/ and emeritus-requests-received/ >>>>>>>> directories are not checked out; they are listings only. >>>>>>>> We should also avoid having such files checked out if possible. >>>>>>>> >>>>>>>> It may be harder to automate, but that is far preferable to making >>>>>>>> layout changes and adding unnecessary checkouts to Whimsy. >>>>>>>> >>>>>>>>> Craig >>>>>>>>> >>>>>>>>>> On May 31, 2020, at 10:44 AM, Craig Russell <apache....@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On May 31, 2020, at 10:36 AM, Craig Russell <apache....@gmail.com >>>>>>>>>>> <mailto:apache....@gmail.com>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On May 31, 2020, at 5:55 AM, Sam Ruby <ru...@intertwingly.net >>>>>>>>>>>> <mailto:ru...@intertwingly.net>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Sun, May 31, 2020 at 12:50 AM Craig Russell >>>>>>>>>>>> <apache....@gmail.com <mailto:apache....@gmail.com>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> So now I just need an example of svn code executed with no update >>>>>>>>>>>>> block and some code executed inside the update block. >>>>>>>>>>>> >>>>>>>>>>>> Publishing minutes after a board meeting involves a number of >>>>>>>>>>>> updates >>>>>>>>>>>> to different svn repositories: >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/publish.json.rb >>>>>>>>>>>> >>>>>>>>>>>> <https://github.com/apache/whimsy/blob/master/www/board/agenda/views/actions/publish.json.rb> >>>>>>>>>>>> >>>>>>>>>>>> This example shows issuing svn commands within the block. >>>>>>>>>>>> >>>>>>>>>>>> A few things to note: >>>>>>>>>>>> >>>>>>>>>>>> 1) If the block only takes one argument, then it is provided with a >>>>>>>>>>>> tmpdir only. It is up to you to do any and all svn commands except >>>>>>>>>>>> for the final commit. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> 2) While you can spawn any command within the block (svn or >>>>>>>>>>>> otherwise) >>>>>>>>>>>> any way you like, wunderbar provides an _.system method that will >>>>>>>>>>>> capture the stdout and stderr and add it to the transcript >>>>>>>>>>>> provided in >>>>>>>>>>>> the response back to the client. >>>>>>>>>>>> >>>>>>>>>>>> 3) As sebb points out, a full temporary checkout of a directory >>>>>>>>>>>> like >>>>>>>>>>>> https://svn.apache.org/repos/private//documents >>>>>>>>>>>> <https://svn.apache.org/repos/private//documents> would be >>>>>>>>>>>> impractical. >>>>>>>>>>>> Perhaps instead of emeritus-rejoined, emeritus-requests-received, >>>>>>>>>>>> and >>>>>>>>>>>> emeritus-requests-rescinded directories that are sister >>>>>>>>>>>> directories to >>>>>>>>>>>> the emeritus directory, there could be a single emeritus directory >>>>>>>>>>>> which contains a number of subdirectories. An example of such a >>>>>>>>>>>> structure is https://svn.apache.org/repos/private/financials/Bills >>>>>>>>>>>> <https://svn.apache.org/repos/private/financials/Bills>. >>>>>>>>>>> >>>>>>>>>>> Here's a way forward that changes a lot but makes the technical >>>>>>>>>>> solution easier. >>>>>>>>>>> >>>>>>>>>>> svn mkdir foundation/Members >>>>>>>>>>> svn mv foundation/members.txt foundation/Members >>>>>>>>>>> svn mv documents/emeritus foundation/Members >>>>>>>>>>> svn mv documents/emeritus-requests-received foundation/Members >>>>>>>>>>> svn mv documents/emeritus-requests-rescinded foundation/Members >>>>>>>>>>> svn mv documents/emeritus-reinstated foundation/Members >>>>>>>>>>> >>>>>>>>>>> Then, the _svn.update would checkout the entire Members directory >>>>>>>>>>> which consists solely of the members.txt and the various emeritus >>>>>>>>>>> files. And the _svn.update function would commit everything or >>>>>>>>>>> nothing. >>>>>>>>>>> >>>>>>>>>>> An alternative is to do the _svn.update of members.txt first and if >>>>>>>>>>> successful, do the move of the emeritus files, which unless >>>>>>>>>>> something is seriously messed up, will "always succeed". >>>>>>>>>> >>>>>>>>>> In order for this to work we also need to implement part of the >>>>>>>>>> above, moving everything but members.txt to a new directory, which >>>>>>>>>> could be in documents/Members instead of foundation/Members. Then, >>>>>>>>>> the directory checked out in the _svn.update would be the >>>>>>>>>> documents/Members directory which includes all of the emeritus files. >>>>>>>>>> >>>>>>>>>> This is probably my first choice because it's minimum disruption to >>>>>>>>>> the existing tools and will significantly help secretary in filing >>>>>>>>>> emeritus requests. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Craig >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Craig >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Craig L Russell >>>>>>>>>>> c...@apache.org <mailto:c...@apache.org> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Craig L Russell >>>>>>>>>> c...@apache.org <mailto:c...@apache.org> >>>>>>>>> Craig L Russell >>>>>>>>> c...@apache.org >>>>>>>>> >>>>>> >>>>>> Craig L Russell >>>>>> c...@apache.org >>>>>> >>>> >>>> Craig L Russell >>>> c...@apache.org >> >> Craig L Russell >> c...@apache.org Craig L Russell c...@apache.org
