Redevelope backend database access

[Alan Tse]

We are re-developing our application using different backend database from .dbf to MySQL. Also we need to change the way how to access the MySQL using different database access components in application.

What do you think we should do with the subversion? Do a branching or something else? Or even start a new project in subversion?

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1701945

To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].

[Andy Levy]

On Mon, Apr 13, 2009 at 23:28, Alan Tse <alan...@trafficnet.com.au> wrote:
> We are re-developing our application using different backend database from .dbf to MySQL. Also we need to change the way how to access the MySQL using different database access components in application.
>
> What do you think we should do with the subversion? Do a branching or something else? Or even start a new project in subversion?

If your application is designed properly, only those areas of it which
deal with the direct database access should be impacted (this is also
a not-so-subtle hint to build in a DB abstraction layer if needed on
the new version, so you aren't doing this again when you switch to
PostgreSQL or MSSQLServer or Oracle).

Would starting a new project (which is a word you'd have to define
here - a complete fork within the same repository, or a new repository
altogether) provide any benefit that outweighs the drawback of (if you
create a new repository) dropping all history?

I'd branch, and merge in changes from the "old" version on a regular
basis since you'll presumably be doing maintenance on the old code
instead of stopping everything while the rewrite is happening..

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1708105

[Alan Tse]

Hi,

Our application is pretty old, might be say all the data access components(access the .dbf files) are put into a data module unit (we use Delphi), this is one of the places need to replace the old components with the new MySQL access components (Zeos components) and its SQL statements.

Also in the other units (such as forms, screens), there are places using these old components specific ways to access the record sets. So not only the data access layer need to be modified.

However, as you mentioned, the existing software are still need to be fixed if any bugs come up.

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1717337

[Bob Archer]

You really should read the chapter on Branching and Merging in the svn
book. It has several strategies that you might use. You could go with a
feature branch or a release branch. Basically you need to branch.

http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.branchmerge

BOb

> unsub...@tortoisesvn.tigris.org].

------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=1728186