On Tue, 2 Jun 2020 at 01:45, Craig Russell <apache....@gmail.com> wrote: > > > > > 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?
No, but moving documents/emeritus will cause issues. > > > >>> > >>> 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? Yes, I used it a while back for JMeter. I have nearly got a PoC ready to commit, but it is getting late. Hope to push something tomorrow. > 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 >
