I have recently experienced a strange problem in tfs source control . I added some code in two different parts of n-tier solution in visual studio 2012; code behind aspx.vb file and class library project, they appeared in pending changes, I checked-in and did something else in the project but later on I found the changes I made in the code are not there anymore.I checked the view history from source control explorer and those changes are not shown in view history. However If i update existing code base now and do check-in pending changes they are showin in view history. Can any body tell why in first place checked-in changes are gone from tfs or is there anything I can do to retrieve those changes. TFS server is 2008
Thanks
I would suggest that there was something wrong with the workflow you used to perform the first checkin. Checkins are atomic so you can't have some files checked in an others not.
The most common scenario would be that the scope of your checkin was incorrect.
Note: You should move ASAP to upgrade your TFS server to 2013. TFS 2008 no longer revives servicing.
Related
I have problem that is all my team members are altering the Sps and functions and
some conflicts occurred through the development
is there anyway or tool to store and get all version of them ?
the problem is before releasing the new version, i don't want a tool to compare difference between two databases like what Red gate SQL_Compare
thanks in advance
You may make use of the features in Visual Studio and TFS(or any other source control mechanisms). All that you need to do is to
Create a SQLServer DB Project in Visual studio and configure it to
your desired database.
Bind the project to a source control (TFS,
SVN etc.,)
Every time you have a change in DB, you can just compare the changes using .scmp file and click update.
You may refer this post for more information:
http://candordeveloper.com/2013/01/08/creating-a-sql-server-database-project-in-visual-studio-2012/
Background:
I have a MS SQL Server database and I want to track changes to it. For example if a column needed to be added or removed or a table needed to be dropped. Something similar to Version control for regular code.
The problem:
While looking around I saw that there were some tools that can be used:
RedGate SQL Source Control
Visual Studio Database project
I am more interested in knowing if either of these tools will track changes to my database? More specifically I have a TFS server that is the source control for my MVC code, can I use either of these with TFS? Will it allow us to restore from older versions? Will it allow multiple developers to work on the database simultaneously?
For this type of work, ApexSQL Source Control shown to be all that you need. With this SSMS add-in you can work directly on a database, and all of your changes will be tracked in real time.
Yes, several developers can work in the same time on the same database. When one developer works on a one or several objects, other developers can see which those objects are, and until the first one does not finish changing the others cannot change that object, they will not be allowed to.
If by any case, object is changed wrong, previous version or any earlier version can be restored at any moment.
This add-in has all necessary options and features to allow the developers to work without losing time for checking changes made against object, since the add-in does that for them. And you can always see by whom, when and what that change is.
Being in the database version control space for 5 years (as director of product management at DBmaestro) and having worked as a DBA for over two decades, I can tell you the simple fact that you cannot treat the database objects as you treat your Java, C# or other files and save the changes in simple DDL scripts.
There are many reasons and I'll name a few:
Files are stored locally on the developer’s PC and the change s/he
makes do not affect other developers. Likewise, the developer is not
affected by changes made by her colleague. In database this is
(usually) not the case and developers share the same database
environment, so any change that were committed to the database affect
others.
Publishing code changes is done using the Check-In / Submit Changes /
etc. (depending on which source control tool you use). At that point,
the code from the local directory of the developer is inserted into
the source control repository. Developer who wants to get the latest
code need to request it from the source control tool. In database
the change already exists and impacts other data even if it was not
checked-in into the repository.
During the file check-in, the source control tool performs a conflict
check to see if the same file was modified and checked-in by another
developer during the time you modified your local copy. Again there
is no check for this in the database. If you alter a procedure from
your local PC and at the same time I modify the same procedure with
code form my local PC then we override each other’s changes.
The build process of code is done by getting the label / latest
version of the code to an empty directory and then perform a build –
compile. The output are binaries in which we copy & replace the
existing. We don't care what was before. In database we cannot
recreate the database as we need to maintain the data! Also the
deployment executes SQL scripts which were generated in the build
process.
When executing the SQL scripts (with the DDL, DCL, DML (for static
content) commands) you assume the current structure of the
environment match the structure when you create the scripts. If not,
then your scripts can fail as you are trying to add new column which
already exists.
Treating SQL scripts as code and manually generating them will cause
syntax errors, database dependencies errors, scripts that are not
reusable which complicate the task of developing, maintaining,
testing those scripts. In addition, those scripts may run on an
environment which is different from the one you though it would run
on.
Sometimes the script in the version control repository does not match
the structure of the object that was tested and then errors will
happen in production!
There are many more, but I think you got the picture.
What I found that works is the following:
Use an enforced version control system that enforces
check-out/check-in operations on the database objects. This will
make sure the version control repository matches the code that was
checked-in as it reads the metadata of the object in the check-in
operation and not as a separated step done manually. This also allow
several developers to work in parallel on the same database while
preventing them to accidently override each other code.
Use an impact analysis that utilize baselines as part of the
comparison to identify conflicts and identify if a change (when
comparing the object's structure between the source control
repository and the database) is a real change that origin from
development or a change that was origin from a different path and
then it should be skipped, such as different branch or an emergency
fix.
An article I wrote on this was published here, you are welcome to read it.
If you're looking for a product that will track changes into TFS from your SQL Server automatically, I'd invite you take a look at our product, Sql Historian. It's different from most other SQL version control systems (including the ones you've listed) in that it does not require developers to perform a check-in ritual to synchronize version control with what's already committed to the db.
However, features common with Sql Historian and the other two systems you mention are: working with TFS, the ability to view older versions of your db objects, and allowing multiple users on the db at the same time.
I am working in the configuration part of the application, so i am new to this data base side configuration.
Database Oracle,SQL,DB2
I need some clarifications on below Questions:
How to monitor the database changes.
How to Track the changes in the database with any specific tool or script
How to roll back the database if to any specific point of change (like we are doing in source control management).
How compare last two changes in UI or with help any other tools.
You should check IBM Data Studio. Of course you can track changes made by Data Studio itself. If you issue a DDL statement outside of the Data Studio, Data studio will not be aware of that.
I deleted a project folder in TFS, without realizing and checked in pending changes as well.
The local project copy was in offline state and I mistakingly made it online. Because of this I lost the only copy I had. Is there a way to restore the project? I know this is foolish and careless but I made the mistake already. Please help.
check this : here
In Team Explorer (in Visual Studio): Tools | Options | Source Control | Visual Studio Team Foundation Server and select Show Deleted Items...
Then in source control explorer you'll see the items greyed out. You can right click on them and Undelete. (This option will only be available if they, after the undelete, will be included in your current workspace).
Alternatively using the TFS PowerToys you can look at history and right click to select "Rollback Entire Changeset": this will create pending changes to revert the changes of the selected changeset.
How do I change process template to MSF for Agile on an already existing team project in TFS 2010?
We have upgraded our TFS 2008 to 2010, and now I would also like to change the process template to MSF for Agile (currently CMMI).
We haven't used the workitem functionality much so if some information gets lost in the conversion doesn't matter.
Once you've created a Team Project, you unfortunately can't just upload a new process template. As Robaticus says, you'll have to download the XML for the template and modify it, then re-upload it. The power tool lets you create NEW templates for NEW team projects, but it won't modify an existing one.
Instead, you can use the witadmin.exe tool (on any computer with Team Explorer installed, under \Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE, or just from a Visual Studio Command Prompt) to export the current workitem definitions and re-import them once you've made your changes.
Luckily, if you're not using workitem tracking much, then this might not be too difficult. You might be able to just delete all the existing workitem types and then re-upload the new types.
If this is too much trouble, consider how much you want to retain your source control history. It might be worth creating a new Team Project with the Agile template and then just moving all your source code into it.
You can't change the process template, however you can change the work item types. So for bugs, tasks you can swap to the Agile definitions.
You can do this in 2010 with witadmin, in 2008 it's importwit, by first downloading the template to disk (you'll need the TFS power tools for this). Then point the console app at bug.xml, task.xml etc..
Usage: witadmin importwitd /collection:collectionurl [/p:project] /f:filename [/e:encoding] [/v]
/collection Specifies the Team Foundation project collection. Use a fully specified URL such as
http://servername:8080/tfs/Collection0.
/p Specifies the team project in which the new work item type is imported. This is required, except when
the validation-only option is used.
/f Specifies the work item type XML definition file to import.
/e Specifies the name of the .NET Framework 2.0 encoding used to import the XML file. For example,
/e:utf-7 will use Unicode (UTF-7) encoding. Encoding is automatically detected whenever possible. If
the encoding cannot be detected, UTF-8 is used.
/v Validates the XML definitions for the work item type, link type, or global workflow without importing
them.
You can export the agile process template to disk, then import the work items into your existing project. You may need the TFS Power Tools to do this.
I may be too late for this question, but the TFS Integration Platform tools could really help here.
See this question on server fault that details on how to move from Scrum For Team System V2 to Microsoft Visual Studio Scrum 1.0.
You would need to setup your own mappings to move from your templates to the target template, but the process is the same.
Please note witadmin.exe could help in some scenarios but TFS Integration Platform is your ultimate choice to achieve this task. There is a user voice item still pending. Please check this SO thread.
I think the best way to accomplish this is to create a new Team Project with "the new" process template and use the TFS Integration tool to migrate your existing WorkItems and choose create a new branch from Source Control, so you'll have new work Items (with the new workflow) and the source control history (as well). You'd even do this across versions of TFS!! (On the case interested on migrate TFS 2005/2008/2010)
Another way might be to use the WorkItem Templates, but I think this is more a kind-of visual style (I've not much experience) applied to the Work Item. To do so, just right click on your project, import the WITDefinition and apply the template by selecting Apply template on desired WorkITems.