﻿<?xml version='1.0' encoding='UTF-8'?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/"><channel><title>SQLServerCentral / SQL Server 2005 / SQL Server 2005 Integration Services  / SSIS package version control / Latest Posts</title><generator>InstantForum.NET v2.9.0</generator><description>SQLServerCentral</description><link>http://www.sqlservercentral.com/Forums/</link><webMaster>notifications@sqlservercentral.com</webMaster><lastBuildDate>Tue, 21 May 2013 04:43:03 GMT</lastBuildDate><ttl>20</ttl><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Thank you, Vivian, for submitting a feedback to Microsoft.  I have just added my vote to your post.  Per the comment from Microsoft, this would be fixed in Denali.  My question is, in the meantime, how does one know a package deployment is successful?  For me, I have to do it the hard way - I have to first delete all the existing packages and then redeploy all of them to ensure the server has the latest.  Does anyone have a better suggestion?  Thanks.</description><pubDate>Wed, 06 Jul 2011 16:25:23 GMT</pubDate><dc:creator>jiamin_zeng</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]Vivien Xing (1/28/2011)[/b][hr][quote][b]Marios Philippopoulos (1/27/2011)[/b][hr][quote][b]Vivien Xing (5/7/2008)[/b][hr]I sent a feedback to Microsoft.  Package version feature will be considered for the next major release.  If you have any comments to add on, here is the link:SSIS Package Version Change Tracking Log in SSMS - SQL2005 &amp; SQL2008http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=341995[/quote]Thank you for suggesting this to Microsoft.Adding the ability of tracking last modified date in packages through querying msdb.dbo.sysssispackages will also help in maintaining a Disaster/Recovery environment with the latest changes in production. [/quote]Good point thinking about DR.  I am glad that Microsoft heard our voice.  It took a couple of years to see the change.  Anyone has tried SQL Server Denali CTP yet?  Hope the version tracking feature meets our expectations. [/quote]Unfortunately, for the time being I'm stuck with SQL 2008, so I have to make do with the [b]verbuild [/b]column of [b]msdb.dbo.sysssispackages[/b].</description><pubDate>Fri, 28 Jan 2011 13:42:13 GMT</pubDate><dc:creator>Marios Philippopoulos</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]Marios Philippopoulos (1/27/2011)[/b][hr][quote][b]Vivien Xing (5/7/2008)[/b][hr]I sent a feedback to Microsoft.  Package version feature will be considered for the next major release.  If you have any comments to add on, here is the link:SSIS Package Version Change Tracking Log in SSMS - SQL2005 &amp; SQL2008http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=341995[/quote]Thank you for suggesting this to Microsoft.Adding the ability of tracking last modified date in packages through querying msdb.dbo.sysssispackages will also help in maintaining a Disaster/Recovery environment with the latest changes in production. [/quote]Good point thinking about DR.  I am glad that Microsoft heard our voice.  It took a couple of years to see the change.  Anyone has tried SQL Server Denali CTP yet?  Hope the version tracking feature meets our expectations. </description><pubDate>Fri, 28 Jan 2011 09:20:42 GMT</pubDate><dc:creator>Vivien Xing</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]Vivien Xing (5/7/2008)[/b][hr]I sent a feedback to Microsoft.  Package version feature will be considered for the next major release.  If you have any comments to add on, here is the link:SSIS Package Version Change Tracking Log in SSMS - SQL2005 &amp; SQL2008http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=341995[/quote]Thank you for suggesting this to Microsoft.Adding the ability of tracking last modified date in packages through querying msdb.dbo.sysssispackages will also help in maintaining a Disaster/Recovery environment with the latest changes in production. </description><pubDate>Thu, 27 Jan 2011 11:54:27 GMT</pubDate><dc:creator>Marios Philippopoulos</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>The .dtsx files are absolutely abysmal for source control.  Impossible to merge or get any idea of what was changed from version to version, so the only thing you can rely on are commit comments.  MS could make this so much better by separating the code used to drive developer studio from the steps to minimize the changes to the files.  Perhaps split the files into two or put all the horrible gobbledygook somewhere at the bottom?  Right now they might as well be completely binary.</description><pubDate>Wed, 26 Jan 2011 14:27:36 GMT</pubDate><dc:creator>rock on dude</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Because of how rdl builds I've found adding notes when you commit helps a ton.</description><pubDate>Sat, 22 Jan 2011 09:54:16 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>We also use the SVN, but its very defficult to make out the what exactly is changed. Do you know how to understand it.</description><pubDate>Fri, 21 Jan 2011 17:14:08 GMT</pubDate><dc:creator>vikas.palaskar</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>I use it with SSRS every day.I would exclude the following types of files though (not check them in).data.suo.userSince these are user specific they can cause problems if you have multiple people working on a solution.</description><pubDate>Thu, 13 Jan 2011 13:33:45 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Matt,Do you ahve any idea how Subversion handles SSRS projects?Thanks!Stad.</description><pubDate>Thu, 13 Jan 2011 13:28:08 GMT</pubDate><dc:creator>Stad</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>After some more looking i have the SVN keyword substitution working. Quite simple in fact. On the working directory right click on the folder that contains all the DTSX files - mouse over Tortoise SVN - click properties. Click New then select svn:keywords from the dropdown and for the value entered "Rev" and mark the checkbox to apply recursive this then set the property for every file in the folder. At this point I did a commit since each file was modified. I didn't worry about other files (non-dtsx) since the property will be there but it will not perform the substitution unless the specific string is found within the file contents.Next opened the solution and set the value of the Version Comments property on each package to $Rev$Saved all then committed. Checked the version comments and found the version number in the comments field. Very slick, now I can setup my logging to include the SVN version number.</description><pubDate>Thu, 14 Jan 2010 17:05:27 GMT</pubDate><dc:creator>Tom Van Harpen</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Matt you mentioned using the keyword sub and update the revision comments.From what I read SVN simply searches the document looking for a text string such as $Rev$ and then replaces it with a value such as $Rev: 12 $: This indicates that the revision of the package when committed was 12.Do you simply put the value "$Rev$" into the version comments field. Then on commit will it update the working copy with the committed revision number?thanks</description><pubDate>Thu, 14 Jan 2010 11:41:19 GMT</pubDate><dc:creator>Tom Van Harpen</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>So I implemented the "svn:needs-lock" property to ensure that only one .dtsx package could be owned by a developer but now I'm getting annoying "check-out" prompts when viewing Data Flows.  How are you other SVN users working around this?  In this scenario I'm not wanting to grab a lock on the file, I just want to view it.EDIT:Let me throw some more information at you.  I was experimenting a little and it seems the number of "check-out" prompts is directly related to the number of Lookup tasks in the Data Flow.</description><pubDate>Thu, 10 Dec 2009 07:10:28 GMT</pubDate><dc:creator>Hiawatha Tiller</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>We're starting to use TortoiseSVN and it seems to work well. Previously we just made backup copies in the filesystem. We don't so anything fancy - no solutions or projects, just individual DTSX files.</description><pubDate>Thu, 10 Dec 2009 06:46:07 GMT</pubDate><dc:creator>Tom Winter</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>No I don't see. When does it commit? on every save? If so that's a problem since we can only commit a buildable working version.Red Gate is coming out with a similar product for Management Studio that integrates with Subversion. This will allow us to version all our stored procedures, views, triggers, udf's ect...We are part of the beta group, can't wait.</description><pubDate>Wed, 09 Dec 2009 05:46:26 GMT</pubDate><dc:creator>Tom Van Harpen</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>It simply relieves you of the responsibility of maintaining it. you work on your SSIS packages, whenever you change anything, the history is added into subversion. you dont need to do anything, youre free to focus on your work, knowing that the history is always there in your repository. see?</description><pubDate>Tue, 08 Dec 2009 14:26:03 GMT</pubDate><dc:creator>yonision</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]yonision (12/8/2009)[/b][hr]The following tool, while built for versioning entire SQL Sever (and works with SourceSafe, Subversion and TFS)  - also does SSIS packages:http://www.nobhillsoft.com/Randolph.aspx[/quote]What does this do for SSIS that subversion doesn't? </description><pubDate>Tue, 08 Dec 2009 13:23:20 GMT</pubDate><dc:creator>Tom Van Harpen</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>The following tool, while built for versioning entire SQL Sever (and works with SourceSafe, Subversion and TFS)  - also does SSIS packages:http://www.nobhillsoft.com/Randolph.aspx</description><pubDate>Tue, 08 Dec 2009 13:14:34 GMT</pubDate><dc:creator>yonision</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Where is the version comment property? How do you access this from a package deployed as a sql deployment?thanks, tom</description><pubDate>Fri, 06 Nov 2009 09:23:42 GMT</pubDate><dc:creator>Tom Van Harpen</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>VSS</description><pubDate>Wed, 28 Oct 2009 01:01:37 GMT</pubDate><dc:creator>NIRANJANA1977</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]daphneds (10/20/2009)[/b][hr][quote]And I wouldn't try merging dtsx files using any source code system. We treat them like binary files and use SVN locks to prevent two developers from working on the same package at once. [/quote]We also do this, and it works great.[/quote]Hmmm?  Can I assume that by "We also do this", that you mean that you also use SVN prevent more than  one developer from editing the same DTSX at the same time?  As opposed to "We also" merge DTSX files (which seems like an impossible nightmare)?</description><pubDate>Tue, 20 Oct 2009 16:28:39 GMT</pubDate><dc:creator>RBarryYoung</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]daphneds (10/20/2009)[/b][hr][quote]And I wouldn't try merging dtsx files using any source code system. We treat them like binary files and use SVN locks to prevent two developers from working on the same package at once. [/quote]We also do this, and it works great.[/quote]Agreed, I've done it with VSS and TFS primarily and I never try to do a merge..  All in, all out..CEWII</description><pubDate>Tue, 20 Oct 2009 11:53:25 GMT</pubDate><dc:creator>Elliott Whitlow</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote]And I wouldn't try merging dtsx files using any source code system. We treat them like binary files and use SVN locks to prevent two developers from working on the same package at once. [/quote]We also do this, and it works great.</description><pubDate>Tue, 20 Oct 2009 10:54:55 GMT</pubDate><dc:creator>daphneds</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]Matt Horton (5/1/2008)[/b][hr]You can search for previous versions through SVN, but SQL server doesn't store previous versions as far as I am aware.[/quote]We also use SVN and use its keyword substitution features to populate the VersionComment property of each package to add version control information. That way it is possible to see what revision of a package has been deployed to each environment.And I wouldn't try merging dtsx files using any source code system. We treat them like binary files and use SVN locks to prevent two developers from working on the same package at once.</description><pubDate>Tue, 14 Jul 2009 08:57:09 GMT</pubDate><dc:creator>Andy B-608329</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>I haven't played a ton with dtsx files.  I do know that rdl files it's a huge pain.  Since files are appended from the top, merging is a nightmare.  Assuming dtsx files appending at the bottom, it should be easier.  As a rule, we currently don't allow two developers to work on the same dtsx file.</description><pubDate>Tue, 09 Jun 2009 08:54:10 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Hi, We're also using SVN and wan't to know if there is any possibility that the merge function would work for a dtsx file modified by 2 developers. I can't imagine there would be any way that a source control could integrate 2 sets of mods to a dtsx with the pipeline relying so heavily on the stored meta-data and lineage ID's, it would have to map lineage ID's on a merge and that would be crazy.thoughts?</description><pubDate>Tue, 09 Jun 2009 08:46:31 GMT</pubDate><dc:creator>Tom Van Harpen</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Thank you Matt.</description><pubDate>Mon, 08 Jun 2009 14:46:02 GMT</pubDate><dc:creator>freemant_analyst</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>All those files except the suo and user files</description><pubDate>Mon, 08 Jun 2009 12:19:07 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>I am using VSS, and it works OK with SSIS.  Not great, just OK.</description><pubDate>Mon, 08 Jun 2009 09:25:17 GMT</pubDate><dc:creator>RBarryYoung</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>My mention of Acces is my history.  My question is:  Which files in the project do I need to check in.  I have the following files:Folder: ProjectName     ProjectName.sln     ProjectName.suo     Folder: ProjectName          ProjectName.dtproj.user          FileName.dtproj          FileName.dtproj.user          FileName.dtsxWhich of these files do I need to check in?  If someone new wanted to check out the code and make edits, which files would they need to be able to see and edit the code?Thank you.Tammy</description><pubDate>Mon, 08 Jun 2009 09:21:59 GMT</pubDate><dc:creator>freemant_analyst</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>I wouldn't do the access database, but the rest I would put in SVN</description><pubDate>Sat, 06 Jun 2009 10:09:10 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Hi - I am new to SSIS and I am not too familiar with packages.  I have coded mostly in Access and ETL systems.  Therefore, when you say load the whole package into Tortoise SVN, what files does that include?  I don't want to store more than I need to and not less than I need to.Thank you.</description><pubDate>Fri, 05 Jun 2009 11:45:28 GMT</pubDate><dc:creator>freemant_analyst</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>We have had issues if multiple people are working on the same dtsx package, otherwise SVN handles changes really well.</description><pubDate>Tue, 21 Apr 2009 16:12:57 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>With SVN how are you guys handling the merge process.  From what I've seen with WinMerge or any other diff tool, there are tons of diffs between packages not really related to what the developer did (version #'s, to connection info, SSIS reorganizing things, etc...).  I've tried BIDSHelper to use "Smart Diff" to remove the visual portions of the packages when doing comparisons but at the end of the day we still have to manually merge changes by hand.We are currently a small team, so it can be managed for the time being but I'm curious to see what the solutions are for much larger teams.</description><pubDate>Tue, 21 Apr 2009 15:35:41 GMT</pubDate><dc:creator>Hiawatha Tiller</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>We check in the entire project since this allows you to easily open the project and run it.</description><pubDate>Tue, 10 Feb 2009 10:40:14 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>[quote][b]Matt Horton (1/9/2009)[/b][hr]I'd keep using SVN. We do and it works great.  Any concerns?[/quote]What do you check in to SVN? Just the dtsx files or entire projects?Thanks. Jeff</description><pubDate>Tue, 10 Feb 2009 10:09:16 GMT</pubDate><dc:creator>Jeff-77264</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>I'd keep using SVN. We do and it works great.  Any concerns?</description><pubDate>Fri, 09 Jan 2009 14:01:39 GMT</pubDate><dc:creator>Matt Horton</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Hi,We are planning for SSIS version control at our organisation.what is the best method to implement this?What tool we can you. Currently we are using TortoiseSVN for version control.Guide me please.</description><pubDate>Fri, 09 Jan 2009 13:58:41 GMT</pubDate><dc:creator>Vundela</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>I sent a feedback to Microsoft.  Package version feature will be considered for the next major release.  If you have any comments to add on, here is the link:SSIS Package Version Change Tracking Log in SSMS - SQL2005 &amp; SQL2008http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=341995</description><pubDate>Wed, 07 May 2008 20:05:30 GMT</pubDate><dc:creator>Vivien Xing</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>BTW, I do not see SQL2008 has much change.  There is no modified date or version change history/log in msdb.dbo.sysssispackages.</description><pubDate>Sun, 04 May 2008 09:29:35 GMT</pubDate><dc:creator>Vivien Xing</dc:creator></item><item><title>RE: SSIS package version control</title><link>http://www.sqlservercentral.com/Forums/Topic463182-148-1.aspx</link><description>Just found verbuild can be set manually during SSIS pkg development stage.In MS Visio Studio, open the project, from solution explorer, click SSIS Packages, right click YourPkg.dtsxà Open, from the perperties section, find VersionBuild, you can reset whatever number.  When deploy to SQL Sever, the value shows as verbuild.  It seems an identity type with auto grow by 1 feature.This gives developer the control of the version, but for DBA, it is a puzzle.  Although verid shows the difference, but there is no previous records saved in msdb.dbo.sysdtspackages90 to compare whenever there is a change.“ModifyDate” column will help for DBA.  I am also thinking whether the previous records should be saved as history/log instead of keeping the current pkg info only.Wondering how the others opinion.</description><pubDate>Sun, 04 May 2008 09:22:48 GMT</pubDate><dc:creator>Vivien Xing</dc:creator></item></channel></rss>