Don't ask why, but I'm using VS2003 and need to see what changes have taken place in all the files in my project between a certain date and now. I see how I can do that, namely by right-clicking on each file and selecting "Compare Versions" then selecting By Date and the date for the version to compare with the latest. This is good; what would be (much) better is if I could generate a report whereby it would show me something like:
The line "*Sit on a potato pan Otis*" was removed from BachBestsMozart.cs.
The line "*Any enterprise requiring new duds is likely a dud itself*" was added to CheapSunglasses.cs
(etc.)
...but hopefully ignore unimportant differences, such as formatting, comments, etc.
Does such a possibility exist, or am I doomed to open each file, one by one?
UPDATE
I ended up having to compare them all, one by one, eyeballing them. At least it's better than VS2010 is acting for me right now:
Awedly (I am awed, but not in a good way), the "Compare" functionality in VS2010 doesn't hold a candle to that in VS2003!
In VS2003, I can select a Target Version based on a date to compare with the current version - so, if I pick 2/13/2013, I may end up comparing files dated recently (today or whenever the file was last modified) and one modified on 2/13/2013, or 2/1/2013, or whenever the last modification prior to the date I selected took place.
In VS2010, it looks like I should be able to do that, but the combo box for the comparison file is grayed out/inacessible! Heavens to Murgatroid!!!
Or maybe this is just related to the problem I'm having where I can't update anything in the Package Manager - even trying to update Nuget gives me a can't load library err msg; and the package console is "read only" for me, too... I wish there were a "repair" functionality built into VS that would check up on missing or corrupt DLLs and replace them...
Related
I'm running a model that has a bunch of DLLs which read some .mat files.
When I use an old version of MATLAB (I think 2011a) to generate the files I get files that work okay, but when I create them with 2017a the files seem not to work with the same script.
I've used 2017 to read in the working 2011 file and then saved it, and these files also don't work.
I've also tried the above with the '-vXX' settings at all available values according to the help, with no success.
Example:
clear; load('v2011file.mat'); save('v2017copy.mat', '-v6', 'var1', 'var2', 'var3');
One thing that I have noticed between the two is that when they're selected in the "Current folder" browser, the preview always shows the 2017 files with the variable names in alphabetical order, regardless of the order that I saved them in, while the older 2011 file seems to maintain the order that they were saved. I can only assume that this is something related to a change in the way that files are saved - it might not be the problem but it does hint toward a change (it does this whether or not I include '-vXX' to use older formats).
It's probably worth noting that the 2011 files are created on XP, while the 2017 files are made on Windows 7.
Essentially I'm looking for anyone who might know whether it's possible for me to change the way the file is put together by MATLAB, rather than having to change the DLLs to accept a newer file.
It looks like I can work around the save order issue and have something that works by doing:
save('new2017file.mat', 'var1');
save('new2017file.mat', 'var3'. '-append');
save('new2017file.mat', 'var2', '-append');
Meaning I can put them in a specific order - I have to have the default save set to -v7 in preferences>general>.mat files too.
I wouldn't say no to a more elegant answer if there's one available though!
I am working with .docx files containing several drawing canvases with images inserted and some lines and arrows drawn in Word 2010. I am using 2010 format with no compatibility mode.
Word inserts an o:gfxdata attribute into each v:shape and v:group element and fills it with ascii encoded something. From what I have read it may be a copy of the VML describing the v:shape or v:group. I don't know if I just don't know what to look for, but I cannot determine what this data is for as its removal has no apparent effect on my ability to read or edit the document in Word 2003, 2007, or 2010.
It does swell the document.xml to almost twice the (apparent) necessary size. This considerably slows OpenTBS' processing so I would like to remove it, if possible. Does anyone know of a way to tell Word 2010 to quit saving this extra data? Or what it is for? I have really struggled to find any documentation on it beyond this post.
Edit:
Here is a sample .docx. The document.xml is ~141KB and OpenTBS takes an average of 10.35 seconds to create a file that includes this as a subtemplate 21 times. If I remove all of the o:ogfxdata attributes, the file size is reduced to ~37KB and OpenTBS takes only 2.99 seconds to produce the same file.
Edit 2:
After further investigation, it appears the removal of the o:gfxdata may cause Word 2003 with an older Compatibilty Pack installed, to object to the file with the following error:
"This is a pre-release version of the Compatibility Pack and can open
pre-release Office 2007 files only. Do you want to check for a newer
version of the Compatibility Pack?"
I have been able to open the file by installing a newer compatibility pack - though it prompts the user about the incompatibility and converts the file in order to open it. This does not damage my file, but it is something to look out for.
Attribute o:ogfxdata is poorly documented in the web.
According to your investigations, it's some kind of compatibility extra information.
You can delete those attributes in your template using OpenTBS.
The cleaning can be done once on your template without any merging, and then save the cleaned template as a new template. Or you can perform the cleaning each time you open the template.
Cleaning the DOCX file:
while ($x = clsTbsXmlLoc::FindStartTagHavingAtt($TBS->Source, 'o:gfxdata', 0) ) {
$x->ReplaceAtt('o:gfxdata', '');
$TBS->Source = str_replace(' o:gfxdata=""', '', $TBS->Source);
}
Note that the class clsTbsXmlLoc is provided with OpenTBS and is undocumented.
The code should work since OpenTBS 1.8.0. (which is currently in stable beta version).
I've noticed that since attributes o:gfxdata are deleted, they do not come back immediately when you edit the docx.
I am doing a refactoring of my C++ project containing many source files.
The current refactoring step includes joining two files (say, x.cpp and y.cpp) into a bigger one (say, xy.cpp) with some code being thrown out, and some more code added to it.
I would like to tell my version control system (Perforce, in my case) that the resulting file is based on two previous files, so in future, when i look at the revision history of xy.cpp, i also see all the changes ever done to x.cpp and y.cpp.
Perforce supports renaming files, so if y.cpp didn't exist i would know exactly what to do. Perforce also supports merging, so if i had 2 different versions of xy.cpp it could create one version from it. From this, i figure out that joining two different files is possible (not sure about it); however, i searched through some documentation on Perforce and other source control systems and didn't find anything useful.
Is what i am trying to do possible at all?
Does it have a conventional name (searching the documentation on "merging" or "joining" was unsuccessful)?
You could try integrating with baseless merges (-i on the command line). If I understand the documentation correctly (and I've never used it myself), this will force the integration of two files. You would then need to resolve the integration however you choose, resulting in something close to the file you are envisioning.
After doing this, I assume the Perforce history would show the integration from the unrelated file in it's integration history, allowing you to track back to that file when desired.
I don't think it can be done in a classic VCS.
Those versioning systems come in two flavors (slide 50+ of Getting git by Scott Chacon):
delta-based history: you take one file, and record its delta. In this case, the unit being the file, you cannot associate its history with another file.
DAG-based history: you take one content and record its patches. In this case, the file itself can vary (it can be renamed/moved at will), and it can be the result of two other contents (so it is close of what you want)... but still within the history of one file (the contents coming from different branches of its DAG).
The easy part would be this:
p4 edit x.cpp y.cpp
p4 move x.cpp xy.cpp
p4 move y.cpp xy.cpp
Then the tricky part becomes resolving the move of y.cpp and doing your refactoring. But this will tell Perforce that the files are combined.
Does RCS have something like svn/p4 delete where it keeps the file history but marks it as deleted? Or do I just remove the file and the matching v file in the RCS directory? What's the recommended way of removing and/or moving files with RCS?
RCS has nothing like 'svn delete'; it does not manage directories.
You do not want to remove the RCS file (RCS/filename,v); you need it for access to past work and historical versions. You simply no longer get (co) it from RCS.
You asked about moving files. There are (at least) two options.
One is to move the underlying filename,v file from one name to the other - possibly in a different directory. That loses the previous information - you would not be able to regenerate a previous release because of the renaming.
The other is to copy the underlying filename,v to newname,v; this preserves the history by leaving the original file in place, and gives the new name of the file a history too.
I generally use option 2, but I'm anal retentive about regenerating old versions of the software.
This technique becomes more difficult if you want to create a new file with the name of the old one. I'd then use the old file and start a new main version (e.g. jump from version 3.15 to 4.1) with the new material. If you decide your new material must have version 1.x numbers, you've hosed yourself - you have to choose between backwards compatibility and forward motion. I'm not so attached to specific version numbers as all that (but would recommend against using 'the year' as a part of the version number; I have a number of files with version 2003.2, etc, and when I edit those, I have to remember to change the version to 2009.1, etc.).
I'm using Eclipse 3.4 (on Mac) and I've got an annoyance with the text comparison having the files I'm comparing in a specific order which is not what I want.
When I compare two files it always seems to put the first file (alphabetically) on the left, and the latter one on the right, but I want to be able to change this on a comparison by comparison basis.
IE comparing 'file-a' and 'file-b' will always have 'file-a' on the left, but that isn't always what I want. I seem to recall in earlier versions of Eclipse that changing the file that was right-clicked when choosing Compare With -> Each Other changed the order, but that isn't working for me in 3.4.
An example of why I care:
I've just performed a subversion merge and had a conflict, so I now have the following files:
file
file.merge-left
file.merge-right
file.working
I've made changes to file and now want to compare file to file.merge-right and file.working to file.merge-left and split the editors so I can have the working/left changes sitting above the file/right changes, and then just page through the compare editors and make sure the differences between this file and the file that the merge comes from have been preserved, but file is on the left while file.working is on the right, and hence the differences need to be compared diagonally rather than just comparing top and bottom.
Yes, that's actually very annoying. We use an external tool called Beyond Compare (we have a corporate licence) which can swap the two sides easily.
What you should probably do is raise an enhancement request on the relevant Eclipse team with Bugzilla. If there's enough demand, it'll either make it into the next release or someone will write a new (or modify the existing) plug-in to allow swaps.
There's a "Swap From and To" button when the Compare screen comes up. Using Eclipse 3.6. I'm actually looking for a way to change default behavior. For example, when I compare revisions, it always have the latest revision on the left side instead of right unless I click the swap button before comparing.
As I mentioned here, Eclipse Neon.2 (4.6.2) has a button to swap the views: