I am trying to release a custom view that utilizes WEPopoverController as well as UIButton+Glossy but I don't know how I should add their code to my git repository. Should I submodule it?
Here is the UIView if anyone is interested:
Of course you could add them as submodules so it boils down to more of a personal opinion.
In my opinion submodules are overused. I would use it only to in a case where I want to break a specific project into smaller projects. So let's say I have a large project but a specific part of it can be usefull by itself. In that case I could create a submodule so people that is only intersted in that part can fork/clone it.
In your case where you are only using it in your app the best way is probably to copy the files into your repo, not using submodules. In that case It may be a good idea to add them to a vendor folder just to make it clear that it's part of a separate project you are using here.
Let's say that in the future the project gets updated and breaks the API or cause other problems. You better have a static version of the file you have tested with your application than leaving it open for anyone to update the submodule to a version of those libraries that might be not supported by your application.
Related
I want to create a Swift Package Manager entry (manifest and modulemap files) for existing C lib repository on github.
However I don't want to fork it, add it there and maintain the fork to be up to date with original repo.
Is this a way to create a separate repository which will work as a proxy for Swift PM?
No, not yet. I have considered this idea, and think it would be useful, but right now in practice making an existing C lib work with the package manager usually requires moving the code around. Once we support custom code layout conventions, then I think it will become more interesting.
As a hack, you might be able to make this work by using a git submodule to reference the foreign package, and using symbolic links to make the sources appear where they need to in your "adaptor" package.
As far as I know, the generally accepted practice of adding third party code like d3 is to add it as a git submodule. This reduces the size of the main repo, but I would imagine having d3 (for example) code in the main repo would help debug the cases when d3 changes breaking some code that uses it.
Are there any reasons why I should not just check out the latest version, develop my code using it, and push it to my own repository?
I really like using git subtree for this purpose. It allows you to keep copies of the remote repository, but still maintains that repository's history, and push/pull back and forth at will.
the only reason is: you don't need it. just use some build tool that automatically manages your dependencies (like grunt). but if for any reason it's not an option for you than use the way that fits your needs. you can make a separate dir for 3rd party libraries and it will work. just make a way so any developer can easily find out which version is currently used (for example use version in file name)
I have a library containing a few classes. Now I want to split up this library into two separate libraries. What is the correct/best way to handle this in combination with source control?
My initial thought is to create a new repository for each new project and in the initial commit mention that it was split of from a now unmaintained project.
While I only have a few commits so far, an issue with this method is that the history of the project is lost.
It depends on which version control you are using. For instance, in git you can use filter-branch to do the trick.
You can make a copy of the original repository, then use git filter-branch to keep the history of the part you are interested in and dropping everything else.
$ git filter-branch --subdirectory-filter mydir1
$ git gc --aggressive
$ git prune
Beware this is destructive. You will see a considerable reduction of the repository size, only having the history of mydir1 and removing all those unreachable objects.
Then, repeat the same for other libraries/subdirectories. In that way, you will keep only the history that belongs to each part/library/directory.
If you are using a different version control system, then you have to figure out the equivalent way to do it.
The rule of thumb I follow depends on whether you will be developing and/or deploying the libraries independently. If you are separating the libraries simply for code organization and the code is deployed as a single solution, then there is no need or benefit to creating separate repositories.
On the other hand, if you will be versioning and releasing the libraries independently, then having the code in separate repositories helps this. So, for instance, if you are separating the code because some of it belongs in a share framework, then put the framework code in its own repository. This will allow you to maintain, build and release the framework separate from any applications that are built using the framework.
HTH
you can create a new repository but also you can create new projects under the same repository and delete the old one in time. actually, that's up to you. if you see the previous project as test level or pre-alpha stage, you may want to create a new repository. but other than that, using the same repository is very likely for this situation.
I've found a really good tutorial on "Easy, Modular Code Sharing Across iPhone Apps: Static Libraries and Cross-Project References"
Now I need to understand if my approach can work.
Suppose I have my "main" project with all the assets I need (View Controllers, Delegates, etc.).
Now I create a new project and simply add a reference to every file I need from the first project; of course I DON'T select the "copy if needed" option.
In this way do I build a new project with all the assets from my main project?
If I change the code in the main project, this change will be reflected to all the referencig projects?
Is this an easier way to share code between projects?
Thanks.
Since I keep all my code under version control, the way I do it is to have modular code as Git repositories. That way, to add common code, or chunks of functionality to my project I just need to add these as submodules.
The advantages of this are:
Common code is kept in one place, versioned and backed up.
Having small repositories for code that does just one thing encourages writing modular code with minimal dependencies.
Submodules are added to a repository at a particular revision. So, if you change your common codebase, these changes are not automatically applied to the clones - you have to explicitly pull in changes. That way, if you accidentally change something that could break one of your projects, it won't appear suddenly.
If you set up your submodules properly, you can make changes to the common code from within one of your projects that can be pushed to all other repositories. That way you can work locally.
Your entire project is in a repository, without references to other projects, so you can move them, save them, archive and restore them without worrying about where the references point to.
I have a project A. This produces a product that's working and already submitted to the app store etc. Now, I'd like to create a new project, let's call it project B, and I want B to be based on A. Obviously B will add more UI and behavior on top of A.
After doing some research, the only option seems to be using cross-project referencing, because I'd like to reuse Project A's XIBs, images etc in Project B. Am I correct in assuming that cross-project referencing should work in that scenario?
Well I'm having some serious problems in getting this thing working. I'd like to achieve project level reuse. In Java or in .NET this wouldn't even be a consideration, the technology allows that. Because iPhone doesn't support frameworks, I think the developers are pushed towards more primitive approaches like code duplication.
So, how can I tackle this problem. How can I create my Project B, based on Project A (including XIBs, images, etc)?
Thanks,
If A and B are so similar perhaps you could consider simply creating a new build target; this would give you a single project with target A and target B. Both targets would have access to any of the resources in the project.
If you have a fair bit of shared code then you can create a static library; iOS doesn't support dynamic linking to user-generated libraries, but it supports static linking just fine. This would make the cross-project dependencies useful, because you could have project B reference library A from project A and build it as a dependency.
I did this same thing at one point:
I copied and pasted the entire app and then had two separate apps that I could work on individually.
Contrary to popular opinion, it is possible to create iOS frameworks.
Maybe you could use a scm tool like Git or Piston (http://piston.rubyforge.org) and 'clone' the code. Do something like:
#add original project to git
cd /your/base/project/code
git init
git add . #Stages all files to check-in index
git commit -m 'Your commit message here'
Then
#clone the original project into a new one
cd /your/new/project/directory
git clone /your/base/project/code
git checkout -b aNewWorkingBranchName #create a new working branch to modify
#modify code to your <3's content, use git pull/push/merge/rebase/diff as required to track/update original project
This should let you develop the 'new' project independently, while allowing you to pull in changes when required. Piston allows 'vendor' branching against both Git or Subversion repositories, tying your new code to a particular remote revision. Have a look at its documentation.