> 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? 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?
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
