I believe this is the best solution. Thanks. Daniel. On 3/10/03 11:55, "Brian Kowald" <[EMAIL PROTECTED]> wrote:
> Sure, just store the backup file as binary. Another option is to store the > scripts for creating the tables and stored procedures since they are text > files, which is what cvs was born to work with. That is how I have seen > DBA's do it. You could then use the merging capability of cvs. You might > also have upgrade scripts to store when going from one version of your app > to another to store. > > Brian > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Daniel > Hurtubise > Sent: Monday, March 10, 2003 11:35 AM > To: CVS-II Discussion Mailing List > Subject: Database file checkin > > > Dear CVS Users, > > Has anybody checked in a database backup into CVS? I know this may sound > odd, but I was thinking of taking a snapshot of my SQL Server database in a > empty data state and then checking it into CVS. > > Basically, I just want to track my stored procedures and table schemas > because I replicate this database for distinct customers. The database is > tightly coupled to a Web application which I manage under CVS also and I'll > like to keep both the database and web application components in sync. > > Will there be any issues with checking that backup out of CVS and restoring > a new database from it? I will test this on my own, but I was wondering if > anyone else has taken this path before. > > Thanks. > Daniel. > > > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs > > > > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
