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
Received on Fri Jul 22 09:33:39 2005