views:

129

answers:

5

Here is my use case:

I start on a project XYZ, for which I create a work item, and I make frequent check-ins, easily 10-20 in total. ALL of the code changes will be code-read and code-reviewed.

The change sets are not consecutive - other people check-in in-between my changes, although they are very unlikely to touch the exact same files.

So ... at the end of the project I am interested in a "total diff" - as if there was a single check-in by me to complete the entire project. In theory this is computable. From the list of change sets associated with the work item, you get the list of all files that were affected. Then, the algorithm can aggregate individual diffs over each file and combine them into one. It is possible that a pure total diff is uncomputable due to the fact that someone else renamed files, or changed stuff around very closely, or in the same functions as me. I that case ... I suppose a total diff can include those changes by non-me as well, and warn me about the fact.

I would find this very useful, but I do not know how to do t in practice. Can Visual Studio 2008/2010 (and/or TFS server) do it? Are there other source control systems capable of doing this?

Thanks.

A: 

Since diff is just done between two, a base and a target, I think you want to diff the empty project and the final project.

If this is the case, then Visual Studio cannot do it.

There are source control systems capable of doing this. What you are looking for is the blame feature in svn

Mahesh Velaga
Well, VS2008 also has a "blame" feature. That works on individual files. Also, svn is not the top notch system from what I have heard. There must be a more advanced tool out there.
Hamish Grubijan
@Hamish: Could you please tell me how to access that blame feature in VS2008? Thanks
Mahesh Velaga
http://www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html\One way: open file for edit, right-click, select source control -> annotation (or something like that).
Hamish Grubijan
I think its not a feature directly in Visual Studio as it needs to integrate to some version control system, VS inherently doesn't have a version control system. For example, Visual SVN is used to integrate it with svn, I still think that u give a try to svn.
Mahesh Velaga
It's a feature of the TFS powertoys, if you're using Team Foundation.
Dan Puzey
+3  A: 

You can certainly compute the 'total diff' yourself - make a branch of the project from the revision just prior to your first commit, then merge all your changesets into it.

I don't think this really is a computable thing in the general case - only contiguous changesets can be merged automatically like this. Saying it's 'unlikely' for others to have touched the files you're working on in the interleving commits doesn't cut it, you need guarantees to be able to automate this sort of thing.

Jim T
Well ... but checking that could be automated, right?
Hamish Grubijan
+3  A: 

You should be working on a branch of your own if you want to be able to do this easily.


The ability to generate diff information for display or for merge purposes is functionality provided by your version control system, as Mahesh Velaga commented on another answer. If you were able to compute the diff by cherry-picking non-contiguous changesets, then logically you would also be able to merge those changes in a single operation. But this is not supported by TFS. So I strongly suspect that the construction of the cherry-picked diff information is also not supported by TFS. Other version control systems (git, mercurial, darcs come to mind) might have more support for something like this; I don't know for sure.

From my reading of their answers on the TFS version control forums, I think that their recommendation for this would be to create a branch of your own for doing this work in the first place: then the changesets would be contiguous on that branch and creating the "total diff" would be trivial. Since it sounds like you are working on an independent feature anyway (otherwise a diff of only your changes would be meaningless), you should consider having an independent branch for it regardless of whether your version control system is TFS or something else.

The alternative is to construct what such a branch would have looked like after the fact, which is essentially what Jim T's answer proposes. You might prefer that approach if your team is very keen on everyone working in the same kitchen, as it were. But as you are already aware, things can get messy that way.

Zac Thompson
A: 

Create two workspaces. Get Specific Version for files specifying the date or upto those two changeset on those two workspace. Now compare folders using a compare tool. Araxis merge is best one.

Ismail
A: 

sounds like you need a tool that supports changesets (changes over multiple files and committing them all at once) instead of committing each file alone

take a look at this comparison between sourcesafe and mercurial ( free and you can find tools to integrate it with visual studio )

ThanosPapathanasiou
Visual Source Safe is obviously useless. How does mercurial compare with TFS server 2010?
Hamish Grubijan