ACKH

Hi all,

Because TFS does not allow renaming on Team Projects (TP) we created a second one with the new name and moved everything from the TP with the wrong name to the TP with the new name. However there is one small problem: When I try to get a file from TFS that belongs to a changeset that was checked in before we moved the stuff source control explorer claims that I already have the latest version. Get specific version with the force option doesn't help. Can someone confirm that behaviour Is there a solution to it

PS: Please tell me that it is possible to renames TPs in a later version of TFS.

Regards,

ACKH



Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

Michal Malecki - MSFT

Hello,

unfortunately I have bad news for you. When you do get in SCE and you specify version before the rename, you end up requesting item that does not exist - in the specified point of time there was no such item (it was created later, by rename).

The only workaround is to use command line and specify the old name (before the rename) there.






Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

ACKH

Thanks for your answer. It is somehow unsatisfying. I hope Team Project renaming is implemented in future TFS versions.

Regards,

ACKH





Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

KenOSmith

I am experiencing the same problems. We did not delete the old team project due to history not being visible, so we were able to perform the Get on the old project using Get Specific, but this is not the acceptable, since this deletes all files from newer project.

You mentioned a command line to perform. With this example, what would be the exact command to get specific version prior to rename. What is the command line specifically and what is the path that you run it from

$/Old/Code/file.cs // Change Set 1

$/New/Code/file.cs // Change Set 2 (move/rename)

$/New/Source/file.cs // Change Set 3 (rename)

Workspace: $/New mapped to C:\TFS\New

What is most disappointing is you can compare versions in SCE, but cannot get the version of the what you are comparing with.

-Ken





Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

Richard Berg MSFT

tf get $/Old/Code/file.cs /version:1

You can run it from anywhere inside your workspace. You'll need to make sure $/Old has a valid mapping though.




Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

KenOSmith

I have $/ mapped to C:\TFS

When I do "tf get $/Old/Code/file.cs /version:1", I get "All files are up to date." and no files are retrieved. I tell it to do a /force and I still get same error message.

In the changeset, there were two files, and I specified only 1 file as shown.

So I changed to "tf get $/Old/Code/ /version:1", status shows "Replacing Code (moved from C:\New\Code)", then I get error "C:\New\Code cannot be deleted because it is empty."

So I deleted the C:\New\ folder, performed again, and I was finally able to get the older files. As I stated before, this can be done by browsing to old team project in source control and do a Get Specific and specify the changeset. The only problem is it deletes the $/New/Source folder where the file is presently located.

Is there anyway to perform this without deleting the folders in the $/New

Will the same thing happen whenever I rename a folder or move files within the same Team Project as well





Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

Richard Berg MSFT

Yes. That's the whole point of renaming something.

If you really want to work on old files but not in the old location, create a branch.




Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

Eugene Zakhareyev

I'd think that you would want to create separate mappings for the folders prior to rename and after the rename. Then you can do whatever you want without fear of files being deleted.

TFS actually attempts to sync your local folder for you, so when you specify some changeset in the past where renamed file did not exist yet (it had old name still) it will be deleted as part of the synchronization.

Regards, Eugene






Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

Richard Berg MSFT

So long as the old & new paths are both mapped, nothing should be deleted. The files will simply be moved from one place to another. Deleting only happens when there's a problem with the old path.

The "error" above is just a warning. It's telling you it can't move (or remove) the new path because it contains some files not under TFS' control. TFS will never touch files it doesn't control. As you discovered, fixing the problem and running Get again will clean things up.




Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

KenOSmith

So basically, you can only have one version of a file in your workspace at a time and since it was moved/renamed then the older version must reside in its old path.

I am able to get the whole directory of files, but am unable to get a single file from a changeset.

If I try, I get warning All Files are Up to Date, and retrieves nothing.

To get the single file, I have to delete the entire folder that contains the latest version of the file, then perform the get on the folder, not the file.





Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

Richard Berg MSFT

So basically, you can only have one version of a file in your workspace at a time and since it was moved/renamed then the older version must reside in its old path.

Good summary. Again, if that doesn't meet your needs, it's a very good sign you should be working in a different branch.

I am able to get the whole directory of files, but am unable to get a single file from a changeset.

If I try, I get warning All Files are Up to Date, and retrieves nothing.

That doesn't sound right. tf get $/oldpath/file.cs;1 should work. Are you sure file.cs existed at changeset 1 Maybe it was added sometime after $/oldpath was. tf history $/oldpath /r /fBig Smileetailed /slotmode should help sort things out.





Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

KenOSmith

When I do the tf history command, I get "No history entries were found for the item and version combination specified."

When I do a file history from SCE, I can see the file listed under the changeset (94743: see below).

I don't know if this caused the problem, but the changeset that we are trying to get the single file from is a SourceSafe checkin, not a TFS checkin.

Chronological Order (with actual change numbers)

Change 94743: file modifed and checked in (in SourceSafe, prior to migration)

Change 154942: files moved to new team project

Change 154943: a parent folder of the file was renamed

Also, branches didn't make sense here because we wanted to retain the full history of the file since we were doing a project team "rename" by creating a new team project. We will be using branches for product releases (in case we need to go back and fix something in v1.0 while working on v2.0).





Re: Team Foundation Server - Version Control Moving all stuff from one Team Project to another leads to problems

Richard Berg MSFT

Bottom line, if a file named $/old/file.cs existed at time 94743, tf get $/old/file.cs;94743 should retrieve it. I can't tell for sure whether that's the case.

To elaborate on my branching comment: when you Get back to an old version, it's essentially a read-only operation. This is great for looking at old code or regenerating an old build. When doing so, you want the environment to be exactly the way it was at the time, including all files having the names they did (otherwise your build could be different, if not outright break).

You can't edit old versions. Well you can, but when you checkin you'll be prompted to merge all of the changes between then & now. If you want to rollback all those changes then that's one thing. But if you want to go back and work on your old release in parallel, you need a branch. Sounds like that's your plan.