On 23.05.2013 23:52, Olemis Lang wrote: > On 5/23/13, Olemis Lang <[email protected]> wrote: >> On 5/23/13, Anze Staric <[email protected]> wrote: >> [...] >> >>> When upgrade is run again, it figures, >>> that it needs to perform all upgrades and tries to add field product >>> to table ticket, but this fails, because the field is still there, it >>> was not deleted in reset_db). >>> >> ... and ensure that MP upgrade procedure will not be triggered if DB >> schema is up to date , which represents a bug indeed . >> > I'll clarify what I meant to say with the statement above because it > may be misunderstood . > > Ensure that MP upgrade actions will not be performed due to the fact > that once MP upgrade method is executed it will notice everything is > up to date . Not doing so represents an error in MP system which has > to be asserted and reported as an (error | failure) .
Not sure I quite understand what you're getting at here. In real life, I'd expect an upgrade to multi-product to be a manual step, performed exactly once per BH/Trac installation. In other words, there is no need to (a) detect that this has already happened, or (b) be able to undo the upgrade -- that is, downgrade the database. This is in fact true for /any/ Trac plugin that adds its own tables to the database; IIUC reset_db will not remove those tables. An important attribute of any unit test environment is that test cases must be isolated -- in other words, it should not matter in which order individual test cases are run. This implies that each test case must see the same initial database -- which either means that it has to be a new database every time, or that reset_db has to roll back any changes to the schema. -- Brane -- Branko Čibej Director of Subversion | WANdisco | www.wandisco.com
