1 of 1 people found this helpful
Envers will certainly work for the 1st point. If you retrieve a test plan using an audit reader, and you have a relation TestPlan.getTestCases() or if you know the revision number (basing e.g. on a date), you will get the historic test cases.
As for the second point, Envers doesn't provide a workflow mechanism, or a "future/forward history". It only archives the old versions.
The third point is also very easy with Envers - it's very simple usage of the audit reader.
Hope this helps
Regarding the second point, I don't need a workflow mechanism, but if I can give Envers a start and end time/date it can give me all the changes for a the testcases in a plan between those times, right? From what I've read Envers won't go all the way and tell me what changed with each version. I'll either need to store that when the change is done or figure it out when I create the report by comparing versions. The workflow part I know I'll need to write on my own.
I appreciate the answer. It looks like envers is probably the right the tool for me to use.
Yes, having a date, you can obtain a revision number. So if you have start and end dates you can obtain two revision numbers. Then, you can query historical data to return test cases which changed between those revisions (see auditReader.createQuery).
Figuring out changes is normally pretty straighforward - just compare two objects - normally it's way faster then storing and retrieving it from a DB.