> On Jun 1, 2020, at 3:17 PM, sebb <seb...@gmail.com> wrote: > > On Mon, 1 Jun 2020 at 22:42, Craig Russell <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 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. 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
