On 02/03/2007, at 4:13 AM, Dennis Birch wrote:
>
> The version control output is more easily readable than the XML
> output, but in a largish project can produce hundreds of separate
> files. Unless you know exactly where to look for changes (and if I
> did, most of the time I wouldn't need to compare project source) it
> seems to me comparing all those files would be incredibly laborious.
Folder comparisons make this no more laborious than comparing a
single file.
Actually, as an experienced hand-merger of files for many years (I
used to insist on manually merging changes so I could see what was
happening), I think you're exactly wrong.
Comparing many files with a reasonable diff viewer means changes
within a file are localised within that file and there's no confusion
by insertion of other files.
It is also obvious when a class has been renamed as the files won't
match - you will see an unmatched file DennisCanvas.rbbas on one side
and DoubleClickCanvas.rbbas on the other, so you can manually compare
those two.
If you have something which has had many classes inserted, maybe some
renamed, within a single file, it is far more difficult to do a
comparison. Trust me - the OOFILE source for reasons of 8.3 filenames
(yes it is that old) has many classes within a few C++ source files.
The topic of "knowing where to look for changes" is like saying you
are performance tuning without profiling. One of the causes of sneaky
bugs is inadvertent code changes in the wrong place, eg: either
because your window focus was in a different place or you did a
search and replace with different scope from your intentions. There
are bugs in RB2007r1 which make it easier than you'd expect to do such.
Doing a diff between versions ensures you have a chance of finding
such changes. If you don't do a diff (when tracking down a bug which
"appeared between versions") then you may take longer than needed to
find the cause.
The most bizarre example of inadvertent code change I can think of
happened with someone working for me. We had an argument about coding
style - I have an uncommon style in C++ of putting braces on the same
line as a condition.
if (something) {
do stuff
more stuff
}
instead of the common
if (something)
{
do stuff
more stuff
}
One of the main reasons for my style is that if you accidentally
delete the line with the condition, you get a compiler error. If the
opening braces are on the next line, you just get an unconditional
block with local scope.
The *very next week* after the argument, this guy found a bug in his
code caused by precisely that - he had deleted the if() statement.
However, it wasn't him that deleted it.
We eventually found we had a dodgy Ethernet card in that Mac and when
he transferred the code, entire lines OCCASIONALLY went missing.
I would struggle to believe that you could have something losing
entire lines of text that only managed to damage a file in such a way
that it still compiled but it is true (and you can imagine how long
it took us to prove!).
I would have had a disagreement with someone about my C++ coding
style maybe a couple of times a year.
This experience widened my appreciation of the laws of probability.
> In the meantime, I would suggest that the original poster open his/her
> projects in RB 5.5.5, export the source, and use the Compare files
> feature in TextWrangler or FileMerge.
I can't remember exactly which but there was something significant
missing from that export - events or menu handlers?
That's why I wrote my BBEdit Text Factory to cleanup the XML so I
could compare XML.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
