Ryan562035

Hi, I'm working on a little utility to do batch work item merges between projects, and have found that when I try merging a file that is a change of type delete, it cannot pull up the versionspec for that file on it's changeset.

My immediate thought is, like clearcase, it should be recognizing the delete operation as a change to the parent folder and therefore I should just pass in the parent folder with that changeset as the versionspec rather than the specific file. However, when I actually look at the changeset itself it lists the file with a delete rather than listing the folder.

My question is, is the reference in the changeset of the file being the change just semantics, and what I really need to be passing in is the folder Or what item do I actually merge in the event of a delete ChangeType If I do pass the folder with the versionspec of that changeset will it even find the versionspec, and or grab it appropriately to what I am looking for

I know cherry pick merges are not everybody's preferred method, but I don't get to make the decisions about how this is done, I merely implement the decisions of others, so please don't just tell me not to merge by work item. I'll keep poking at it myself and if I find the answers I'm looking for, I'll post them here.

Thanks.




Re: Team Foundation Server - Version Control Question about merging a delete operation

Ryan

Ah- I have a thought, I'm thinking I could do a recursive merge on the folder at the date of that changeset, then have it undo pending changes on all but that file in the folder I recursed in the target project. Can anybody tell me how this will draw a line for the source of the merge I'm guessing it will just say in the changeset in the history something like Merge;Delete; and say source: $/SourceProject/blabla/folder;MM/DD/YYYY or something to that tune, yeah

Thoughts anybody Think I might give this a run and see what I come up with.






Re: Team Foundation Server - Version Control Question about merging a delete operation

Ryan

Ok, so I can merge my deletions like this just fine, but now comes the problem of renames. If I merge a rename, it merges the new file just fine, but I do not know how to identify what it's previous name was, so wont know how to identify which file to delete, completing the rename operation.

Any thoughts how I can trace this back Could I pull the new named file up with a version spec of a date immediately before the rename changeset's checkindate, or would this hold the new name or just pretend it didn't exist






Re: Team Foundation Server - Version Control Question about merging a delete operation

Richard Berg MSFT

Yes, we really do record a delete on the file. File records don't "belong" to the parent folder as in SourceSafe (to pick an example whose architecture I know more about). In TFS, to greatly oversimplify, moving / deleting a file just means writing a new server path / deletion ID to the version table.

As you've discovered, Merge doesn't let you specify deletion IDs in the versionspec. This is similar to the label problem. The simplest way is to do a cherry-pick merge on the parent folder. Merging up to a date and undoing the other files should produce the same end result, but is more prone to error.




Re: Team Foundation Server - Version Control Question about merging a delete operation

Richard Berg MSFT

I can't follow your scenario. Can you summarize the changes on both sides and what you're trying to merge For example:

changeset | source | target
-----------------------------------
10 | del foo |
15 | | ren foo -> bar
20 | edit bar |

In this case merging #10 should "just work" -- Merge will pend a delete on bar without any conflicts or manual tracking.

Tracking the various names of an item over time is a tricky from tf.exe. It's much easier when you can call VersionControlServer.GetItem() directly, like you can from PowerShell.
$item = vcs.GetItem("$/known/name", known_changeset, false)
$otherName = vcs.GetItem($item.ItemId, desired_changeset, false).ServerItem