Test metrics accomplish in analyzing the current level of maturity in
testing and give a projection on how to go about testing activities by
allowing us to set goals and predict future trends:
http://www.top-itarticles.com/softtest/softtest18.asp
Specific practices to establish baselines are covered by this specific
goal. The specific practices under the Track and Control Changes
specific goal serve to maintain the baselines.
http://brsx.co.uk/management/ConfigMgmt/CMsg1.asp
Software configuration management specific practices play a great part
in maintaining and monitoring configuration of various items. More to
read
http://testingmechanism.blogspot.com
Configuration management brings integrity in your work using
configuration identification, configuration control, configuration
status accounting and configuration
Audits. To learn more, visit:
http://testingmechanism.blogspot.com/
I am curious if there are any Bi or Curious guys on this group. I am looking for a few buddies to have fun with. I am a flight attendant for a major airlines so i can get free tickets anywhere at anytime. I am very discreet, clean, safe, and very easy going. Would love to have a few buddies for good clean, mutually pleasurable experiences. If you are at all interested, you can see a few of my photos, and contact me via kam chat from my profile at http://www.ezlmail.com/kevin
With WINE installed on Linux, all that was needed to get Daversy
running (command line and GUI) was to download:
MSVCR71.dll,
MSVCP71.dll
and
MFC71.DLL
From dllfiles.com, put them into Daversy directory and fire Daversy up.
I'll add this information to http://appdb.winehq.com as soon as possible.
Do not worry about porting to Linux in the first place.
Now I need some demo-files to try out the functionality with - you
have any? Do not run neither SQLite nor Oracle databases.
I tried the 0.1.207-version under WINE (winehq.com) but it failed
because of MSVCP71.dll and MFC71.DLL not being registered/available
to WINE. Also added Daversy to WINE application db:
http://appdb.winehq.com
If you give more information about the versions of MSVCP71.dll and
MFC71.DLL that you have verified works on Windows I'll try to get hold
of them, link them up and continue testing. Maybe it works rather will
under WINE after that. If it does, I'll add a Wiki-page describing how
to run Daversy on Linux if you are interested.
Hi!
After extensive research (summarized at
http://wiki.motin.eu/VersionControlOfDatabases where Daversy is
mentioned as well of course) on methods of database versioning, I have
not found any - not even commercial - products/projects that support
MySQL database versioning.
Your project really looks promising for this though! I already love it
and all the work you are doing! :)
I'll be very interested in notices of how this project evolves.
Especially on if and when MySQL support is going to be added. I
present a "user demand" on this issue here :) Also being able to use
Daversy on Linux. Hopefully it will work out great after it has been
rewritten en Perl.
Thereafter I may be able to help fix things as well. I am a
web-developer running Linux as main OS, so Windows-programming is not
my cup of tea...
Cheers!
/Fredrik
It looks sweeeet! :)
--- In daversy@yahoogroups.com, "Eli Golovinsky" <egooli@...> wrote:
>
> I've asked a friend of mine to create a logo for Daversy and I've
> changed the www.daversy.org site to include it.
>
> It's in green.
>
> Hope you like it.
>
> Comments are welcome.
>
> Eli.
>
Thought i would share something with ya'll. Great fun and it does actually
work. Met my girl on here, http://www.dontwaitjoinnow.info/qkmg and so far
it's been the best year of my life ever! Wish you all the same happiness.
There's a design issue David and I have been discussion over the email
for about a day. I would like to hear what you think.
It concerns the dependencies between database objects and what is the
best way to represent them in Daversy.
Until now, the only database objects Daversy has supported were tables
and columns. As was planned I started working on adding support to
other objects, and I started out with indexes. The relationship
between tables and columns is quite clear : it's one of containment. A
table clearly contains the columns. The relationship between an index
and a table is not so clear-cut. On the one hand, an index cannot
exist without the table that it indexes. On the other, removing the
index doesn't change anything in the logic of the database design -
just makes it slower. Another argument that supports the second claim
is the fact that while columns, primary keys and foreign keys can be
stated within the CREATE TABLE statement, the indexes must be created
with separate SQL commands, leading me to believe that the designers
of SQL did not consider the index to be an integral part of a table.
This whole issue of dependency management relates to the way we
generate SQL scripts from a state. We need to create the objects in an
order that will not violate their dependencies. That is not a hard
task, what we need is just a topological sort implementation. The
problem is that some object types can be viewed as being contained
within other (as in the table-index case) and so the sorting might
need to be done on top-level objects only.
There's also another problem, the implementation of the database
providers. Ideally each database provider will contain very little
code so that Daversy could be adapted to many. The original concept
was to create an ICommandGenerator itnterface and each provider will
have classes that implement this interface for each database object
type they support. And so in the Oracle provider we have
CTableCommandGenerator, CColumnCommandGenerator and
CIndexCommandGenerator. The assumption about those objects is that
they generate complete SQL commands, such that CColumnCommandGenerator
can generate ALTER statements to add / remove / change columns in a
particular table. This assumption led to some duplicity between the
table command generator and the column command generator - both have
to handle column names and data types. That duplicity was naturally
refactored into a common method but it still feels a bit like a
cludge. If we consider the indexe to be a part of the column, it will
require CTableCommandGenerator to call CIndexCommandGenerator
directly. In itself that is not a bad thing, but that makes the
provider aware of the hierarchy of database objects and that logic
will have to be duplicated in all the providers. I don't feel very
comfortable with that. Looking at this from yet another angle, a
database provider is already more or less aware of that hierarchy in
its Extract method. It adds columns to tables and tables to the state,
which makes it aware of the fact that a table contains columns. It
could also add indexes to the table and be aware that tables contain
indexes.
I'd love to hear any thoughts you might have on the subject. If you're
not familiar with the design of Daversy, you can download
https://www.svn-hosting.com/trac/Daversy/attachment/wiki/Downloads/Daversy.chm
and read the documents in the Daversy Documentation folder.
I've asked a friend of mine to create a logo for Daversy and I've
changed the www.daversy.org site to include it.
It's in green.
Hope you like it.
Comments are welcome.
Eli.
Welcome to the Daversy project group.
I've been discussing various issues related to the project with many
people, at several forums, over the email and on the wiki pages of the
project's home page (www.daversy.org).
I thought it was time to bring all those interested in the project
together as well as provide a convinient platform to announce new
versions as they are made available.
Your participation is most welcome.
Best regards,
Eli.