I'm currently using Red Gate ( http://www.red-gate.com/ ) and storing
the database schema snap shots it can create in SVN. I wrote up a
quick little command line utility to create the snapshots so it's very
easy to commit the whole schema frequently.
Then I use the rest of the red gate tools to compare and merge changes
from snap shots. Eventually I plan on using the Red Gate comparison
API to build a proper comparison tool for the snap shots but haven't
as yet had time to
The process though is working better for me, as it doesn't take much
effort for me to commit the schema frequently, which is the main thing
I wanted to accomplish.
Joe
On 7/22/05, Albie Janse van Rensburg <albie.jvr@gmail.com> wrote:
> Thanks a lot to everyone for your help, I'm going to have a look at
> everything after hours and hopefully we'll find a good streamlined solution.
>
> Cheers,
> Albie
>
> Dan Shookowsky wrote:
>
> >I see. I think the infrequent commits are the difference between your
> >environment and my experience. I like to commit things fairly often
> >so that I can return to a prior state in the event that I completely
> >bork some code while being "creative" or "efficient". These commits
> >are not stable at all and there's little reason to tag or include a
> >database script. You could probably use NANT or something similar to
> >perform a build/dbscript/commit operation in one fell swoop.
> >
> >
> >On 7/21/05, Albie Janse van Rensburg <albie.jvr@gmail.com> wrote:
> >
> >
> >>We're not really looking to subversion as a database recovery tool - I'm
> >>talking about, say, the "programming" aspect of the database - stored
> >>procs and "settings" such as metadata - status ids and that sort of
> >>thing, which are not user editable anyway.
> >>
> >>Yes, the scripts do have enforced compiling, but the application code
> >>might be dependent on a specific set of parameters or expect specific
> >>outcomes, etc which can change. The new version of code adapts quickly
> >>and goes into source control, but whenever someone tries to have a look
> >>at the old source (say 2 versions back, not yet a "stable" release
> >>gone), they run into problems. I think the need for control in this
> >>regard is well understood, just thought I'd put it down into writing ;-).
> >>
> >>We do very slow commits - say once every two days or so per developer,
> >>normally once that developer has reached a pretty stable point in his
> >>work, but scripting everything out before a commit still begs to be
> >>automated/integrated.
> >>
> >>Maybe one day (optimistically, at least 6 months hence) when I have time
> >>I'll look into building something myself...
> >>
> >>I'm checking out that script, thanks.
> >>
> >>Thanks for all the help so far.
> >>
> >>Dan Shookowsky wrote:
> >>
> >>
> >>
> >>>This guy has a VBScript that automates the scripting and versioning of
> >>>databases with VSS. It could probably be easily adapted.
> >>>
> >>>http://searchsqlserver.techtarget.com/tip/1,289483,sid87_gci1093178,00.html?bucket=ETA
> >>>
> >>>Personally, I'd rather only script a known "good" version and rely on
> >>>database backups for catastrophes involving the database. This is
> >>>because SQL Scripts, unlike code can't be on the server unless they
> >>>actually compile.
> >>>
> >>>On 7/21/05, Albie Janse van Rensburg <albie.jvr@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Thanks for the help. Is this the only way? I would obviously prefer a
> >>>>more integrated approach, but we'll have to make do. Does anybody know
> >>>>anything about the source control support in SQL server?
> >>>>
> >>>>Dan Shookowsky wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>Before you create a tag indicating a stable version that you'd like to
> >>>>>get back to, script the database into one or more .SQL files and
> >>>>>commit these to the repository. You end up with all the info that you
> >>>>>need. If you have specific meta-data that must be in the database,
> >>>>>you'll probably need to script this in some other way.
> >>>>>
> >>>>>On 21 Jul 2005 11:46:50 -0000, users-digest-help@subversion.tigris.org
> >>>>><users-digest-help@subversion.tigris.org> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>From: Albie Janse van Rensburg <albie.jvr@gmail.com>
> >>>>>>To: users@subversion.tigris.org
> >>>>>>Date: Thu, 21 Jul 2005 11:51:11 +0200
> >>>>>>Subject: Source Control for Database Aspect
> >>>>>>Hi all
> >>>>>>
> >>>>>>I am implementing Subversion for a .Net project at work, and it's great
> >>>>>>to be able to use plug-ins like AnkhSVN to get Subversion integrated
> >>>>>>with Visual Studio. However, like most software project above the
> >>>>>>"Hello World" level, there is a database aspect to our development. We
> >>>>>>are using Microsoft SQL Server 2000, and a large part of the project's
> >>>>>>business logic lies in stored procedures and metadata that populate
> >>>>>>elements in the project. It is necessary to bring the database aspect
> >>>>>>into version control, as older versions of the .Net source are often
> >>>>>>incompatible with different versions of the database.
> >>>>>>
> >>>>>>Is there any way to accomplish this level of source control using
> >>>>>>Subversion? I am also very interested to know whether there are any
> >>>>>>Subversion plugins available that would work with SQL Server - it has
> >>>>>>some method by which Visual Source Safe (ew...) can integrate, so it
> >>>>>>seems natural to assume that third party developers should be able to do
> >>>>>>something similar.
> >>>>>>
> >>>>>>Any hints, suggestions or flames (I did mention VSS. Argh! Again!) are
> >>>>>>welcome.
> >>>>>>
> >>>>>>Albie
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 16 18:54:28 2005