Related
I've created a project and built out a several model classes. I've decided that I'd like to recycle them as a separate framework. In doing so, I want to change my class prefix of those files. The issue is, of course, that I now have to batch rename my files and my classes. I could use the refactor tool, but I have tens of classes, so it would be tedious. Is there a good way to automate the process? For reference, I'm using Xcode 5.
For anyone looking for an answer, I think I have a solution, although it's something I'd like to see built in to Xcode. I've filed a radar.(#15261680)
I had three things to worry about here:
The class names themselves. The class prefixes didn't match the framework that I wanted to put them in.
The file names. Even if I did a careful global search and replace and changed the class prefixes, the file names would be wrong.
The Xcode project references. Xcode keeps a list of your files, and I had to be sure that Xcode would know where to find my files, in the event that I renamed them.
What I did:
I did a global search and replace. Instead of clicking "Replace All", I used the "Review" pane, so I was able to exclude about ten or so cases that I wanted to keep with the original prefix.
I found a utility to do a batch rename. Now my files and classes all match nicely.
Uh oh! Xcode doesn't know where my files are, now. To fix this, I opened the .pbxproj file and did another careful search and replace. (I made sure to quit Xcode first, so my changes wouldn't be overwritten automatically.)
This was a bit of an involved process, and I was hoping that there was a tool or Xcode feature to help me do this, but alas, not yet.
I seem to have some files in my Xcode project that I can't erase. I've tried right-clicking->deleting, dragging out, Build->Clean, anything I can possibly think of.
Any ideas how to get rid of these renegade files?
I'm sure in an older version of Xcode you could dig around (AT YOUR OWN GREAT PERIL!) inside the .xcodeproj file (show package contents and look in there) and somewhere was an xml file which held everything like that. However, I have just had a quick look and didn't see anything that looked likely. Try grepping the files in there for your rogue filenames and see if anything shows up.
If you don't get anywhere in that route you might be able to trick it by creating those files (or at least files with those names) again, then re-importing / re-deleting them.
I am relatively new to Xcode and one thing that has bothered me is that when I add a resource it gets added to the top level directory of my project directory. So for example, at the moment, all of my images are at the top level directory and it makes things look messy. I rather would've liked, for example, to have an images/ folder and then sub-folders within that to store images for certain things, like tab-bar/ icons. Is this possible? Or is it convention to just keep everything in the top level directory?
Someone in the #iphonedev channel at freenode told me something about the build process rule or something, it just seemed too complicated I figured I shouldn't bother, and that most people just kept things at their root directory considering the complexity of the solution. Perhaps it isn't all that complicated though, I just felt it should be easier.
For example I would also like to have a sub-folder for my views, like views/ that stores all of my nib files; currently they are all in the top level directory. And the same goes for my property lists.
I would appreciate it if you could tell me what the convention is, I doubt it is to just store everything in the top level directory. And I'm referring to the actual file system, not simply creating 'virtual folders' in Xcode to organize things, because the top level directory of my project will still be a mess. And if it is possible to organize things better, I would appreciate any detailed help on how to accomplish it.
I think I have heard that in the final build, the entire file structure gets squashed to the root directory. I don't mind so much about that, I just want things to be organized while I am working on my project. I think this is where that 'build rule' thing comes in, but I'm not sure how or what to do.
Here's a little more explanation of Graham's suggestion:
Create an images directory
Create an images Group in Xcode
Right-click the group and Get Info
"Choose..." to set the group's directory to be your images directory
Now, anything you put in the images group will automatically go into the images directory. That's true if you drag/drop from within Xcode, from other other projects or from Finder, or if you Add New... by right-clicking on the images directory. (This assumes you leave the default setting of "relative to group" in the info pane.)
This will work for anything you put in that group (NIBs, etc).
For imageNamed:, you just give the base name.
My recommendation is to keep a small number of filesystem directories, and mostly organize with groups in Xcode. But I agree, a small number of filesystem directories are very helpful. I put all my source code in a Classes directory (just because Apple used that name; I would have picked "Sources" or something). I also have a Resources directory at the top level and generally create images and audio directories under that. But I don't generally create a lots of real directories beyond that. This keeps things a bit tidier, but makes it easier to grep and wildcard things with the shell.
Beyond shell tools, the big advantage of organizing by groups rather than directories is the impact on version control systems like subversion. When you suddenly realize that your "Views" group is way too big, you can reorganize it without taking the huge impact of moving files around.
The accepted answer didn't work for me in Xcode 4.3.2. Looks like they removed the "Get info" menu option. Instead I did this:
Created the directory on disk where I wanted it.
Went to the file menu
Right clicked on the group I wanted to add to
Selected "Add Files to PROJECTNAME"
Added the files from the directory I created in (1)
Life is hard for IDEs. They have to mediate between a filesystem world, where the compiler, with its source files live, and the UI world, where programmers work.
In the old times that formed the contemporary coding culture, everybody, compilers and people, used to live all togheter in the filesystem. So today we still have a tendency to think we want to control where sources and resources reside on the disk. That is good, because we may need to know exactly what compilers eat.
Anyway if you think your IDE just as a the frontend of a funny database system of source code and if you really have full confidence about its capabilities and features (which is seldom the case), you may get to the conclusion that if you just don't care about the filesystem you may have a better life, as a programmer (and as a human being).
You're right wondering, because Xcode is not very good nor friendly about filesystem code organization and people that is (correctly) picky on that will learn how to move files on their right folder on disk, and on their right Xcode group. That, if you use the "Create folder references for any added folders", have a 1:1 relation.
But you will see many people, and many project examples from Apple itsef, that use a simple flat filesystem tree with everything in the same folder.
My advice is that you at least group public headers and resources in different folders, something à la Java/Maven, but there is no universal convention.
It's actually really easy to get from where you are to where you want to be. Create the images/ folder and put all the images in it. Now in the project window in Xcode, the image files have gone red because they aren't in place any more. Get Info on them, and "Choose..." the new location.
Note that just because you've moved the file in the source file system (known as $SRCROOT), there's no change to the way the file is used in the product. If it got copied into Contents/Resources/ before you moved the file, that's where it gets copied to afterwards. No subfolder will be added at the destination.
We have a StarTeam view that has two files that are in the "Unknown" state – does anyone understand why they are in this state and/or how we can get them out of the state?
Is deleting them and re-adding them with a different name the only solution?
Note that if you check out these two files (regularly or using “force checkout”), they will always be listed as “Unknown” (annoying).
Thanks.
More info based on Craig's suggestions below:
a) Calculating file status using MD5 checksum: same results ("Unknown" status)
b) These two files in question have only one revision on the server. I'm not sure if this is because our CM group attempted to fix the issue by deleting and recreating the files or if there really was just one revision. The files are text files.
c) I tried deleting the files on my local machine and refreshing the status. When I do this, instead of seeing the two files listed as "Unknown", I see a total of four files listed with a status of "Missing". There are two entries listed for each file - each pair has the same file name, folder path, "modified by", and "file stamp at time of check in". I have no idea why each file is listed twice. If I select each entry in a pair and select "Compare Contents", my diff tool says they are identical.
I have this same weird issue with the four files whether I use the MD5 checksum compare or non MD5.
If I try to checkout all four of the Missing files, I get two alerts prompting me to merge the files. I say no, the files are now on my local file system and the status is back to where I started - two files listed as "Unknown".
Craig's update:
You're definitely on to something. I moved each of the duplicate items to another directory. That immediately solved the issue in that I now could checkout the four items (two in same dir and two in new dir) without any "Unknown" items. I then deleted the two items that I moved to the new directory.
In doing this, I saw some more info. We somehow have a directory structure like this:
Parent_Dir
--SubDir1
--SubDir1
--SubDir1
--SubDir1 <- Two items were here
--SubDir1 <- Two items were here
--SubDir2
--SubDir3
--SubDir4
--SubDir5
Somehow we have five sub directories with the same name and these two files in question existed in two of the sub dirs with the same name.
The issue appears to be resolved. Do you think I should manually delete the extra sub directories?
Thanks to Craig this issue appears resolved. I have no idea how this situation was created (anyone?) but.. we're good now. Thanks Craig!
It would be a huge mistake to delete the files before you determine where the problem lies. Deleting and re-adding the file would kill the history and any links to the file. It also might not fix the problem, due to the way that StarTeam works internally (with a Native-II repository, anyway). Deleting the file and re-adding the identical file will not actually update anything in the repository, except the pointers to that revision. The revision itself would have stayed there when you deleted the file, and re-adding it would just create a new pointer to that revision.
If you haven't done so already, I strongly recommend telling StarTeam to calculate the file status using an MD5 checksum. Do this in the client via Tools->Personal Options->File->Use file checksums to calculate status. Then try update status again. This is not the default setting (in at least some versions of StarTeam), so it's worth checking. If you have not already done this, it may, by itself, fix the problem.
The first thing to do is to determine if the revision is valid on the server. If the files are text, the easiest way to do that is to compare contents between that revision and the previous revision. If it does turn out that the revision is corrupt, then the best solution would be to check out an earlier revision, and then force check in. This way you preserve the history of the file.
If the file appears to be OK on the server, then test it locally, by comparing contents. If the file is corrupt locally, do feel free to delete the file locally and then check it out again. Unlike deleting the file on the server, you don't lose anything by doing this, except local revisions.
If these suggestions do not fix the problem, I still would not recommend deleting the files on the server. Tell me the results of your investigations back here, and we'll see where we can go from there. It is, in my opinion, nearly always mistake to kill history.
Update
Based on the updated information in the post, I'm getting a better sense of what is going on here. It is likely that there are two items which point to the same file, and have the same name. "Item" is a concept in StarTeam related to the fact that a single file, change request, requirement, etc. can live in multiple places at once. For example, you can have a single file in two different views or projects.
Generally, you do not have the items with the same name in the same folder. But it can happen. And that probably explains the "Unknown" status. When you tell StarTeam to compare the file on disk with the item of the same name on the server, perhaps it can't figure out which item it should look at.
The first thing I would try is to try and drag one of the two items somewhere else. If that fixes the problem in the folder in question, you can delete the item elsewhere, without affecting the item in the folder. If, on the other hand, dragging one of the items elsewhere causes them both to move, it's easy to drag the item(s) back to where they came from.
Update 2
Do you think I should manually delete the extra sub directories?
Yes, but just as with the files, move them first, and make sure the subdirectories you'd like to keep are unaffected before deleting them.
A good way to identify this issue if it comes up again is to click on the root folder, add folder path to the shown columns, then click the all descendants button. Sort the files by name, and look for the unknown files and see if multiple files of the same name are checking out to the same path. Usually this is the result of a mistaken share, addition, or a change in folder check-out path.
As it is undetermined what order StarTeam will check files out, having two different files with the same name pointing to the same local location is a mistake. The 2005R2 native Windows client and Cross Platform client would pull files in a slightly different order, causing views with this issue to produce checkouts with different files.
There are a few ways to legitimately end up with this situation - keeping multiple branches of a single file on the tip and designating which to use by view label is a common one. StarTeam is one of the few VCs that can handle multiple references like this.
Separately, if you can help it, never delete and re-add a file. 99% of the time, it isn't what you want to do. Re-adding a file to the server gives it a whole new archive in the database and it will not be tied in any way to existing shares of that file. You will also lose all of your revision history. Instead, look for ways to move files. And if you have multiple files with the same name and content on your server, it is usually a good idea to make an effort to share the file to the various places it should exist rather than re-add it. This will make sure your changes propagate so you don't need to check-in fixes multiple times.
Were those files added twice? You can add the same file multiple times which could result in this error. Also, check the Reference tab - are these linked files to elsewhere in the repository?
Could that be the files or their status got corrupted on the server? In that case, delete and re-add is the only way.
In VS2008, I have a web-site project. When I use find in files and search for a string, the find results window will list every occurence twice.
What could be causing this?
[EDIT]
Below is the screen capture from VS. I was searching for the work CommissionBucketProductID within my website project. Notice that each line is returned twice.
[EDIT2]
In response to your questions. I am only searching within the project, not the whole solution. I currently don't have these files under VSS, although they were in the past.
I had the same issue which was annoying. I just fixed it. What I've done is to change "Entire solution" to "current project" in "Look in" field when doing search. Then I noticed the result would not be doubled. After I switched back to "entire solution" the problem was gone.
If you do find in "Entire Solution", it also searches in any loaded files, even if they're already in the solution. This means that they'll be listed twice.
Perhaps this is your problem?
I use VS2003, but I get this exact result when I have the same source file in multiple projects. Are you sure you aren't searching more than one project?
Here's your answer:
Find in Files searches same files twice
This seems to happen for files that are shared between multiple projects in the same solution, causing them to get searched twice. Since the problem exists in VS2010, it must have been inherited from VS2008, which probably means you're pretty much out of luck (unless you work around it, such as by separating the projects into multiple solutions).
But in the meantime, it sounds like it's not high enough on Microsoft's priority list to get this fixed.
Do you have any symbolic links to a directory/file within the same search scope? This could cause the file to be listed twice: once for the primary file, and once for the link to the file. Although from memory it should show the directory of the link for the 2nd occurrence, not the file pointed at by the link (and this is inconsistent with what is in your screenshot).
Try closing VS2008, renaming the file (USPostalApplciation.aspx and the code behind file too), then re-opening VS2008, refresh everything you can think of (project, solution, etc...) then try doing the search again.
I had a similar problem. VS would turn up find solution results from files I had loaded in the IDE just to view them and then closed again. So it would search through files that weren't even in the solution.
I scanned all files in the solution, but there was no reference to these phantom files stored anywhere. Finally I decided to scan the registry and found that they were stored in the MRU list. After deleting the MRU list entries, the expected behavior was restored.
Make sure your web project does NOT have any virtual directories that point back to other areas of the site.
Verify that VS2008 shows the same virtual directories (if any) that IIS has.
If you have mis-pointed or mis-configured Virtual directories, it will cause a HUGE performance hit, search result replication, etc.
This is an old thread, but this still happens.
As new info, I just found that the solution contains a Setup project, which naturally references some of the projects, besides the solution itself.
In that case, when searching the Entire Solution there are two routes to some files.