Cocoa mail archive
Re: Why initialize the menubar without Interface Builder
FROM : Uli Kusterer
DATE : Sun Nov 04 00:15:50 2007
Am 03.11.2007 um 22:44 schrieb Fritz Anderson:
> I'm sure you mean more than I intend to address, but isn't this
> analogous to giving more than three developers simultaneous rights
> to edit a JPEG? As in, isn't that a _very_ bad idea, and one of the
> reasons SCM systems offer locks?
I was being a bit flippant here. :-p When someone says something
outrageous that starts with "It seems perverse ...", I sometimes just
can't help myself :-)
Anyway, the main difference is that a JPEG is a single image, while
a NIB may contain several windows and other objects. They don't really
compare too well. JPEGs are, well, "atomic", for lack of a better
word. More single-purpose. Few JPEGs are complex enough that you would
have the need to "merge" several changes. A Photoshop file with
various layers and text layers, where different developers change
different parts is almost as un-manageable as a NIB.
And locks don't help when you're working with branches, because then
NIBs and JPEGs and PSDs are impossible to merge back if someone
changed something in the trunk. But NIBs that use bindings and
connections contain complex logic that's harder to merge over, but
will change more often than the typical image file (or a "simple" NIB,
like Carbon still has them), and if an image is wrong for one dot-
release, it's not as fatal than if one outlet didn't get connected,
which can make the whole app go brain-dead.
And while you can occasionally split up a layered image file into
several and composite them at runtime, you can't usually do that to a
NIB, because you have to keep certain objects that interact in the
same file, e.g. because one has an outlet that points at the other.
Hence, even if you don't have a branch at this time, locking NIBs may
mean that you either have to be very short and quick in your commits
when you lock a file, or half the team is waiting to be able to change
a NIB and get on with their work.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
DATE : Sun Nov 04 00:15:50 2007
Am 03.11.2007 um 22:44 schrieb Fritz Anderson:
> I'm sure you mean more than I intend to address, but isn't this
> analogous to giving more than three developers simultaneous rights
> to edit a JPEG? As in, isn't that a _very_ bad idea, and one of the
> reasons SCM systems offer locks?
I was being a bit flippant here. :-p When someone says something
outrageous that starts with "It seems perverse ...", I sometimes just
can't help myself :-)
Anyway, the main difference is that a JPEG is a single image, while
a NIB may contain several windows and other objects. They don't really
compare too well. JPEGs are, well, "atomic", for lack of a better
word. More single-purpose. Few JPEGs are complex enough that you would
have the need to "merge" several changes. A Photoshop file with
various layers and text layers, where different developers change
different parts is almost as un-manageable as a NIB.
And locks don't help when you're working with branches, because then
NIBs and JPEGs and PSDs are impossible to merge back if someone
changed something in the trunk. But NIBs that use bindings and
connections contain complex logic that's harder to merge over, but
will change more often than the typical image file (or a "simple" NIB,
like Carbon still has them), and if an image is wrong for one dot-
release, it's not as fatal than if one outlet didn't get connected,
which can make the whole app go brain-dead.
And while you can occasionally split up a layered image file into
several and composite them at runtime, you can't usually do that to a
NIB, because you have to keep certain objects that interact in the
same file, e.g. because one has an outlet that points at the other.
Hence, even if you don't have a branch at this time, locking NIBs may
mean that you either have to be very short and quick in your commits
when you lock a file, or half the team is waiting to be able to change
a NIB and get on with their work.
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
