Merging Labels

Merging Labels

• Matthew Power

  Hi Richard,

  I'm having the same problem when I try to merge from a label I've created. My tree structure is as follows:

  $TeamProject

  $root

  |->A

  |->B

  |->B1

  |->B2

  When I made the labeI I've applied it to items found in B (such as B1 B2). Offcourse when I look at the contents of the label I can see all the changesets/items that were included in it.

  What I'm trying to do is to branch from this label to from a folder under A. when I make the branch (right click on B->branch) I get the same error - no items match $TeamProject/A in the label mylabel@$Teamproject.

  What am I doing wrong am I missing something here I've done branches (not from labels) and it worked fine.

  Ofir

  
  

• Laz

  The $<frompath> was the immediate parent directory that contains all files with this label. As such, nothing was implicitly omitted. And the changeset-based merge, using the exact same "from" and "to" path, worked fine - getting every single file that the label had referenced (since that label consisted of precisely the two changesets I chose in the version spec).

  In short, merging labels evidently isn't operative.

  
  
  

• motostamp

  Are you sure the error message mentions $/TeamProject/root/A It should mention the source branch (B).
  
  In any case, the problem is the same: the root of the source has to be included in the label. Adding B1, B2, ... to the label isn't enough. Make sure the label includes the $/TeamProject/root/B directory itself.
  
  

• edukulla

  Ok, I understand. But if a label represents these two files:

  "foo.cpp" 10/10/2006 4:00pm

  "bar.cpp" 10/5/2005 7:00am

  ...then those timestamps should be resolvable to changesets. Perhaps the closest changeset to the timestamp for "foo.cpp" is 3279, and for "bar.cpp" it may be 1173. And of course, if I were to ask TFS to merge 3279 and 1173, I'd have no problem at all. So it feels like this comes full circle - that TFS should have no problem using a label to merge, even though the label did not reference a common folder ancestor (the changesets did not reference a common folder ancestor, and they will merge just fine).

  I'm not trying to be a nuisance re-hashing this, but somehow the limitation just isn't making sense.

  
  
  

• Mortsdeh

  Not sure what you mean by "operative." I'll admit that merging by label -- we call it an "intersection merge" -- is complex. If we added more intelligence, eg to implicitly add the root to the label in cases like yours where it seems unambiguous, it would just become even more complex.
  
  

• Bear S.

  Hi Hurleyj,

  I understand what you and Richard meant but the problem for me is that if I include $\Project\Trunk\Foo in the label it will take all the sources under it and that's not what I've wanted in the label. I wanted the label to contain only ceratin folders under "Foo" (as I've showed in my example) what can be done in this case

  Thanks

  Ofir

  
  

• sschleicher

  Labels and changesets are very very very different.
  
  http://blogs.msdn.com/bharry/archive/2005/11/18/494439.aspx
  
  

• Azriel Cross

  There are 2 major differences between label versionspecs and changeset versionspecs.
  

  1. Changeset versionspecs and dates are equivalent. Labels refer to multiple points in time.
     
  2. Changeset versionspecs represent the state of the entire repository. Labels refer to a subset of items.

  You're accounting for #1 but not #2. With simple versionspecs (changesets and dates), all Merge needs to do is recursively expand the root path. That's still fairly complex because it treats namespace changes (delete, undelete, rename) as first-class operations but at least you can't hit the issue seen in this thread. With label & workspace versionspecs, Merge needs to do all that PLUS do an intersection of the recursively expanded paths with the set of paths contained in the label/workspace. If your merge root is not in the label then *poof* there are no rows returned.
  
  Also, you can't really "merge a changeset." Merge operates on changeset ranges. By default if you only specify 1 versionspec then the start of the range is the previous merge (in any) -- that's usually what you want (a "catch-up" merge), but it's NOT the same thing as merging foo.cpp @ 3279.
  
  Sorry if these explanations make no sense. Whenever I try to explain where a specific issue comes from in a forum thread, I have to basically start telling the story in the middle. I'm writing a series of blog posts that starts with a good mental model and then works out scenarios like these. Hopefully reading it that way will make more sense.
  
  

• jh0483

  If you use the command line, Foo can be added to the label without adding its children.
  
  tf label myLabel $/Project/Trunk/Foo
  
  

• EWoodruff

  While I am very appreciative of your response and help...from the "outside" it still seems very strange that performing the merge via equivalent changeset(s) - which do not have "the root of the source included" - works just fine. It just seems that labels should be capable of the same flexibility as the changesets. I mean, I tend to think of a label as nothing but a moniker for a changeset(s).
  
  

• vlamak

  I think what Richard is trying to point out is in your label you don't have the path which you are trying branch. Atleast that is what the problem was for me. For example:

  Source of Branch - $\Project\Trunk\Foo

  Target of Branch - $\Project\Source\Foo

  Label Contained These items:

  $\Project\Trunk\Foo\UI

  $\Project\Trunk\Foo\Doman

  $\Project\Trunk\Foo\Persistence

  $\Project\Trunk\Foo\UI\Blah

  The label didn't contain an item which is equivalent to the Source of the Branch. Once I added this to the label I was able to branch successfully.

  
  

• Thomas Ivarsson

  My guess is that $<frompath> is not included in the label. It's not good enough to include some of its children -- the root must be included for it to work.
  
  
• Merging Labels