On Sun, 31 May 2020 at 22:18, Craig Russell <apache....@gmail.com> wrote: > > Hi, > > Here's a formal proposal for Emeritus file names: > > New directory documents/Emeritus with these directories: > emeritus for accepted requests > emeritus-requests-received for received requests > emeritus-requests-rescinded for rescinded requests > emeritus-reinstated for original requests from reinstated Members
OK. > Contents of these directories: > <stem><.suffix> > Stem is full (legal) name > suffix is .txt, .pdf, or empty for directories with e.g. .pdf and .asc, or > historic (.eml .jpg etc.). The emeritus-requests-rescinded and emeritus-reinstated directories could potentially have documents from multiple instances, so may need a disambiguating suffix. > There was a comment that full name might include duplicates. I don't believe > that these are serious enough to warrant changing the file names that we have > historically. If we use availid going forward, then duplicates cannot happen. But it was not just about duplicates, which I agree are likely to be rare. (However there have already been issues with ICLAs.) What if someone changes their Full Name? How does one match up the old file name with the account? > Craig > > > On May 31, 2020, at 10:36 AM, Craig Russell <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". > > > > Craig > > > > > >> > >>> Thanks, > >>> Craig > >> > > > > Craig L Russell > > c...@apache.org <mailto:c...@apache.org> > Craig L Russell > c...@apache.org >
