What source control integration do you need?

• 
  I had sent out several ideas in an email on this topic earlier, but I thought of one more. I don't think the tool should automatically check-in the changes it has made, but when you go to check them in, it would be good to get a summary of changes, and by this I simply mean a list of the items that are going to get updated, removed, inserted into source control so that I know the changes I'm expecting are there with no surprises.

  Grant Fritchey May 25, 2007 07:20

  - 0 +
• 
  The feedback I've had so far has been nearly unanimously been for not checking in the modified files once SQL Compare has checked them out, so you're on the same wavelength.
  
  In terms of actually performing the checkin, this will be simply a question of using your preferred source control client Pending Change Set view, which should list all checked out files, allowing you to check them in with appropriate comments.
  
  Bear in mind that source control integration has not been approve just yet. If it gets implemented it will be a later release.
  
  Hope this makes sense.
  
  David Atkinson
  Red Gate Software

  David Atkinson May 25, 2007 09:32

  - 0 +
• 
  I agree that I would like it to automatically check out, but not automatically check in. Perhapse a prompt for me to check them back in with a comment box as to why I made changes.
  
  If I have to go somewhere else to check it in I probably will forget.

  Giggles220 May 25, 2007 12:07

  - 0 +
• 
  I'm hoping that as part of the SCCI interface, it will be possible to invoke a Pending Change Set window, but if this isn't possible it would be a nice addition to integrate this into SQL Compare. However, I wouldn't class this as an essential source control integration, as Change Set functionality exists in all source control UIs.
  
  David

  David Atkinson May 25, 2007 12:14

  - 0 +
• 
  Would input regarding integration with other systems be welcome?

  rbellamy May 30, 2007 18:18

  - 0 +
• 
  It depends what you mean by "other systems". Essentially I'm trying to get a feel for what SQL Compare could do to help those who want to save their object script files under source control.
  
  So far the number one request is to have the tool automatically check the relevant objects out. This affects all those who use the VSS checkout-edit-checkin source control doctrine. If you use CVS/SVN (edit-merge-commit), it works pretty well as-is.
  
  The other requests are as follows, roughtly in priority order:
  - auto add new object files to source control
  - auto delete object files from source control
  - provide a list of source control modifications that SQL Compare intends to make
  - option to get latest version of a scripts folder from within SQL Compare
  - option to get labeled version of a scripts folder from within SQL Compare
  
  David Atkinson
  Red Gate Software

  David Atkinson May 30, 2007 18:59

  - 0 +
• 

  David Atkinson wrote:

  The other requests are as follows, roughtly in priority order:
  - auto add new object files to source control
  - auto delete object files from source control
  - provide a list of source control modifications that SQL Compare intends to make
  - option to get latest version of a scripts folder from within SQL Compare
  - option to get labeled version of a scripts folder from within SQL Compare

  
  And then make it do all this from the command line. See, we're reasonable people.

  Grant Fritchey May 31, 2007 08:03

  - 0 +
• 
  Grant,
  
  Can you please describe the scenario in which you need this to work from the command line?
  
  David

  David Atkinson June 01, 2007 08:31

  - 0 +
• 
  Sure.
  
  We have a continuous integration environment that we automatically build daily based on a label. We have to check the code out of the system and then run the build on a database. We've been doing this with an in-house system. We're looking at doing it with MS DBPro. DBPro actually won't manage the code at all so we have to use the TFS command line. If your tool worked that way, it wouldn't be an issue as long as we can then call all the compare & build functions from the command line.

  Grant Fritchey June 01, 2007 08:35

  - 0 +
• 
  If you're running a build, why are you checking out the files? Isn't a getlatestversion what you need to do?
  
  You can definitely build a database from the command line using SQL Compare 6. Well, you need to synch to an existing one - SQL Compare won't create a new DB for you, but there's no reason why you can't simply run a sqlcmd script to create the database first.
  
  David Atkinson
  Red Gate Software

  David Atkinson June 01, 2007 09:54

  - 0 +
• 
  Shouldn't be an issue. We deploy from a label, not from the latest code. That way we always go from a known state.

  Grant Fritchey June 01, 2007 10:37

  - 0 +
• 
  So all you want to do is to automatically get a labelled version of your scripts folder, and synch this to a database?
  
  If this is the case, whether we provide the source control functionality via the command line, or whether you have to use your source control tool's command line is pretty much equivalent?
  
  Unless you need to automate the synching of a live database to a scripts folder, I can't see why you'd need checkout functionality in the SQL Compare 6 command line. Or am I missing something? I can see why you may like a switch that could load a specific labelled version of the scripts folder... is this what you're really asking for?
  
  David Atkinson
  Red Gate Software

  David Atkinson June 01, 2007 10:59

  - 0 +
• 
  The problem has always been getting the scripts to run in the correct order to build the database. We've been working with manifests that determine script order and that in-house tool I mentioned earlier uses this to figure out the order for scripts. However, it's a pain the butt and a manual process, therefor prone to error. If we used SQL Compare for this it would be because SQL Compare can, quite successfully, figure out the correct script order on it's own automatically.

  Grant Fritchey June 01, 2007 11:23

  - 0 +
• 
  My point is that you don't need the SQL Compare 6 command line to interact with your source control system. Instead you can use the TFS command line to get your labelled version from source control (I'm guessing that this works), and then use SQL Compare 6 command line to deploy your database.
  
  Naturally SQL Compare will sort out all the dependencies/ordering. All you need to do is to point it to the folder where the sql creation files are stored.
  
  David Atkinson
  Red Gate Software

  David Atkinson June 01, 2007 11:51

  - 0 +
• 
  We call the TFS command line now.

  Grant Fritchey June 01, 2007 12:22

  - 0 +
• 
  I think there may be some confusion over terms here...
  
  i have noticed alot of people say "check out" when they arent actually checking out a file to edit it... they really should say "synch" or "get".
  
  The idea of using SQL Compare 6's new script folder abilities to "build" a database is one i am looking forward to as well... like Granted, i have an inhouse build routine which essentially takes all of the database scripts and "builds" them into an empty staging database, that can then be snapshotted and/or used as a source to synchronise schema changes to a live DB.
  
  Currently my DB build is pretty dumb... it just uses a queued approach and hammers scripts at the staging database, if one fails it gets requeued at the end and tried later... It works for the most part but is ugly and inefficient. But i didnt want to get into the nitty gritty of actually interpretting the script files and figuring out some kind of dependancy order.
  
  I plan to change my build routine to create the empty database, then use SQL Compare 6 to compare the script folder source, to the empty database, and synchronise all changes across. I can let redgate worry about the dependancies and order that the objects need to be created!
  
  We use the SQL Compare Toolkit edition (c# libraries to use in our .NET apps) to do this kind of thing here, but i believe that the "Pro" edition of SQLCompare supports commandline invocations as well, so that may be what you can do Granted.
  
  I agree with David, in terms of building a database from the scripts, no integration with source control on the part of RedGate itself is strictly necessary... most of us would probably have our existing build scripts or visual build applications like Visual Build Pro, FinalBuilder etc, anyway, and these can handle synching to the desired label/revisions of scripts and creating the empty database, before invoking redgate to do the actual "build". Then assumedly there are cleanup steps afterwards that our build script will do too. In my case this is comparing the built database to the snapshot stored in perforce, and if this is different checking out the snapshot and generating a new one ready to check back in. These tasks are accomplished by an application i wrote, which uses the SQLToolKit libraries

  rgribble June 05, 2007 01:37

  - 0 +
• 
  Thanks for your post. I think you're summarized a common issue clearly and your suggested solution using SQL Compare should solve it. Once you've got your hands on the final release and given it a go, please let us know how you get on.
  
  Best regards,
  
  David Atkinson
  Red Gate Software

  David Atkinson June 05, 2007 04:46

  - 0 +
• 
  Yes, I seem to have put myself in a hole. I didn't mean check out when I was referring to the continuous integration builds. It is a get by label. The command line capabilities of SQL Compare 6 would then come into play for the build from the scripts. Sorry for creating problems over syntax.

  Grant Fritchey June 05, 2007 07:18

  - 0 +

Add comment

Please sign in to leave a comment.