🚀 go-pugleaf

In article <1gkruse.1q969jgwj58p8N%egusenet@verizon.net>,
 egusenet@verizon.net (Eric) wrote:

> What is the best way to place a .nib file under version control using
> projector? This .nib file may contain other files (classes.nib,
> info.nib, objects.xib).

The .nib is not a file, it's a folder, and you should check it in (and its 
contents) like you would check in any other folder.

hth

meeroh

-- 
If this message helped you, consider buying an item
from my wish list: <http://web.meeroh.org/wishlist>

Miro Jurisic <macdev@meeroh.org> wrote:

> In article <1gkruse.1q969jgwj58p8N%egusenet@verizon.net>,
>  egusenet@verizon.net (Eric) wrote:
> 
> > What is the best way to place a .nib file under version control using
> > projector? This .nib file may contain other files (classes.nib,
> > info.nib, objects.xib).
> 
> The .nib is not a file, it's a folder

Actually, this isn't wholly true either. 

Some items with the .nib extension can be files as well. If you Show
Package Contents on one of the .nib folders, you will likely see .nib
files as well.

> and you should check it in (and its 
> contents) like you would check in any other folder.

I am curious what _good_ solutions (if any), within the CodeWarrior
environment, people have come up with that allow them to treat the .nib
folders as if they were files. 

If you have any suggestions, please let me know.

In article <1gktii3.1l4hy2y145dccwN%egusenet@verizon.net>,
 egusenet@verizon.net (Eric) wrote:

> I am curious what _good_ solutions (if any), within the CodeWarrior
> environment, people have come up with that allow them to treat the .nib
> folders as if they were files. 
> 
> If you have any suggestions, please let me know.

Initially, I put the .nib folder in the project, so I could double-click 
on it, but not under version control. Then, I manually used the 
Contextual Menu Item in Finder: Create Archive, and put the resulting 
.zip file in the project, under version control. This requires that, as 
I change the .nib in Interface builder, I remember to check out the .zip 
file, delete it, then create a new .zip file.

Naturally, this means editing the File Mappings preference panel to 
allow .zips in a project as do-nothing files.

I now believe that Miro is right: That I should individually check in 
the .xib and .nib contents files into version control (I can hide them 
in a group in the Codewarrior project file most of the time.) I'll just 
give up on the idea of double-clicking on the .nib package in the 
project, and use the project's title bar menu to get to its containing 
folder in the Finder, where I can easily navigate to the .nib package.

Since .nib FILEs and .xib files are text files in Carbon, then I'll get 
the advantage of source code control diffing.

David Phillip Oster <oster@ieee.org> wrote:

> In article <1gktii3.1l4hy2y145dccwN%egusenet@verizon.net>,
>  egusenet@verizon.net (Eric) wrote:
> 
> > I am curious what _good_ solutions (if any), within the CodeWarrior
> > environment, people have come up with that allow them to treat the .nib
> > folders as if they were files. 
> > 
> > If you have any suggestions, please let me know.
> 
> Initially, I put the .nib folder in the project, so I could double-click
> on it, but not under version control. Then, I manually used the 
> Contextual Menu Item in Finder: Create Archive, and put the resulting
> .zip file in the project, under version control. This requires that, as
> I change the .nib in Interface builder, I remember to check out the .zip
> file, delete it, then create a new .zip file.

This is essentially what was doing, except with the extra step of
needing to transfer the ckid from one .sit file to the new .sit file.

> I now believe that Miro is right: That I should individually check in
> the .xib and .nib contents files into version control (I can hide them
> in a group in the Codewarrior project file most of the time.)

This is the solution that I have switched to...transferring the ckids
was just to troublesome.

> Since .nib FILEs and .xib files are text files in Carbon, then I'll get
> the advantage of source code control diffing.

Good point. 

Eric <egusenet@verizon.net> wrote:

> > I now believe that Miro is right: That I should individually check in
> > the .xib and .nib contents files into version control (I can hide them
> > in a group in the Codewarrior project file most of the time.)
> 
> This is the solution that I have switched to...transferring the ckids
> was just to troublesome.

Actually, I have just discovered that this solution is not working
well.. CodeWarrior cannot find the classes.nib, etc. files inside of the
.nib folder. Since it doesn't know where they are, I cannot check them
in or out within the CodeWarrior environment.

When I export the project to XML, I see an entry that looks like:

                <FILE>
                    <PATHTYPE>Name</PATHTYPE>
                    <PATH>classes.nib</PATH>
                    <PATHFORMAT>Unix</PATHFORMAT>
                    <FILEKIND>Resource</FILEKIND>
                    <FILEFLAGS>Debug</FILEFLAGS>
                </FILE>


This seems obviously incorrect as the <PATH> should include the name of
the .nib folder that classes.nib is sitting in.

Is there some trick that I am missing that would allow this technique to
work? 

I am about to try editing the project XML file and then importing it to
see if that might help. Would anyone expect this to work? 

Eric <egusenet@verizon.net> wrote:

> This is the solution that I have switched to...transferring the ckids
> was just to troublesome.

Of course, a more fundamental problem with placing the individual files
in the .nib folder with the Projector version control system is that
Interface Builder does not apparently honor ckid resources. It will
allow you edit regardless and, when saving, will write the files out
without the ckid resource.

Of course, this would seem to lead to the conclusion that one should use
CVS...it would appear Projector has finally reached the end of its life.

In article <1gkvnpz.k476ib10jnf8nN%egusenet@verizon.net>,
 egusenet@verizon.net (Eric) wrote:

> Eric <egusenet@verizon.net> wrote:
> 
> > This is the solution that I have switched to...transferring the ckids
> > was just to troublesome.
> 
> Of course, a more fundamental problem with placing the individual files
> in the .nib folder with the Projector version control system is that
> Interface Builder does not apparently honor ckid resources. It will
> allow you edit regardless and, when saving, will write the files out
> without the ckid resource.
> 
> Of course, this would seem to lead to the conclusion that one should use
> CVS...it would appear Projector has finally reached the end of its life.

I'm using Voodoo, which doesn't need you to copy the ckid resource, and 
does set the Macintosh Lock bit.