How can you get a list of all the files under a team project that have changed since a particular label was cut on that team project
get list of files changed after a specific label
Hot Topic
- sorry about this!
- Problem with DataGridView CheckBox column - Please Help
- How to write a file (I´m a novice)
- Reading/processing Hex ASCII text file
- please..... i want to know
- Unable to edit Areas and Iterations in some projects
- Permission - How do I deny delete access only for contributors?
- Multiple vsmdi files
- database update
- Making the Exit Button not shut off the application
VS Team System
- How can I tell how many times my web test ran within the load test?
- Problems Install Visual Studio Express
- New projects fail to run
- BackGroundWorker
- Create Database on Real time
- c-mon guys..help me out
- re date difference
- Test List Results and Reporting
- pressing return key as an event
- Centering image in picturebox?
get list of files changed after a specific label
Luc Seguin
I would appreciate your team considering this enhancement. I might be in the minority, but it would be nice to have a straightforward mechanism to find files that have been modified after the label was cut. Thanks again!
sart479493
...and you can find just such a program at http://support.larucorp.com/blogs/carld/archive/2006/07/27/77.aspx if you're interested in exploring that path.
Jon Braganza
fhunter
Buck, that's exactly what we are using labels for. I just wanted to make sure that I'm adhering to development best practices.
The book I read is "Software Configuration Management Patterns: Effective Teamwork, Practical Integration".
DanO84
knvb
Thanks for the knowledge imparted on this subject. Regarding your last paragraph on only using labels rarely, I would like to ask some further questions. We are cutting labels for particular release numbers. We then branch on the label to fix any production bugs. Since we previously used VSS, we avoided branching and merging like the plague...so we're new with the best practices for branching and merging. I read a book on software configuration management patterns and took a liking to the mainline pattern. Should we not be using labels for this Is there a better way to skin this cat
Gewitty
sandeep srivastava
- changesets that only include files added after the label won't be included
- it's a closed range, i.e. it starts with the changesets actually in the label, not the subsequent ones
- it prints lots of other info that you'll have to parse out if you just want the filenames
I can think of two main alternatives:creaturita
Workspace versionspecs are overly complex. Changeset #s and Dates (they
resolve to the same thing) are a lot simpler. Unless everyone bookmarks
this thread and thinks through the various scenarios, simple will = more
predictable.
EtienneB
However, it's not a direct solution to the original question -- it only works after you create a branch based on the label. For that, there are a few possibilities:
- change the way history (and diff, maybe others) interpret compound versionspecs like L~T and W~C
- add a separate command or powertoy that essentially does what Carl's code does
- build a GUI treediff so powerful and compelling nobody wants to do this at the cmdline :)
Thanks for the feedback.
David Ing
I have a couple questions about the "easy answer".
This command returns the changesets that have been modified since the label was cut, not the files contained in the changesets, right
The label was cut on 7/26/2006, and yet the when I use the tf history command, I get changesets back until 7/12/2006.
I am also a little confused about the flaws of the first solution. The first bullet states "changesets that only include files added after the label won't be included". I'm not sure what this means. What other types of changesets are there other than the kinds that contain files
RaviKanthReddy
On changesets back to 7/12: yes, that's another aspect of the "closed range" drawback I mentioned. When you cut the label on 7/26, at least 1 file hadn't changed since 7/12. Let's call that file foo, and say that it last changed on 7/12 as part of changeset 100. Although TFS is smart enough to know that commands like tf get foo;C150 mean "fetch the highest changeset <= 150", there is no actual record of foo being part of changeset 150. So when the label is applied on 7/26, it has to record a reference to foo;100. Dumping the contents of the label with tf labels /f:detailed can confirm this.
On the first bullet: let's say you cut the label on 7/26. A few days later, you add some new files. There are now two groups of files: those that exist in the label, and those that don't. Any changeset containing only files from the 2nd group will not be returned by History when specifying L~T.
Frankly, it looks like the problem you're trying to solve is ill-suited to labels. TFS has atomic changesets, so it's perfectly safe to use a changeset or date filespec -- you'll always get a consistent snapshot of the repository. Although TFS labels are more powerful than in previous SCC systems, I find the need for them is a lot rarer.
Dennis Mark Thorsen
Labels are good to use when you want to tag the set of versions of files used to produce a particular build, for example. If you don't know whether you'll need to service the build (i.e., produce updates and bug fixes), then a label provides the ability to branch it later (by specifying the label as the version to branch) if you need to, without losing track of what was in that build.
If you know you are going to be servicing a release, such as a v1.1, supported beta, etc., then you may as well start with a branch.
Which book did you read
Buck
mattman206