Re: FileMerge trouble with XCode 3.1.x
Re: FileMerge trouble with XCode 3.1.x
- Subject: Re: FileMerge trouble with XCode 3.1.x
- From: Chris Backas <email@hidden>
- Date: Fri, 23 Apr 2010 12:15:26 -0400
(Sorry for sending this twice Jens, forgot to copy the list the first
time!)
On Apr 23, 2010, at 11:50 AM, Jens Alfke wrote:
>
> On Apr 23, 2010, at 8:35 AM, Chris Backas wrote:
>
>> I'm migrating my company from XCode 2.5 to XCode 3.1.x on Leopard
>> machines. We write software for internal use only, so we take a long
>> while to validate our products on new OS releases (in this case
>> Leopard)
>
> Your company is still running on a five-year-old unsupported OS?! I
> thought only Windows shops did that. ;)
>
> Just curious: If you’re catching up now, why are you moving to 10.5
> and not 10.6? I would really, really recommend going to 10.6 as
> there are many improvements in performance, stability and developer
> tools. Also consider that, if you ever buy any new Macs, they
> probably won’t run any OS earlier than 10.6. And Apple will probably
> at some point stop providing security updates to 10.5 just as they
> did to 10.4.
Leopard's only three years old isn't it? =) Most of our machines are
on Leopard, just we're using Xcode 2.5. We do use 10.6 on our world-
facing servers, but they don't run any of our internal software. We do
know about the 'new Mac' problem, it's usually what causes us to start
validating on a new OS release. But in general we gain nothing by
staying at the forefront of the treadmill, it's just a cost. As it is,
Leopard has a major regression in its PDF generation that greatly
affects our product, and Snow Leopard hasn't corrected this, so we
still do have certain production machines on Tiger. In general OS
upgrades tend to cause us significant engineering time to address new
problems just to get things back to the way they were before, instead
of adding new features customers ask for. And as we have a very small
engineering department it's a major burden.
>> Basically, FileMerge (or XCode itself if the option is set that way)
>> ALWAYS displays ALL changes as going left to right.
>
> I’m not clear what you mean by this. Do you mean that the older
> revision is on the left side, and the newer one on the right? That’s
> determined by the order in which the two files are given to
> FileMerge. FileMerge itself doesn’t have a notion of ‘older’ and
> ‘newer’, just ‘left’ and ‘right’.
>
> If you mean the arrows themselves, they’re a bit misleading: they’re
> only used for merging (when you save a result file), and the arrow
> head points to which version of a change is going to be incorporated
> into the merge result. They don’t indicate a direction.
What I mean is:
Say I have a file which I've locally modified, and which a coworker
has also checked in an update that I don't yet have.
In Xcode 2.5, if I bring up the SCM window and select "Compare",
FileMerge will appear, and the arrows (in their default positions)
will be pointing left or right as appropriate to incorporate BOTH sets
of changes, producing a merge in the bottom pane that looks exactly
like the output I'd get if I just selected "Update".
If I do this in Xcode 3.1, the result depends on the Preference "Show
local files on the Left/Right", but is always wrong. ALL changes are
shown going right (All arrows by default point to the right), and any
updates/changes/deletions/additions in the version that's displayed on
the left are undone in the proposed merge. It doesn't look AT ALL like
the file that will be produced when I select "Update", and makes it
very hard to tell what the heck I'm looking at.
And since this occurs regardless of the application selected in the
"View comparisons using" tool, and to the same version of FileMerge, I
have to think that the newer Xcode is doing something differently
here, I just can't think what it would be.
Chris Backas
Bristol Capital, Inc.
CONFIDENTIALITY NOTICE: This email (and any related attachments) contains information from InfoPlus (a service of Bristol Capital, Inc.). It is intended only for the addressee and may contain information that is confidential and/or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or are acting as agent for the intended recipient, any use or disclosure of this communication is prohibited. If you have received this communication in error, please notify me immediately to arrange for the appropriate method of returning or disposing of the communication. If our respective Companies have confidentiality provisions in effect, this email and the materials contained herein are deemed CONFIDENTIAL and should be treated accordingly unless expressly provided otherwise.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden