December 10, 2009 at 7:10 am
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.
January 14, 2010 at 11:41 am
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
January 14, 2010 at 5:05 pm
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.
January 13, 2011 at 1:28 pm
Matt,
Do you ahve any idea how Subversion handles SSRS projects?
Thanks!
Stad.
January 13, 2011 at 1:33 pm
I use it with SSRS every day.
I would exclude the following types of files though (not check them in)
.data
.suo
.user
Since these are user specific they can cause problems if you have multiple people working on a solution.
January 21, 2011 at 5:14 pm
We also use the SVN, but its very defficult to make out the what exactly is changed. Do you know how to understand it.
January 22, 2011 at 9:54 am
Because of how rdl builds I've found adding notes when you commit helps a ton.
January 26, 2011 at 2:27 pm
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.
January 27, 2011 at 11:54 am
Vivien Xing (5/7/2008)
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 & SQL2008
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=341995
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.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
January 28, 2011 at 9:20 am
Marios Philippopoulos (1/27/2011)
Vivien Xing (5/7/2008)
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 & SQL2008
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=341995
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.
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.
January 28, 2011 at 1:42 pm
Vivien Xing (1/28/2011)
Marios Philippopoulos (1/27/2011)
Vivien Xing (5/7/2008)
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 & SQL2008
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=341995
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.
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.
Unfortunately, for the time being I'm stuck with SQL 2008, so I have to make do with the verbuild column of msdb.dbo.sysssispackages.
__________________________________________________________________________________
SQL Server 2016 Columnstore Index Enhancements - System Views for Disk-Based Tables[/url]
Persisting SQL Server Index-Usage Statistics with MERGE[/url]
Turbocharge Your Database Maintenance With Service Broker: Part 2[/url]
July 6, 2011 at 4:25 pm
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.
Viewing 12 posts - 46 through 56 (of 56 total)
You must be logged in to reply to this topic. Login to reply