Is this a known problem? I am hoping that I wont have to select and merge (or move, or branch..) each file individually.
Thanks in advance for your insight.
MikeH
Can you give an example how you'd like those dialogs to work with multiple files? For instance, if you selected folders A thru D, clicked Branch, and typed "A-mybranch" in the textbox, you'd want it to automatically create "B-mybranch" thru "D-mybranch" as well? That seems like it would cause more problems than it would solve. (I'm sure you can think of many ways to trick that algorithm into doing something wrong.)
I can see where it would be a problem for the branching and definitely see why you would disable multiselect for the branching case.
The actual thing I was trying to do was merging. I thought I should just be able to select a few files to merge, rather than merging an entire folder.
I see now that the GUI dialogs for each of these functions (move, merge, branch) shows the filename for the function end result, and not just the folder in which to perform the function.
I guess the only example I can offer for how things could work are:
1. Leave single file moving, merging, branching as is.
2. Leave multiple file branching disabled. I appreciate your naming dilemma.
3. For multiple file move and merge, allow me to pick which folder in which this should happen rather than the actual file to perform the function on.
Move would create a file of same name.
Merge would merge changes to a same named file.
You certainly know your product better than I do, so maybe these won't work.
Anyway, I appreciate your response.
--MikeH
As you've probably noticed from the behavior of operations like Checkin and History, the preffered atomic unit of change is the "changeset." Recognizing that any single edit is likely to have far-reaching effects -- up to & including breaking the build -- we group them into changesets wherever possible, with the hope that developers check in changesets whose individual changes are in sync with each other. That's why 'tf get' refreshes your entire workspace by default: if you're going to download any piece of a changeset you haven't yet sunc, we prefer that you get all of it.
Merge inherits these design decisions on top of its inherent hazards (namely, there is no way to guarantee that a purely textual parser can safely edit source code). You can do a cherry-pick merge from the UI, but only at the changeset level -- even then, it's recommended only for people who know the before & after state of their codebase very well. Cherry-picking on the basis of individual items can only be done at the command line, where "caveat admin" is implied.
-
I do like the idea of supporting multiselect with Move. Right now Move is just a thinly disguised alias for Rename, and obviously Renaming multiple files poses the same perils as Branch or any other 2-argument command. However, moving multiple files from 1 location to another (single) location is one area where we could use the familiar semantics of filesystem "Move" to safely generalize. This sounds like a good topic to blog about & gauge interest for v2.
