This sounds like a simple thing to do, but I am not sure if it is possible ...
If I use TFS annotate, I can determine when each line of code was changed and the changeset where it was changed. This is great for determining when something was added or modified. But what about determining when something was removed?
Does the removal of code appear in an annotate? I don't think it does. If not, how can I detect when some code was removed?
Does the removal of code appear in an annotate?
I don't think so.
Which leaves taking diffs between specific versions, perhaps using divide and conquer to find the specific changeset.
I don't think it is possible, annotation does not show code removal. You can open the History dialog for a File, Ctrl+Select 2 fairly separate changesets and then Compare those and see if the line was there or not. Keep increasing/decreasing the range of the changesets until you find it.
Related
I am facing 2 problems during checkin of design changes in TFS 2012.
When I made the some design changes (for example alignment of buttons), codes in frm file gets rearranged. Which gives me a lot of differences even though there are very few (If I manually cut and paste the code in proper place then I can see only few lines of mismatching)
If there are some unwanted changes in frm files then there will be changes in respective frx files also. My question if I undo (delete the unwanted changes in TFS ) then how can I differentiate between required and unwanted changes of frx files ?
These two things are killing my lot of time. Please help me to solve these problems.
Its not always the case, but usually the amount of churn in generated files like the frm file is caused by people by selectively checkin parts of that file. By selectively checking in parts of a generated file it causes visual studio to make more drastic changes to the file than one would expect beforehand. If you checkin the complete file a few times this behavior should go away. If it still persists, another option would be to swap the merge tooling to something that suits you better https://blog.paulbouwer.com/2010/01/31/replace-diffmerge-tool-in-visual-studio-team-system-with-winmerge/. E.g. winmerge can be modified to ignore moved sections if they are not modified.
Every VB6 project in source control faces this issue. I find it useful to break up my work into many smaller changes, and diff and/or check-in changes only in those smaller chunks. This usually makes it much clearer what actually changed.
As in subject:
Go to "Find Changeset" option.
Find a changeset.
Double-click on changeset to open Changeset Details window.
It gives a list of all files that have been checked in within given changeset.
Why I cannot apply a label on those files from that level where I have them all in one place? Especially, that very often they are part of different solutions and projects, so normally I would have to create a label for one file and then search and add one by one to the existing one.
It is so inefficient!
Is it some bug or lack of functionality? If the second - it is hard to believe MS guys forgot about such handy function.
How do you deal guys with such situation?
EDIT - to clarify my reasoning:
If I use jessehouwing's method - yes, it works and it's simple.
But then when I search in the future for that label and want to see what code was included, it gives me a list of all solutions - even those totally unrelated (IWP and PDPRO are the unwanted ones):
If I use it my way - it gives me that:
I think it looks cleaner and gives directly the information of what solutions and files underneath where included at the time when I put stuff into Production environment and applied corresponding PROD label.
The feature you're looking for doesn't exist. generally a single file or group of files at a label doesn't make a lot of sense. While it's possible to "scope" labels in TFVC, it's only possible through the commandline.
generally you'd create a label at the repo or branch level at the specified changeset. That will include all files, including the ones you just checked in. Creatign such label is relatively easy from the source control explorer, though you need to copy the changeset number:
It's unclear to me why you'd only want the changed files to be included in the label, maybe you can elaborate a little more on that requirement.
Update: What you desire isn't possible from inside VS and isn't simple from the commandline either. I suppose that with a bit of Powershell Magic against the TFS Client Object Model you can do this from the commandline and it should also be possible to build this as a Visual Studio Extension (or maybe suggest it to the author of the TFS Source Control Explorer Extensions.
I'm using TFS 2013 Update 3 and Release Management 2013 with Update 3 (agent-based templates).
In the Release Management client, I'd find very useful the ability to add a comment for any action/component (or even a group of them) that is part of a deployment sequence. This is because often it's obvious what an action/component does (e.g. "Move File or Folder"), but it might be useful to know why that is done, also in the context of that particular deployment sequence.
I haven't found a way to achieve that, is it actually possible?
If not, do you have any alternative solution or do you know if a similar feature is available in newer
versions?
One thing you can try (but I am not sure if Agent-based Update 3 allows it) is to rename the action/component once dropped on the canvas. I know vNext templates allows it, and some earlier versions of Agent-based allowed it (but not the recent one... it seems to be broken).
Another less optimal option would be to add a parameter (which would be ignored during the actual deployment) - call it 'Notes' or similar - and just fill its value with the description of what this action/component does. It is less obvious and you may need to scroll to see it when you have many params, but it would be available. Also, this would only work with custom actions and components.
Last option would be to put your action/component (or group of) inside a 'Sequence'. You can rename those by clicking on the name. That would give some context on what that action(s) does.
It seems that Plastic SCM does not track code moved between files (compare with e.g. Git) Am I right, or is there a way how to switch this feature on?
(Disclaimer: I work for Plastic SCM).
As far as I know git is able to track moved fragments of code between files when you run a "git blame", but it doesn't use this information during merge, correct? Git is able to calculate the "moved fragment" between files if it happens on the same commit and that's what it does while processing the 'blame'.
No, Plastic is not able to do that yet, which is a shame because we're already doing some interesting things around the idea:
First we have semantic method history which is able to track the history of a given method even when it has been moved, renamed and modified, but always inside the same file. We have plans to extend this to a repository wide basis, indeed we were about to implement it by the end of last year but we had to postpone it since we got some other highly requested features to work on.
The 'semantic method history' is based on the SemanticMerge tech we've developed. Right now it also works inside the file, but plans are also to come up with SemanticMerge multi-file (we even have a working prototype already). I expect this to be several steps ahead of what other tools can do.
Applying the last two together it wouldn't be hard to do something like 'blame with moved code', which as you pointed is something really great to have. Hopefully we'll release something like this in the coming months.
A blog states
Labels come with a big warning though - labels themselves are not
version controlled, meaning that there is no way to track or audit the
history of activity on a label. Plus, labels don't keep copies of
versions in case of a file deletion, so if a file gets deleted, any
label that relies on a version of that file is essentially hosed.
This is not the only place I've read similar information regarding TFS labels. The lack of history is clear enough. The second part "labels don't keep copies of versions..." is unclear. In fact, I created a test project > labeled it > deleted a file > performed a Get by Label and the file came back. So what is this referring to? Has the label functionality changed in TFS as of recent?
I realize that a file deletion does not actually remove history, is that the cause? In other words, if I run
tf destroy "$/MyTeamProject/Project/FileName.cs"
Is that what it means to delete a file? If so, that seems an extraordinary circumstance to even consider. I mean, its an intentional unrecoverable deletion of history. Changesets are not going to be any improvement over labels in such a case.
When we apply a label we do so to a version of source control at a point in time. Intuitively, because we initially created a snapshot of source control at a point in time one may assume the snapshot represents source code at a point in time.
This is incorrect. Labels can be edited after creation.
Conceptually, a label defines a product and the product’s bug-fixes (source). A real world example may help. Let’s say we have a product called AlphaBoogerBear. AlphaBoogerBear is a product, not a version (think pre-release Windows names). AlphaBoogerBear can be made into a Label, AlphaBoogerBearLabel. We perform a release of AlphaBoogerBear. There are some bugs. We fix them.
Now, we go back and edit AlphaBoogerBearLabel to include the bugfixes. The label no longer represents a snapshot at a point in time. Instead, it represents the most stable release of AlphaBoogerBear.
Finally, we move to BetaBoogerBear. We have the option to go back and grab a label that represents the old product at its best version in time.
In my opinion, if one requires a snapshot of version of source control it's better to branch. If one requires an edit-able snapshot that represents a product release then a Label is useful. Albeit, it seems a difficult balance of trust and convenience.
As far as the author's intentions, I really can't say for sure. He could mean to say that items can be deleted from a label and thus when you Get by Label the item will be gone. Though, the item is still stored in TFS history so although it is a confusing situation, not all is lost.
I'm not sure what is meant by the sentence about labels getting affected by file deletions. But you have it right, a regular file delete won't affect labels, but a destroy will.
What it's cautioning you about with respect to not being version controlled though, is that somebody can come and edit a label, by including or excluding files from the label, or changing the versions of files included in the label. And there will be no history of these changes to the label definition.
As I understand it, a label in TFS is basically a set/collection of changesets.
Let's say you label a directory with two files in it. The label would then consist of three changesets: one for the directory and one for each file. Deleting one of these files in TFS will produce a new changeset for the directory, so doing a Get by Label at this stage would get the deleted file "back" since it contains the changeset prior to the deletion. Destroying a file would remove it from any changeset records it has appeared in, thus also destroying the information in the label.
Since the label is identified by its name only, it is also very easy to overwrite it with a new label, destroying the old information. The /child parameter to this command can change this behavior somewhat: using /child:merge will keep the changesets that were previously recorded along with the new one, /child:replace will exchange the old changeset with the new. In the example above, none of these alternatives would make any difference, since Get by Label would still retrieve the highest changeset.