Re: Testing with concurrent sessions
От | Markus Wanner |
---|---|
Тема | Re: Testing with concurrent sessions |
Дата | |
Msg-id | 4B5489FC.1010004@bluegap.ch обсуждение исходный текст |
Ответ на | Testing with concurrent sessions ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>) |
Ответы |
Re: Testing with concurrent sessions
|
Список | pgsql-hackers |
Hi, Quoting "Kevin Grittner" <Kevin.Grittner@wicourts.gov>: > I strongly encourage you to set that up on git.postgresql.org. I'm about to provide git repositories for Postgres-R anyway, so I've setup two projects on git.postgres-r.org: dtester: that's the driver/harness code postgres-dtests: a Postgres clone with the dtester patch applied - this is based on the Postgres git repository, so you can easily switch between Postgres branches. I'd like to clean postgres-dtests in the sense that all tests included there are expected to succeed on Postgres HEAD. Those (like the initial SSI ones) that are expected to fail should get marked as such in there. If you want to add SSI specific tests, which your are expecting to succeed on your branch, I'd recommend you create your own branch (or merge into your branch from postgres-dtests). Git makes that simple enough. > I've barely scratched the surface on git in the last few > weeks, and already I'm a big fan. I was never convinced that > subversion was an improvement over cvs -- they each had advantages > over the other which seemed a wash for me -- but git takes everything > to a whole new level. I agree, and would like to extend that to DVCSes in general. Having started with monotone, I'm used to a different level of convenience, especially WRT network exchange and merging. To be fair, I'm excited about how fast git is (especially WRT network exchange, where monotone just plain sucks). > I see your point. Even with a general solution, probably best to > leave the pset there for psql, though. Agreed, that's fixed in the new git repository. > I'll look those over. Any caveats beyond what you already mentioned > of which I should be particularly careful? Uh.. no, there's no difference other than that. It's a paradigm question. Ones like it that way, others the other. And then there are applications that are a better fit than others... Now, I tend towards the event based approach, because it basically relieves you from having to deal with concurrent threads and all their issues. You need to get a single ordering of events anyway, if you want to check ordering constraints. Regards Markus
В списке pgsql-hackers по дате отправления: