I've got a WSDL service definition checked into our repository. I've noticed that it has changed between versions, and I would like to see what exactly has been changed.
Unfortunately, said WSDL file is a singe-line XML file, albeit a pretty long one. TFS compare shows the entire line as changed, which isn't really helpful.
How can I compare changes between versions for a long single-line XML file in TFS?
PS. Obviously I could copy both versions, format them, and use an external comparing tool. What I'd like to know if there's a way to do this comparison using tools provided by VS / TFS.
You don't need an external tool as Visual Studio can compare any file, even local files located on the local file system:
But you still need to do some formatting (a basic search ">" and replace ">\n" would do though) in order to locate the lines which have changed.
TFS will only do line for line comparison, so single string to single string. You are going to have to use an external tool if you want more information about what was changed.
I would suggest prettifying/formatting the XML and then doing the comparison on both versions, it should be fairly simple to spot then.
I will be upfront I represent the company at hand, but I'm fairly certain this can help you.
This use case is exactly what DeltaXML is for so please feel free to take a look at our free evaluation or free online sandbox to provide you with a line by line comparison or your XML.
http://www.deltaxml.com/products/core/
Related
I have a large application to manage consisting of of three or four executables and as many as fifty .dlls. Many of the source code files are shared across many of the projects.
The problem is a familiar one to many of us - if I change some source code I want to be able to identify which of the binaries will change and, therefore, what it is appropriate to retest.
A simple approach would be simply to compare file sizes. That is an 80% acceptable solution, but there is at least a theoretical possibility of missing something. Secondly, it gives me very little indication as to WHAT has changed; It would be ideal to get some form of report on this so I can then filter out irrelevant (e.g. dates/versions copyrights etc..)
On the plus side :
all my .dcus are in a row - I mean they are all built into a single folder
the build is controlled by a script (.bat)(easy, for example, to emit .obj files if that helps)
svn makes it easy to collect together any (two) revisions for comparison
On the minus side
There is no policy to include all used units in all projects; some units get included because they are on a search path.
Just knowing that a changed unit is used/compiled by a project is not sufficient proof that the binary is affected.
Before I begin writing some code to solve the problem I would like to ask the panel what suggestions they might have as to how to approach this.
The rules of StackOverflow forbid me to ask for recommended software, but if anyone has any positive experiences of continuous integration tools that would help - great
I am open to any suggestion or observation that is relevant in this context.
It seems to me that your question boils down to knowing which units are contained in your various executables. Since you are using search paths, it will be hard for you to work this out ahead of time. The most robust way to find out is to consult the .map file that the compiler emits. This contains a list of all units contained in your executable.
Once you know which units are contained in each executable, you need to know whether or not anything has changed in those units. That information is contained in your revision control system. Put this all together and you have the information that you need.
Of course, just because the source code for a unit has changed, you might argue that re-testing is not needed. Perhaps the only change made was the version, or the date in a copyright label or some such. But it is asking too much to be able to ask a computer to make such a judgement. At some point you need a human to step up and take responsibility.
What is odd about this though is that you are asking the question at all. It seems to me to be enormously risky to attempt partial testing. I cannot understand why you don't simply retest the entire product.
After using it for > 10 years for commercial in-house and freelancer work in large projects, I can recommend to try Apache Ant. It is a build tool which supports dependencies, and has many very helpful features.
Apache Ant also integrates nicely with CI tools such as Hudson/Jenkins, Bamboo etc.
Another suggestion - based on experience with Maven - is to design the general software architecture as modular as possible. If modules (single or multiple source or DCU files in one directory) use a version number in the directory name as a version number, it is possible to control exactly how application are composed from these modules.
If you want to program such a tool yourself the approach would be something like this:
First you need to detect wheter there were any changes made to seperate source files. As you already figured out comparing the file size is bad idea as the file size can stay the same despite lots of changes made to it (as long as there is same amount of text in pas file its size won't change). So instead you could check the last modification time for specific file or create some hash value like MD5 hash for comparison (can be quite slow).
Then you need to generate yourself a dependancy tree which will tell you which files are used for which project/subproject.
Finally based on changes detected in seperate files you check the dependancy tree to see which projects needs to be recompiled.
The problem of such approach is that you would probably have to update the dependancy tree manually each time when new unit is added to the project or an existing one is removed from the project.
But the best way would be to go and use some version controll software istead of reinventing the wheel. I myself like the way how GIT works and I belive that with proper implementation of GIT into the project mannager itself could be quite powerfull do to GIT support of branching/subbranching (each project is its own branch, each version of your software can be its own subbranch).
Now latest version of Delphi does have GIT integration done though SVN but this unfortunately limits some of best GIT functionality. So if you maybe decide to go and integrate GIT support directly into Delphi I'm first in line to use it.
I have a .po file where most translated strings are identical to original ones. However, few are different. How do I quickly find the ones that differ from original?
use podiff
I used it, an it workd for me. Its in C, so you have to compile it. make is your friend
I would suggest using one of the many web-based localization management platforms. To name a few:
Amanuens (disclaimer: my company builds this product)
Web Translate It
Transifex
GetLocalization
This kind of platforms allows you to keep your resource files in sync, edit them in a web-based editor (useful for no-technical translators) and most importantly to highlight/see only the changed/untranslated strings.
How do I have in each *.pas file it's version, incrementing on each save in some comment line? I have plenty of files on three PCs and I need to have a possibility to quickly check their versions against each other.
This problem is easily solved by some centralized version control, but some sources I have cannot be trusted to external servers and are kept on TrueCrypt volumes.
May be some addon can do that for me? Something like changing $Version: to $Version: 121212 on each save, incrementing this value?
May be there is another way also of solving this problem?
Read this chapter about keyword substitution in Subversion.
In short: you have to enable keyword substitution for your files via svn propset svn:keywords ... and insert the revision keyword in these files.
You should try a DVCS like Mercurial. It doesn't need a centralized server while still giving you the benefits of a VCS.
It will also make it easy to synchronize the changes made on each PC to the others.
You may also look at Git : http://git-scm.com/
Don't know if one already exists, but you can write a Delphi plug-in (using its OTA interface) to achieve what you need. Although of course it won't work well if more than one developer works on the same file, unless you use an external, shared counter.
Note that locally hosting subversion can mean filesystem access. i.e. you don't even have to set http. Just point place the repository in your (already) encrypted hard disk, and instead of an URL, use a reference like \share\directory\svn\repo\project1 or C:\svn\repo\project1
Is there currently a feature that allows a exclusive checkout in SVN?
Is there a good plugin for Delphi that allows the access via IDE?
SVN has a concept of "locking" which roughly corresponds to the exclusive checkout. For example, in TortoiseSVN this is exposed via Get lock and Release lock menu entries.
JCL contains a SVN version control expert which works quite fine. Besides other things, tt gives you access to the locking functionality from the IDE.
TortoiseSVN can be added into the Delphi tools menu. I've not tried this myself, since I'm happy using it as an Explorer extension.
Regarding the exclusive checkout, I'm guessing you mean so only one person can edit it at a time? That's not really the idea behind Subversion, the idea is you have working copies and then check in your changes. It'll then try to merge your changes in (this usually works most of the time). If there are conflicts you'll need to resolve them manually.
I believe one of the reasons why people sometimes enquire about locking items in a Subversion repository is because they have their Delphi DFMs saved in a binary format, which makes committing/merging problematic.
An alternative to changing DFMs etc to text is use Scooter Software's Beyond Compare.
Beyond Compare is written in Delphi, and natively knows how to read binary DFMs. This means that it then becomes less of an issue (or even no issue) whether your DFMs are stored in Subversion in binary or text. Beyond Compare V3 also does 3-way merging which makes it really easy to merge multiple commits etc. Even ignoring the ability to diff binary DFMs, it's still a much better diff viewer than TortoiseSVN's built-in tools. I can highly recommend it, and it's very inexpensive.
Currently the only things that I lock in our repository are COM type libraries (*.tlb and their associated *_TLB.pas files).
Regarding exclusive checkouts. It can be done, but it's a pain and generally not worth the time. If you do have dfms saved as binary, convert them to text.
Regarding delphi addins, I have a post at Delphi addins for subversion.
I use the jedi jcl, and TortoiseSvn.
There are also Delphi svn and Delphi addin in for Tortoise svn that I know of.
Maybe I'm naive, but why would anyone want to go to the enormous trouble of merging their changes? Merging might be a simple matter if programmers were editing text files whose contents are easily understood, and which therefore could be merged by virtue of the programmers knowing the meanings of the changes. However if you're using SVN with MS Visual Studio, where changes to one file frequently case changes to other files you didn't know about, and where the encoding of information in such files may be completely unknown to the programmers (who would therefore have no concept of how to interpret much less merge such files) and may even be binary, why would you go to the enormous trouble and risk of having multiple people simultaneously editing things?
The locking paradigm is simple. Only one person edits at a time. Merging is never required. Programmers don't need to know the encodings of (possibly binary) files that they don't even realize that they're modifying. Nobody can stomp on anyone else's changes. Locking (i.e. locking by default) sounds much preferable to me.
What do you mean by "exclusive checkout"? Do you mean that after you check out, nobody else can check out?
That's called a lock and subversion can do this (see Locking), though it's not recommended in general as the purpose of version control is to allow multiple people to simultaneously work on the versioned item.
For first part, I was using Visual Source Safe which is support locking (you have to check out before use), SVN has locking command, but it's against it's concept, you need few time to get used with it, and you will never use the locking command again.
For second part of your question, The TortoiseSVN can be used as external tool, or you can get it working with File Browser bundled with Delphi 2007 and above, and you can use IBrowser which work with older versions.
and Subversion add-ins for Delphi summarize the available SVN plug-ins for Delphi IDE, beside SourceConneXion which is commercial product.
Building the same project (without any changes) produces binary different exe-files: some small regions of them are different. Empty project, version information (and auto-increment on every build) is turned off.
Why it happens? And is it possible to make delphi produce binary equal files for the same projects?
The various structures in the PE executable file format used by Windows include timestamps that are set by the compiler and linker.
It is possible to post-process the file to reset these values to a defined constant (I wrote a tool to do exactly this for a secure product that needed exact hash values), but this should only be done on ready-to-ship executables, as some debuggers rely on the timestamps for source lookup, etc.
Try changing the problem into "How do I avoid compiling if there are no changes to the source", might be easier to deal with.
I suspect compiler insert to *.exe encoded time, special ordinal numbers (for versioning) and maybe other things :)
It's impossible to force Delphi to produce equal binary output.
it may be, that some actual time-stamps are compiled into the exe-file.