If i make a label in TFS, and later make a new label with the same name... then the old label is replaced by the new one.
How do I prevent TFS from overwriting a label?
The following MSDN article covers using the Scope of a label to try and minimize the occurrences of these mishaps:
Using the /Child Option to Avoid Labeling Mishaps
If you issue a label command together with a pre-existing label name and an itemspec that includes files that are already marked by the same label, the value of the /child option determines whether the marked files are updated with new revision information. That is, the files are labeled by the same name, but have different scope.
Thanks, that led me on the right track.
It seems that the label overwrite is a "feature" and not a bug. It's working as designed
sixletter's link above explains it, and below are two more with info about it.
http://msdn.microsoft.com/en-us/library/ms181439(VS.80).aspx
http://msdn.microsoft.com/en-us/library/ms181440(VS.80).aspx
Apparently TFS labels are not a snaphot of a point in time like in other VCS's , though i do not fully understand the explanation.
Related
In the process of cleaning up some Templavoila Plus FCE, I created a new FCE template that will replace several others. To do so, I created some new field names to replace the old ones. (I noticed you can't change the name of a field after creating it).
For example, I had field_title_A for FCE A, field_title_B for FCE B, etc… Now I just have field_title in my new FCE template.
The problem is that if I change the FCE / Template Object for an existing content, the title field is now empty. It doesn't understand that field_title_A is now field_title.
I seriously doubt that there is a solution, but I still hope there is one.
Is there something I can do to tell TV to move the content of field_title_A to field_title or to tell it field_title_A is now field_title? Is there another way to achieve that?
If I'm not using some terms properly, please, feel free to edit.
no, there is no such support present yet. You could open a feature request for that, but I don't think I could work out a sollution in the next 2 years.
I've created a "block" in Berkeley Snap! that implements Heron's Formula (calculating the area of a triangle given the length of the three sides). It works but it reports an error. I've included a screen shot below that sums it all up. (FYI, there are three such blocks in the image below named HF2, HF and Herons Formula. I created all three trying to fix the problem.)
The routine correctly calculates the value (~125.14), but it also reports an "inside error" that the "reporter didn't report." But, as you can see in my block editor window, the block does report.
Am I missing something, or is this a bug? (I don't want to report a bug on their github site, if I am missing something.)
BTW, I tagged this "mit-scratch" because there is no tag available for Berkeley Snap!
A discussion of this issue can be found here. Bottom line: delete the last reporter block and then add a new one. That should fix it.
I really like how Visual Studio html editor updates the matching tag. Example:
<h2>Header</h2>
If we replace <h2> opening tag with <h3>, then the closing tag should change automatically to </h3>. This should happen as we type.
I'm trying to implement this on my own, but no luck so far. I thought that matchtags addon would be a good starting point, but it stops working if tag names do not match.
Also, I noticed that xml mode marks closing tag as error on tag name mismatch, but I'm not sure how to use this to update the closing tags.
I would appreciate any help from more experienced CodeMirror users.
Thanks
So once the edit has been done, you no longer have the information needed to find the matching tag (which is why the matchtag addon can't help anymore). A good solution might be to track the current matching tag when editing starts (when the cursor is in a tag name) by using the CodeMirror.findMatchingTag function exported by the addon/fold/xml-fold.js file. Then, on "change" events that look like local editing inside the tag name (i.e. their start and end are inside the tag name), immediately follow up by modifying the matching tag.
add matchtags.js, xml-fold.js
config : matchTags: {bothTags: true}
I just upgraded to ReSharper 8.1.23.546 and it added a new key to our team settings file:
<s:Boolean x:Key="/Default/Environment/SettingsMigration/IsMigratorApplied/=JetBrains_002EReSharper_002EPsi_002ECSharp_002ECodeStyle_002ESettingsUpgrade_002EMigrateBlankLinesAroundFieldToBlankLinesAroundProperty/#EntryIndexedValue">True</s:Boolean>
What is this, and why did it add it to the team settings file? Will it cause issues with other developers when this is stored in version control and they haven't upgraded to this version yet?
This is an indicator that ReSharper has migrated some settings that have changed from one version to the next, and is used to not run the migration again.
In this case, ReSharper 8.0 introduced some new formatting options - number of blank lines around property/auto-property, and number of blank lines around single-line property/auto-property. I don't know for sure, but looking at things, it's reasonable to assume that ReSharper 7 used the number of lines around a field when formatting properties.
If you've got a fresh install, introducing these new options is no big deal - everything will be default, and nothing will get written to the settings file. But, if you've previously customised the number of blank lines around a field, then introducing these new options will change the existing behaviour, because the formatter would use the new default options, rather than the old, customised value. So, the migrator runs and checks to see if the number of lines around a field is anything other than the default. If it is, it checks to see if you've already edited the number of lines around properties. As long as they're still set to the default, it overwrites the (default) value to be the same as the number of lines around a field - it migrates the previously used field values to overwrite the default values for properties. It then adds the migration indicator to make sure the migrator doesn't run again, else you'd never be able to have default formatting for properties and non-default formatting for fields.
As for why it's in the team settings, I presume that's because the customised field value is also in the team settings file. Since this file is shared, it makes sense to only migrate the values once, so the indicator should also be in the shared file. There will be no danger in sharing this with the team.
I'm probably biting off more than I can chew with this particular problem, but I'll try to be as specific as possible in case it's within my scope. Disclaimer: I'm not terribly experienced with MS Word, beyond simple data entry/some formatting, and I have absolutely zero experience working with macros or VBasic. Unfortunately, I'm afraid the solution to my problem will come in the form of one of those last two.
THE GOAL:
What I want to do is to have placeholder text throughout my template document that will change content but not formatting when the first instance of it is changed. Basically, I'm writing a template for support manuals for a software suite. Each app has certain similar features like the menu bar, data entry screen, diagnostic log screen, transaction history, etc., so I am pre-writing those sections and using placeholders when I need to insert certain app specific properties.
I started off using the Insert->Quick Parts->Document Property->Subject tool which I used as a placeholder for the app name. I set the Property to [Subject] and then used Insert->Quick Parts->Field->Subject throughout the document, wherever I needed to include the app name. This worked fine in this case because the app name will always be capitalized. I simply change the text in the first [Subject] (which is content controlled) and update the fields throughout the document, and they all match nicely, easy-peasy, work done, go home and drink beer, right?
Not quite.
Our software handles part tracking via scanners and SQL Server, so while the interface and menu in the apps remains largely unchanged, the parts they track change from app to app. Because of this, I need to change the part name when I reference it within the text of the manuals; for example, if I'm working in ToiletPap.app and our TP is tracked by the roll, I need every mention of [Component] to be changed to roll. If I'm working in LightBulbs.app, I need [Component] to say bulb.
My first efforts went toward creating a custom doc property called Component using the Advanced tab under the Document Properties dropmenu. I then created a plaintext content control around my first [Component] titled Component and made my next [Component] a field with modified code: {COMPONENT * MERGEFORMAT}. This comes from copying what I can find when [Subject] works. This didn't work at all; updating the text in the first CC doesn't change the Content doc prop, and my fields return "!Undefined Bookmark, COMPONENT".
I got close to what I need by using the [Comments] doc property, set initially to [Component]. I used it just like [Subject], but (this is when I realized that capitalization was going to be an issue) when I mention my [component] in-text, as often as not, I need to to be lowercase instead of upper.
I've looked on MS's forums and a few others as well as here on SO, and I can't find anyone who's trying to do the same thing, much less an answer to how. Please keep in mind when answering, it would be a great help to me if you would include step-by-step instructions on how to enter/implement the code you provide because, as I mentioned, I have no idea how to go about editing macros/VBasic for MS Word.
To restate and summarize my overall question: How can I use a placeholder that displays the text "[Component]" so that, when I change the first instance of [Component] to something else, say "hopper", every subsequent instance of [Component] is updated to hopper but maintains its current capitalization and formatting scheme?
Apologies for the length of the request, but I wanted to make sure I explained the situation as accurately as possible. Thanks in advance for your consideration and responses.
I managed to solve this one after a couple extra hours of tinkering. I didn't need macros or VBasic, either.
On the first instance of [component] I created a plain-text content control to act as a container (not a necessity, but it makes it look nicer. Will likely cause a problem eventually, but for now, it's working as intended) and bookmarked it. Then, for all other instances of [container] I selected each and used Insert->Quick Parts->Field->Ref with the following field code:
REF Text1 \*Lower
Where "Text1" is my bookmark and "*Lower" indicates all lower case. The *Lower can be replaced with *Upper or *FirstCap to indicate all upper case or capitalize the first letter respectively. Now, each field reflects the text of the first with the capitalization appropriate to each field's location within the document. Just like using the doc prop with [Subject], ^a -> f9 is needed to update all fields within the document.