On Mon, 1 Jun 2020 at 23:30, Craig Russell <apache....@gmail.com> wrote: > > > > > 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 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 Introduction of the Emeritus parent will require changes elsewhere, so it is not cost-free. > > > > 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. > 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 >
