roster-emeritus ready for review

[Craig Russell <ap...@gmail.com>]

Please take a look at branch roster-emeritus. 
https://github.com/apache/whimsy/tree/roster-emeritus

I'm not sure how to test it using rackup. The rackup environment sets up a /srv/svn directory with some of the files needed, but I cannot use it due to credentials. Is there some documentation on how to set up the local svn environment?

I've also significantly modified memstat.json.rb to use multiUpdate instead of update. This allows me to combine the update to members.txt with moving the emeritus request file from emeritus-requests-received to emeritus.

Finally, I'm not sure how to do the update for the emeritus request file if there is not a corresponding members.txt update. It seems silly to checkout a version of members.txt, not modify it, and then commit it just to move the emeritus request. So the code that is now checked in simply constructs an svn mv command followed by an svn commit command. Is this the right way to do this?

Thanks,

Craig

Craig L Russell
clr@apache.org

Re: roster-emeritus ready for review

[Sam Ruby <ru...@intertwingly.net>]

On Mon, Jun 8, 2020 at 6:48 PM Craig Russell <ap...@gmail.com> wrote:
>
> Please take a look at branch roster-emeritus.
> https://github.com/apache/whimsy/tree/roster-emeritus
>
> I'm not sure how to test it using rackup. The rackup environment sets up a /srv/svn directory with some of the files needed, but I cannot use it due to credentials. Is there some documentation on how to set up the local svn environment?

Short answer: http://svnbook.red-bean.com/en/1.7/svn.reposadmin.create.html

Longer answer: I know of three basic approaches.  One is to create an
empty repository, commit test data into it, check THAT repository out,
and run your svn commands against that.  That's the approach the
(Ruby) board agenda tool uses.  A second is to use your testing
framework's mocking function to stub out the svn calls.  That's the
approach the Node.js implementation of the board agenda tool uses for
everything (except some point in the future unit tests of the svn
functions themselves).  A third approach is the one that Sebb is
currently taking: using the dry run feature.

Cautionary note: if you intend to move forward to testing any client
side function, doing it using Ruby frameworks is both difficult and
slow.

> I've also significantly modified memstat.json.rb to use multiUpdate instead of update. This allows me to combine the update to members.txt with moving the emeritus request file from emeritus-requests-received to emeritus.
>
> Finally, I'm not sure how to do the update for the emeritus request file if there is not a corresponding members.txt update. It seems silly to checkout a version of members.txt, not modify it, and then commit it just to move the emeritus request. So the code that is now checked in simply constructs an svn mv command followed by an svn commit command. Is this the right way to do this?

This seems like something that can be done with a single svn mv
command, specifying two URLs and a --message parameter.

> Thanks,
>
> Craig
>
> Craig L Russell
> clr@apache.org

P.S.  Any chance you will be returning the favor and reviewing my
Node.js work any time soon?