I started a code review from the command line using
ccollab adddiffs new D:\Development\review\before D:\Development\review\after
I made changes to the code and then went to upload those changes to the review using:
ccollab adddiffs ask D:\Development\WRONGpath\before D:\Development\WRONGpath\after
code collab errored out saying there were no files to upload. Okay, fine. I fixed the path and redid the command with the correct path
ccollab adddiffs ask D:\Development\review\before D:\Development\review\after
I properly edited the list of files in the text file leaving all the original file names in there except files I did not want added to the review, but Code collab proceeded to add the files as new rather than as diffs to the original files. I'm wondering how I can undo the last upload to the review?
It's only possible to delete files if there aren't any comments or defects on them. If the files you want to remove is part of a changelist (which it probably is in this case) then your only option is to remove the whole changelist.
In the Review Materials section you'll see a Delete button next to each changelist. You may need to change the View As option to Separate in order to delete the changelist.
Related
I followed the instructions in this Microsoft article, but they don't work.
I created .tfignore file, put it in the root, here its content (I want to exclude these folders).
When I open Team Explorer - Pending Changes, I see these folders are included in Pending Changes
A way to solve the issue is updating your VS to VS2015Update 3. The .tfignore should be indeed working correctly.
If those files already in the pending changes before you add your .tfigonre file in source control. You can try below solution:
If the changes are "still" in pending changes, first create a backup
copy, then make an Undo on them. Close VS, restore the backup copies
and then it should work.
Or you can try to use a temporary quick fix for the problem:
Add an $ char into the bower_components folder name in the .bowerrc. TFS does not allow the $ character in the file name, so it can't be added to source control.
More detail ways you can refer this blog from GitHub: Things in ".tfignore" still are shown in pending changes
I'm a rails developer seeking a fix to an annoying problem.
Recently, I've been noticing some random textedit file being generated in wherever directory I was working.
The file looks like this.
Click this Image
After spending some time, I was able to find out that the file was generated every time I opened up Terminal. Even after I delete that random file, it gets regenerated if I open the Terminal app.
It says that the file is a TextEdit document, with 0 bytes of size.
When I open the file, there's no text.
It is so annoying because it gets tracked by git, and I have to delete it every time I am committing/pushing my work.
Disregarding the causes why you have this bug, you can simply use a gitignore file to stop the file from being staged. You define a pattern and all files fitting will be excluded. It's generally recommended to have a gitignore to make sure no wrong files are staged.
https://git-scm.com/docs/gitignore
Ok so some how 2 of my classes had ended up in a weird directory
projectname>projectname.xcodeproj>
In my infinite wisdom I tried to transfer these to the proper directory were the rest of my classes are (projectname directory)
However now I cant compile due to it not being able to find certain files
what file can I edit to check to see where it's looking for these files?
UPDATE 1
in response to the first answer I have tried readding the files. which has netted me some different errors. Specifically that Cameleon-Prefix.pch, no matter how many times I re add it always shows red.
A quick fix for this is to delete the files from Xcode, but in the confirmation dialog, choose to just release the references. Then add the files again (from the File menu Add Files… item).
If you want to see where Xcode expects to find the files, choose the file in the navigator pane on the left, and set up the right hand pane with this configuration.
And from there you can click on the detail disclosure buttons to see even more.
Edited to add
Make sure this is the same file pointed to in your build settings:
Do a similar search for pch to make sure the same thing goes with the pch file
I've run into a problem with VS2010 (it also exists in the latest version, SP1 (10.0.40219.1)):
Add an existing Word file to the "Solution Items" and check this new file in.
Check the file out for editing
Double click on the file and edit it in Word (just make some minor changes)
Save the file (CTRL-S)
Now the file is removed from the "Solution Items" in Visual Studio (you may have to repeat the editing and saving a couple of times)
Update: I'm using Visual SourceSafe 2005.
Despite my research efforts I haven't really found anything on this issue apart from this Microsoft page, and I'd like to know whether there is a way to prevent this problem from happening.
Any ideas are more than welcome, thanks in advance.
G.
After further investigation I think I found the reason behind this behaviour and a workaround.
Please also note that the behaviour described in the original question only occurs for files that are added directly underneath a solution or to a folder that is directly underneath a solution.
The reason
I'm not sure whether the following is 100% correct, but the main point is how Word (and probably other MS Office apps as well) saves an existing file:
Save the current version of the file to a temporary file
Rename the original file so it can be used later in case something goes wrong
Copy the temporary file to the location of the original file, using the original file's name
Delete the original file (that was renamed in step 2)
Visual Studio picks up that the file doesn't exist (for a very short time though) and removes it from its tree and the .sln file. This can also be reproduced by manually adding any kind of file, checking it out (if not checked out), renaming it to a different name and then back to its original name => file is no longer shown in Visual Studio.
The workaround
I've created an empty project template following the steps on Microsoft's site. I also set the output to "Class Library" so that the project would compile even if no static main method exists. This template can be used to add a "Documentation" project to an existing solution. Underneath this project you can add files and edit them as you wish, as Visual Studio behaves differently and does not remove the file when it is saved in this constellation.
Obviously this approach is still not very satisfying or elegant, but I hope that it may be helpful for others who might run into the same problem.
G.
I've run into the same issue. I simply undo changes for the solution after I've closed the document file and the solution files will be as they originally were before your document changes.
Borland Starteam: How to re -check-in a file from a frozen labeled configuration to current configuration with history?
You should be able to go to that frozen labeled configuration (View->Select Configuration->Labeled Configuration) and pick that label. Then what you are seeing should be files as of that label. You could then checkout the file you wanted from that label.
Then go back to the current configuration (View->Select Configuration->Current Configuration) and check-in your file (you will have to do a Forced Check-In since it will show as Out of Date status). In the check-in comments you may want to mention that you pulled that file forwards from that label.
You will not lose any of the history between the label and your check-in.
If the file does not exist in the current configuration, you can share the file from the labeled config to current - just have the view open in two separate windows. This will retain all of the version history.
There is a hiccup in that it will not allow you to share the file into the same folder as it originally existed (as of 2008R2). Just share the file into a different folder then move it.
All history is retained. Note that the new instance is a share, so you may want to check the reference tab before branching to make sure it will do what you expect.
Based on GanYo's comment to the question -
The problem is not the fact that the file is sitting in a frozen label -
the real problem is that the file was deleted.
You cannot "bring back to life" a file that was deleted,
but you can "go back in time" to see it's history (as mentioned by Dougman).
The only solution supported by Borland is this:
Set-Configuration to a time (or label) just before the file was deleted
(this should allow you access to the latest version of the file with all its history).
Check-out all the different revisions of the file, one-by-one, keeping them in unique names
until you have the complete list of revisions.
(best is to append the revision-number to the name of each revision to the file being saved locally)
Set-Configuration back to 'Current'.
Check-in the complete history of the file, starting with the oldest version of the file,
and going forward, until you have imported all the file-revisions in the correct sequence.
(you have to rename each revision of the file to its original name before you check it in, of course)
Having said that, you really need to think if this is worth it, because:
This "restore" process does not bring back:
the comments of each revision
the CR-links that were attached to each revision
the Lables that were attached to each revision
The file's history was there all along, and is available via 'Set Configuration' - why duplicate it?
Bottom line:
It is probably best just to restore the latest version of the file,
mentioning in the comment that it was deleted accidentally and that its history can be reviewed
by doing 'Set Configuration' to ...