Here is the scenario as best as I can describe it. I'm hoping someone can explain why/how these things can happen.
1. Developer#1 attempts a merge from top of tree to branches\v1.0.x, gets some type of error (maybe SQL error but it put pending changes) Any ideas of what can cause sql errors
2. Due to the error that developer was seeing I (Dev#2) did the merge with no errors and shelved my changes for that developer to unshelve, review then checkin. The developer did this.
3. Developer #3 At some point during the above did a shelve of items they were working on in the branch.
4. Developer #3 notices a branches\v1.0.1 tree with just the files from Developer #1. They also notice some items in the shelve they did show up in v1.0.1 instead of v1.0.x. (What happened here )
5. Developer #2 Realizes v1.0.1 is not supposed to be there and deletes branches\v1.0.1.
6. Developer #3 even after repeated refreshes and GetLatest still sees a plus sign (+) next to branches\v1.0.1 - Though no pending changes were showing. (Why would this be )
7. Theorizing that maybe the shelve that Developer #3 created that somehow got v1.0.1 locations in the shelve was confusing source control explorer I asked him to delete any shelves with those references. After doing that the branches\v1.0.1 tree was no longer visible.
8. In the middle there for Developer #3 - it seemed like some things were checked out to the wrong location in v1.0.1 instead of v1.0.x, relaunching the IDE seemed to refresh that.
Question List
- Why did developer #1's merge go to branches\v1.0.1 instead of branches\v1.0.x FYI - At one time several months ago we had renamed branches\1.0.1 to branches\v1.0.x. I still don't understand why that would happen
- How did Developer #3 get v1.0.1 items in his shelve
- Why did Developer #3 have the plus sign next to v1.0.1 with no pending changes
- Why did deleting the shelvesets containing v1.0.1 items seem to fix the display of the v1.0.1 and remove it from the display
- What caused files to look like they were checked out to the wrong locations
FYI - Some additional information that may relate to this. Developer #2 had just previously deleted the branches\v1.0.x\MyProject and rebranched from the top of tree to there. Not sure if that is a contributing factor or not.
Merge/shelve/Source Control Explorer Strangeness???
AmirAlis
Thanks for the info.
Some comments:
Performance isn't a big concern if that is really what you intended to do, was merge against the tip and you don't have the files, yep you do have to get the whole thing.
Predictability: Updating workspace behing a users back. This is where I think additional workflows should be considered. Perhaps for the purpose of the merge a temporary workspace is created so the user can go back. Or all work gets shelved and the whole users workspace is auto labeled so it can be restored (Some type of version history list for the workspace- to allow the user to undo workspace changes for example). Since this is a standard workflow I think it makes sense to take it and make it a full fledged use case and support the workflow in such a way as to not interfere an already in progress workflow. (Shelving or auto shelving existing work could be supported and keeping workspace version information).
For Get's I would recommend the same thing support an auto save/shelve of work before a Get so the previous code and workspace can always be restored if need be. I currently recommend all of our Dev's do a shelve before a get so they have a fallback in case of a bad merge, it would just be nice if you could restore your workspace as well (To do that some at MS have suggested an autolabel that encapsulates the workspace so it could be restored.).
For merging same named items, clearly this happens and at least not preventing work would be nice. The power tool should help though.
Thanks
ray_newbie_SSIS
That sounds reasonable for the baseless merge aspect. I definately would recommend improving the merge wizard in general to include the other items mentioned as well. It was not obvious initially to several developers as to what was taking place during a merge (in the case it wasn't realized it was merging to a local workspace that was significantly older than the tip.
Rhubarb
There are other reasons not to pend changes against Tip:
- performance: potentially need to Get a lot of files
- predictability: we would be updating the user's workspace "behind their back", potentially breaking their build. all of the arguments we used against "get latest on checkout" apply here.
- conflicts: anytime you run Get you run the risk of conflicts. this isn't a bad thing, but it adds complexity to whatever operation you're doing. you have to to stop what you're doing, go thru the whole Resolve process, then resume -- hard to make that a pleasant user experience.
(For an upcoming Rosario feature, I actually argued that we should pend certain new kinds of changes against Tip. I lost the argument and now agree with the other side.)
Namespace conflicts should be expected. It seems lots of people don't understand that readding or rebranching is NOT the same as undeleting. You're creating brand new items. Maybe that's what you wanted, but I have a feeling most of the time some other operation (undelete + merge or undelete + rename) would be more appropriate.
The best workaround is tfpt unshelve /migrate which should be in the next PowerTool release.
ReneeC
Merges work like all other pending changes: they are pended on your workspace. Any differences between your workspace and tip are resolved upon checkin. So in your case, if Dev #1 had tried to checkin, it would conflict; Resolve would bring the rename into his workspace. The problem with trying to pend changes against tip is that it's a moving target.
Note: branch and merge DO use the tip as the default version range. That is, by default, branch will branch all of source (including items you may not have in your workspace yet) and the same for merge.* But those changes will still be pended against the workspace version of target. I hope that makes sense.
The shelveset would have the old names stored since it was created after the checkin of the rename. (As mentioned, pending changes & shelvesets are updated during checkin.) Turning on logging might offer a clue.
*Unless you have SP1/Orcas, and you use local paths at the command line
jeff357
The basics of how TFS handles items won't change, but we're making a couple improvements that should smooth the rough edges.
71M
A related question, are shelvesets supposed to effect what you see in source control explorer
Debabrata.debroy
Was there ever another folder named v1.0.1
Did the merge really go to the wrong location Was the old name shown in the dropdown on the 1st page of the Merge Wizard That should only happen if Dev #1 had not run Get on the folder since before the rename.
Strange.
Donnieb
I definately think that MS should seriously consider the merge to tip of branch, as that is a normal developer workflow, having to do the get prior to the merge is somewhat out of an expected workflow. When I think of merge changesets to a branch, I typically want to merge the changesets to the top of that branch (Yes there could be cases where you are merging to work in progress), but often in many shops when you create a release branch you merge only critical changes to it and usually the top since that represents your release. Even though it is a moving target it fits the workflow better of someone doing integration/merging to a branch better than allowing them to merge to a potentially old workspace on their machine. Otherwise you always have to remember to do a Get latest before you merge. That's not to say you should always do that. It should just be a clear option as part of the wizard that does merging. I think that would be enough to clarify it.
For the shelveset unfortunately now we deleted those shelves which resolved the issue, not sure if we could reproduce. We'll try a couple things and see if anything shows up.
The other issue we noticed but I guess shouldn't be too surprised, that after a rebranch of code someone that had shelved on the old code when they unshelve gets all sorts of naming conflicts... not quite sure what to do about that one. We were'nt thinking about the impact on shelvesets when we rebranched, I guess we have to think about that now unless the future holds some improvement for that scenario. I guess the key is, it should never be hard for developers to recover code they saved. There should always be a way to force the code out, as developers rely on shelving as a form of backup.
Pati123
Ah... That may be it (doesn't explain the sql error, but...). That workspace may have been a long time since Dev#1 did a get on their box (possibly never or very early). So in that case if there was an early version it would merge based on what you currently have on disk and not necessarily the latest code in source control I guess that makes sense, it's just a workflow that developers are not typically used to here. Also I wonder if there should be some type of warning on merge to indicate you are merging into a tree that is not the latest. For people that don't normally work with the branch they just need to merge one change they figure ok, merge my changes with the top of the branch and presume merge is doing that for them... but really it is merge with the source on their box. Probably some type of indicator is warranted. (When doing checkins or checkouts directly it is significantly more obvious the code on your box itself is merged.) When initiating a branch to branch merge often times I always want to merge with the top of the tree of the release branch ( perhaps that should be an option in the wizard )
Ok that would explain how the first one happened, I had thought that might be possible but didn't have a chance to verify.
The next issue of seeing the folder that was deleted with a plus next to it, even though there were no pending changes.
Also how did the dev #3 shelve get the v1.0.1 branch, we are not sure.
The thing with deleting the shelveset clearing the SCE was strange, makes me wonder if there is some query being done on determining an add that accidentally picks up shelveset information (we already know there are other cases of that happening, so that shouldn't be too surprising.)
mikebk
SCE does not handle situations where more than 1 item exists in a slot very well. Renames and delete + readd/rebranch can both cause this. Restarting VS usually helps.
It's hard to say exactly what you saw since you probably hit one or more SCE bugs that obscured things. If you see weird effects again, use the command line to find out what's "really" on the server, then we can debug from there.
SQL Errors are always bugs.
Shelvesets shouldn't affect what you see, unless you unshelve them of course. Whenever you checkin a rename, the server updates every pending change and every shelveset with the new name. I don't think there are any known problems with this. Again, it sounds like an SCE issue.
Fusion54
In the case of more than one item in a slot, the rename was done months ago, thus should have been a new name. So not sure why the merge went into the wrong location (the original rename).
I used team foundation side kick at one point that showed no checkouts to Dev #3 on v1.0.x but his IDE showed he had checkouts even after closing and re-opening the IDE (FYI this is all with SP1 on the server... have to check the client to be sure.).
The SQL error I should have got a screen shot from the developer, unfortunately might be too late now.. Maybe I'll see if I can get him to reproduce it might be reporducible.
The shelveset thing it was pretty clear that deleting the shelveset seemed to immediately fix the SCE UI to not display the plus next to branches\v1.0.1 which had been deleted.