There are a couple of bundles that I would like to add some functionality to. If I update the bundles via SVN will my additions/updates be replaced?
Generally, you should check out a bundle's repo in the global /Library/Application Support/TextMate/Bundles directory; then, if you make any changes, the changes will be stored in ~/Library/Application Support/TextMate/Bundles, and you can easily (a) undo changes, or (b) update bundles without conflict.
To be honest, I forget what happens if you check out bundles to ~/Library/Application Support/TextMate/Bundles instead; I think your own changes get mixed in with the bundle itself, which can create conflicts when updating.
Here's the idiot-proof way to to make sure you don't unintentionally overwrite your custom-edited version during a Bundle update:
Instead of editing an existing bundle, create a new one (bottom left-hand corner of the Bundle Editor, click on the "+" dropdown then click 'New Bundle') and give it a unique (but descriptive) name.
Then just copy+paste the snippets, macros, commands, etc. that you want to modify, from the original bundle, to new snippet/macro/command windows in the Bundle Editor and start editing.
You might want to give Bundles you create this way names that begin with your initials followed by the name of the bundle you modified, e.g., 'DY-python'.
But it's not the unique name that you rely on to keep them from being overwritten. Actually, TextMate recognizes these by the fact that the name doesn't match the name of any Bundle in the Repository, and so, behind the scenes, TM stores them in a location different from the other Bundles, e.g., ~/Users/dougmbp/Library/Application\ Support/TextMate/Bundles, for the user-modified ones, while the default location for TM Bundles updated from the repository is /Applications/TextMate/Contents/SharedSupport/Bundles/.
There is absolutely no discernible difference to the user in how these two types of Bundles behave--they are accessed, edited, and called just like the conventional Bundles. This way, your modifications will survive Bundle updates, TM version updates, and well as bad things (just make sure you add the path above to your list of back-up locations).
No but if you additions conflict with changes made in SVN you will need resolve those conflicts by comparing and editing the two versions.
Related
I'm using BartyCrouch to maintain an up-to-date localized project. My project is currently translated in 4 different languages, and I'm going to add some new languages. My issue is that my base Localizable.strings file has about 200-300 resources, even though there are probably less than 100 currently used in the project.
I'm looking for the best way to remove the un-referenced localized strings in the project, all while keeping the currently localized values.
Is there any native solution or do I have to use a third party? And if so, is there anything automatic?
Well, I definitely didn't look hard enough. I think it's worth posting an answer instead of deleting the question because I don't think the answer is on Stackoverflow yet.
https://github.com/ijoshsmith/abandoned-strings
This little gem will do exactly this. Easy to use. Simply download the zip file, use the Terminal to go into the "AbandonedStrings" folder containing a single "main.swift" file.
Then, on the terminal, enter: ./main.swift /the/path/to/your/project
This will display a list of all the unused ressources.
Then, if you also want the script to delete them, simply add "write" at the end of the command.
Watch out though: it will delete all the Storyboard localized ressources, so commit your project before and simply discard the changes.
I want to pull from a git repo in Windows which has two directories, named Foo and foo. Both the folders have different contents.
As Windows is case insensitive and doesn't allow folders with same name but different case, how do I push to the git repo?
Short answer: You can’t do this easily.
By default, this is a restriction of the Windows subsystem. Unless you use lower level system calls, Windows cannot differ between different casing; so even if Git is able to keep track of the differences, it can’t communicate these difference to the file system.
As pointed out in the comments by phuclv, it is possible to reconfigure the Windows kernel to be case sensitive. In Windows 10, this even works for individual folders, so you could use this to add compatibility where you need it. However, the case sensitivity per folder is not inherited, so you will need to manually change this for the folders that Git creates which might be a bit bothersome and makes this mostly a workaround.
Instead, you could make the whole file system case-sensitive but that might have additional implications, so just be careful if you want to do that.
Also note that even if there is support for case-sensitive content on the lower level, most Windows applications, including built-in Windows tools, will probably not be able to work with this. So this will only allow you to work with these files from certain tools. My guess would for example that most GUI based Git tools simply won’t work here.
If you don’t want to make these modifications, then what you maybe also could do is create partial commits where you just add files to the correct folder (you need to rename it in-between to get the different casing). But that will be very impractical.
In my opinion, the best solution is to simply avoid using multiple files on folders with conflicting names. Even on case-sensitive systems, this will only make things more confusing. By avoiding this completely, you also make it easier for all other developers to interact with the project.
As a follow up to poke's answer, you need to split those directories apart into different names, or merge them correctly into one with the same name, depending on your needs of course. They can't have the same name other the case and have it work in Windows (in a clear and obvious manner anyway).
I accidentally ended up in this same boat. I'm not sure how, as I was using Windows the whole time, but at some point I changed the case on a directory in the repo and some files ended up remaining in a directory with the "old" name and some in one with the "new" name. On my Windows machine they were all under the new name, but I found this problem when I pulled the repo into Linux, and confirmed the split when I looked in my remote repo.
To fix this, I first cloned the to a separate location on my Windows machine. Doing so, all the files were there in one directory again, as apparently the two directories just get merged. I then renamed that problem directory to "temp", (using the TortoiseGit "rename" operation). Then, I cloned the repo to yet another location. At that point, the two directories were in fact split apart in Windows. I had a "temp", plus the directory with the "old" name.
As I really did want them in one directory (on all platforms!), I moved the files out of the old named directory into "temp", then deleted the "old" directory. Next, I renamed temp (using the TortoiseGit "rename" operation again) to the name I wanted everything within, committed and pushed again. Finally, I pulled the changes into my original repo (my Linux one) and checked what was on the remote. Everything was finally in agreement, so I deleted those temp clones and called it a day.
I've got a solution in which I'm trying to create a 2nd executable. These two executable share most of the same files, but have a few different ones including resources and application icon, etc.
I created the 2nd project, and added the items as links.:
Right-click "Add existing item",
Browse to it,
Click the "Add" drop-down and select "Add as link".
Adding as links means that it just references the other file in the other folder and does not copy it.
Now, when I tried to commit my project VisualSVN / SVN tried to do an SVN add on those files in the logical path they belong to resulting in lots of errors that the file was not found. It caused the entire commit to fail and was a major pain in the ass.
Is there a good way I can add links to files without side-effects? All the files I'm trying to link to are already in the same repo.
Update
Maybe I should add more information about what I'm trying to accomplish because I'm open to any suggestion which helps me accomplish it.
I have a project structure something like this... Or I want it to be like this...
MyProject
/Common
BusinessDataObjects (svn:external)
ControlsLibrary (svn:external)
OtherCommmonLib1 (svn:external)
OtherCommonLib2 (svn:external)
/Modules
Module1
Module2
Module3
...
Application1
Application2 (shares all App1's files, except different .resx, icon, name, other minor differences)
SetupProject1 (includes app1 and certain module dlls)
SetupProject2 (includes app2 and certain module dlls)
The application is basically an empty shell (using Prism) which loads the modules installed in a /modules folder. I want both applications to be almost identical, but I want them to have different names and a different icon. I thought I could accomplish this by adding the files from the first project to the second as a link, and simply swapping a resource file which included the strings for the application window title, About dialog, etc. But then VisualSVN or whatever tried to SVN Add those items which I wasn't expecting.
I need to be able to develop the modules and the application's shell project. They are not stable in any way yet. I just want them to near copies of each other but with minor naming differences. I figured with two application projects, I could have two setup projects that included the output from each application and whichever modules are supposed to be included in that version of the software program.
I was trying to make this as foolproof as possible, and I'd like to avoid having to update external references to the same project. (I'm a bit confused about that as well, would I svn:external to the same repo?) That doesn't sound good, but this was my main idea on how to create two almost identical apps. I'm not sure how else I'll do it if I can't get my version control software to behave.
I had suggested oringally we only have one version of the software and have certain modules be upgrades, but there are some good reasons they can't really do that.
When you add a file to a Visual Studio project with "Add as link" it's expected that the file is not copied to the project's folder.
VisualSVN considers status of items in your working copy, even files which are not included in the current solution. However a linked file does not exist in a working copy, thus can't be tracked. It's out of version-control.
Since the files you attempt to link are already version-controlled (i.e. they exist in the SVN repository) it makes sense to use Externals Definitions (svn:externals property) to link them.
Also see TortoiseSVN Manual; it's description of svn:externals is really good.
You don't mention your environment. However, you mention you have a Solution. I'm assuming it's VisualStudio you're using.
Have you tried AnkhSVN which is a Source Control Provider for Subversion for VisualStudio? AnknSVN integrates into VisualStudio much like Microsoft's native version control systems of Visual SourceSafe and TeamFoundation. I believe you can use AnknSVN to do the linking you want since these links are really internal VisualStudio structures and not actual symbolic or hard links like you find in a Unix system.
I usually avoid links (I believe they're called Junctions on Windows) because they simply don't work across operating systems. Instead, you can use one of the following methods:
Use your build system to copy the files, or create the required links rather than your version control system.
Use svn:externals to do the linking. Careful with this because svn:externals are pointers to a Subversion URL.
For example, if I setup http://foo.com/svn/trunk/proj1 to have a svn:externals link to the head of http://foo.com/svn/trunk/proj2, and I create a tag for Project 1 by copying http://foo.com/svn/trunk/proj1 to http://foo.com/svn/tags/REL-1.2/proj1, that project is still pointing to the head of the trunk of proj2. Changes in Project 2 will change what I thought was a stable tag. Always point your svn:external to a stable revision.
I have no experience with VisualSVN, we use Ankhsvn which does not have that problem.
http://ankhsvn.open.collab.net/
Duplicating a target in Xcode is a great way to create multiple app or framework/library products that have somewhat different features using the same codebase as a result of conditional code controlled by environmental variables set within the target build settings or related schemes. First duplicate your known-working basic version, then set the environmental variables each target will use, then start splitting up your code behavior with inline preprocessor #ifdef statements.
However, any duplicated target will be named "Original Target Name copy". This can be renamed, but the info.plist will also have this name, it may also appear in a couple of essential build settings, and it can be a tedious and error-introducing process to remove all references to the non-informative "copy" version of the duplicated target name depending on how you do it. When I create iOS frameworks this seems to be especially prone to introducing issues.
My question is whether there is any technique for duplicating a target which allows you to specify the new target name at the time of duplication, so there is never a temporary wrong target name or any files being created which contain that temporary wrong name. Or, alternately, if there is some way to use the "refactor" functionality to fix this is an automated way.
If there is some kind of wrong assumption contained within the question that explains why this feature hasn't been included in Xcode, let me know. I'm using 4.3.
Unfortunately, I'm pretty darn sure there's not any current UI for this, although I strongly agree that it would be a huge improvement; I can't speak for everyone, but I pretty much never want a target named Foo copy. I would suggest filing a Radar.
You could, with some effort, use CMake for that. It's a build system generator.
It may be difficult at first to learn and setup the project, and some things are (currently) not easily possible for Xcode (like resource adding) but it would make creating new targets with a basic configuration very easy.
Basically, you write CMakeLists.txt files in your source tree to define your libraries and targets, then define the source files, etc., then generate the Xcode project each time.
Adding a new target would be very easy:
ADD_EXECUTABLE( Target_Name Source_Files )
SET_TARGET_PROPERTIES( Target_Name PROPERTIES COMPILE_DEFINITIONS Your_Additional_Defines )
Rerun CMake. (Its not even required to close the Xcode project)
Disadvantages:
Takes time to setup.
Sometimes research is necessary to get some things to work
Some things are currently not well supported via CMake
In Xcode 6 (not sure about earlier versions) duplicating a target will still generate the " copy" appendage and rename all localized menus for example. But, it is reversible by updating the Product Name under Packaging in Build Settings / All. Info.plist will still have to be taken care of as well as Scheme naming though.
Doubleclick on the target to at least rename thetarget ... still looking to rename the product, but that's not so important if you can rename everything else (like the displayname etc))
select project in Navigator panel
select Target you want to duplicate
right mouse click and choose "Duplicate"
Rename Target in XCode: click on selected Target and inline edit starts.
Open Terminal and go to your project directory/folder
Run svn status to see the changes XCode just has made.
XCode has created new Infocopy.plist file and has added under version control if you use one. Typically you want to choose different name so follow these steps:
Cancel version control addition: $> svn revert Infocopy.plist
Rename it: $> mv Infocopy.plist YourNameInfo.plist
Add it to version control: $> svn add YourNameInfo.plist
Set the new name in your new Target Build Settings named "Info.plist File"
Rename target file properly: $> mv OrigTargetCopy.xcscheme YourTargetName.xcscheme
Add the new target file under version control: $> svn add YourTargetName.xcscheme
Rename you Product in your new Target Build Settings named "Product Name"
Very likely you will also want to set new "Preprocessor macros" Build Settings for your new Target.
Set proper values your YourNameInfo.plist
Set Target assignment for target specific files. Typically YourNameInfo.plist shall be part only of you new target. There may be plenty of other similar files (icon, splash screen, other graphics, etc).
[UPDATE 03/04/2015]
The question is now 4 years old, and applies to a specific version of XCode which I have now specified in the subject.
I have searched a lot for this argument, but I couldn't find a solution, I even post on stackoverflow, but I soon deleted the question becuase of very little access.
Now I am trying again.
I have a workspace with two distinct projects A and B.
B has two targets, one that build a static library Blib.a, and one that build a bundle B.bundle. All of them get built in the derived directory.
In project A I can easily add the static library from the build phases. However I cannot find a way to include the bundle. B.bundle is not visible from "copy resource" tab in A.
Therefore I need to add manually, with all that implies.
I also thought about using a script, but I would like to use this as a very last option.
Has someone a solution for this ? Did I miss something ?
thanks
After long investigation, it came up there's no easy way of doing this. The B.bundle is never visible to A project, and there's no settings in workspace to change that.
At this point there are three solutions:
Include the bundle manually from "copy resources->other", I started with this, but everytime there's a change you have to drop and include the bundle again
Create a script to be run in build phase, if everything is built into the PRODUCTS dir you can find the bundle easily and having copied automatically into the app.bundle. This is not a bad solution. If you are using svn the script got included in project, and users have it for free without additional work.
As suggested by Apple tech support, use folder references.Build bundle B into a folder and add such folder to project A using the "Create Folder References for any added folders" option. Xcode 4 will update your bundle into that folder every time you built it.
The added folder will appear as blue once included in your project A.
Thats's it, I personally use the script, because this solution is path independent if you use standard xcode reference variable such as BUILT_PRODUCTS_DIR and so on, and the shell script is just a cp -r-f
[UPDATE 03/04/2015]
I would like to point out that the question is now 4 years old. At that time there weren't many "official" options available. I even spoke with Apple Tech Support, which proposed solution 3 as the only available solution. It is of course very likely that things are now changed, and there is a much better solution. Just to speak, I also like to add that the three above are not "hacks" but "solutions", maybe technically outdated, but they can still be used nowadays. I intend a "hack" as a..."hack", which means it probably not going to work in future software release.
Here is how I did it.
Drag and drop B.bundle from Project B → Products → B.bundle into the Copy Bundle Resources build phase of your app in Project A (select the Create groups options when asked). This will add B.bundle at the root of your Project A outline. You can move it into the Frameworks directory near Blib.a if it you prefer.
Select B.bundle and check its Location in the Identity and Type right panel (Utilities area). By default, Xcode chooses Relative to Project. This is wrong, select Relative to Build Products instead.
The path to B.bundle will now look something like ../../../../../../../../Projects/MyApp/B.bundle. This is not what you want, but you can easily fix it. Open ProjectA.xcodeproj/project.pbxproj in a text editor, search for this path and delete everything in it except for B.bundle. Your project.pbxproj should look like this:
explicitFileType = wrapper.cfbundle; name = B.bundle; path = "B.bundle"; sourceTree = BUILT_PRODUCTS_DIR; };
Save your project.pbxproj file. Xcode will automatically reload your project and your app should build just fine.
After searching for a long time and failing many times, I found this resource that has been an absolutely great tutorial to create Static Libraries and include bundles in your main project or even for distribution to 3rd party developers that may consume your library.
Absolutely recommended:
https://github.com/jverkoey/iOS-Framework
In project A, is the product of project B a dependency in your scheme's Build action? I think you might have to set up this dependency (sometimes disabling the automatic dependency discovery option is best) for it to show up and be available for copying into another target. I believe this is because it doesn't really exist (like an image resource file) until it's built and Xcode needs to ensure it's built before working with it from another target.
As of Xcode 5.1.1 I was able to drag and drop B.bundle from the Project Navigator to the Copy Bundle Resources list of project A Build Phases. I assume creating B.bundle target is not an issue.
Switch build to Generic iOS Device. This step is needed to create a non-simulator reference.
Drag the .bundle to the other project's Copy Bundle Resources.
Select the .bundle in the Project navigator of the other project, and change its Location to Relative to Build Products
Make sure your .bundle in added to Target Dependencies of your static library