I happen to see the fact that the differences between C* version are clearly visible for a given test as a feature rather than a burden. Every difference in behavior between C* versions should have a good reason, and I like that dtests highlight them. Typically, from very quickly eyeballing the patch, I saw a couple of differences between versions I had forgotten or that I'm not entirely sure about: it's a good thing, and if we split between branches we largely lose that (you'd have to diff the branch to figure out those differences which imply you already know what you're looking for). Similarly, I've used dtests a bunch of times to check in which version a particular change of behavior was done and looking at the '@since' annotation is far easier than having to bisect through version branches manually to find when the test was added.
I understand that there is also places where the difference between version is due to more boring changes like a change in the spelling of a log message that is checked by the test, but is that really such a big burden in practice? Also, there is probably some of those cases that could be made cleaner: for instance, I can see some diff related to changes in stress that could be partly abstracted out. Anyway, I'm basically not sure "isolating version specific changes to their own branches" is necessarily a good thing, so I can't say I'm convinced. But I'm not writing as much dtests as you guys, so if you think doing so would substantially facilitate your work, then that's good enough reason (but you asked for feedback :)). -- Sylvain On Thu, Jan 8, 2015 at 9:23 PM, Philip Thompson < philip.thomp...@datastax.com> wrote: > All, > > I would like to propose splitting the cassandra-dtest code base into > versioned branches that match the structure of the C* repository. Each C* > version branch, e.g. cassandra-2.0, would have a corresponding dtest > branch. This will allow us to isolate version specific changes to their own > branches, at the cost of extra merging work on contributors to > cassandra-dtest. I have a WIP and the code has become significantly > cleaner, and I expect the benefits to grow as we make more radical changes > to cassandra-dtest for cassandra 3.0. > > I am looking for feedback from the contributors to Cassandra that use or > contribute to cassandra-dtest. Are you in favor of this change? > > Thanks, > Philip Thompson > > https://github.com/riptano/cassandra-dtest/compare/cassandra-2.0 > https://github.com/riptano/cassandra-dtest/compare/cassandra-2.1 > https://github.com/riptano/cassandra-dtest/compare/trunk >
