Good ideas. I'll definitely do this, starting with the pset lines in the email.
Also, for the meta-data I think I will go with a single file for all old revisions, but I will inspect svn properties for overrides on that going forward. That will make the history useful and have a lot of good defaults without having a ton of property edits right now. Jay On Fri, May 29, 2009 at 8:23 AM, Eli Barzilay <e...@barzilay.org> wrote: > On May 28, Matthias Felleisen wrote: >> >> 2. Your emails could include svn pset commands for setting/changing >> properties that you think may be appropriate to improve your >> software's behavior. (For example, if some file times out, your >> nagger could include a command to set the time out property low >> because I know that it's useless to wait or something like that.) > > Actually that's a good idea for all breakages: once something breaks, > you can make it continue sending the alerts -- and the way to get rid > of them is to either fix it, or if it's expected, then record it on an > svn property. And for even greater convenience (both for committers > and for you as the one who will need to fix things up) -- don't tell > people what to set, but make the web interface do that instead. This > approach does make the properties strategy work out nicely. > > -- > ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: > http://www.barzilay.org/ Maze is Life! > -- Jay McCarthy <j...@cs.byu.edu> Assistant Professor / Brigham Young University http://teammccarthy.org/jay "The glory of God is Intelligence" - D&C 93 _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
