I need to maintain in parallel two version of the same applications. One for app store and one standalone (not app store) version.
My initial plan was to use the master branch for developing all feature that are common for both version. For standalone version my plan was to create a new branch, and in that branch to add a features for standalone applications, and the same for app store version.
Actually I tried my plan, but I have a problem with cocoapods. I have multiple dependencies that are common, but for standalone application I need to use a Sparkle framework. Now every time I try to merge master to one of my branches I have a huge conflicts with cocoapods files. That are very difficult to solve.
I was thinking about removing pods for my source control but than, when I switch branches I will need to do "pod install" every time.
Is there a better way to do this?
Thanks.
I strongly recommend to use Targets.
Look Apple docs and here.
Related
I want to have Meteor as a server and Ionic2 as a client. I currently have a headache with authentifiacation. It seems that there are two different approaches:
First is use of Meteor server and Meteor client with ionic-angular library. This approach described here
https://angular-meteor.com/tutorials/socially/angular2/ionic2
I guess the advantage of this method is use of Meteor native architecture, on the other hand I guess we're using Ionic2 just like a subframework and maybe loosing some stuff from native Ionic2.
The second is using separate Meteor server ('client' folder deleted completely) and native Ionic2. This approach described here
https://angular-meteor.com/tutorials/whatsapp2/ionic/authentication
This option is vice versa: use of native Ionic2, but it has to use libraries like meteor-client-side, accounts-base-client-side, accounts-password-client-side etc, which I'm not sure are native for Meteor.
The first approach looks better, because there is a ready-to-use UI component for authentification. But I wonder what issues I would have, when I come to the step of completing my applications for different types of devices.
Thank you in advance for your help.
These approaches are essentially the same for the authentication itself.
What you are pointing out is more about what mobile platform to choose to develop and run mobile projects.
In the first case, you use Meteor's built-in Cordova platform to run the app and Meteor's compiler and bundler plugins (like TypeScript package or Meteor core packages for Babel and UglifyJS etc) to develop the app. In the second case, you develop and run the app solely on Ionic 2 CLI.
But from the app logic point of view these approaches are absolutely same: you import the same Ionic 2 components and use the same Meteor packages with the only difference in the second case is that these packages are now NPMs not Atmosphere ones (essentially though they contain the same scripts since these NPMs are built from Atmosphere packages).
The reason why What’sApp clone is built in that way that differs from the Socially’s one is simply described in the README of
the What’sApp repo (see https://github.com/Urigo/Ionic2CLI-Meteor-WhatsApp). If to repeat: since Ionic is a one of the best Web frameworks that specializes solely in building mobile apps, it’s reasonable to guess that it’ll be (and likely it is) much more powerful in building them than Meteor itself. From that point of view the second approach seems more future-proof, I would say. You could think even of building your project in some way that will allow you to substitute Meteor easily with some another framework if you decide to use it at some point in the future.
If you are though concerned about using those NPMs mentioned in the second case (e.g., if the process of building them doesn’t look transparent to you), you could try this project https://github.com/Urigo/meteor-client-bundler to bundle Atmosphere packages you need into separate scripts and use them after.
I have a pro version and a lite version of the app that have nearly identical codebases. The difference being that the lite version has ads in various view controllers as well as in app purchases. I have each version on its own branch in Git with the lite version being the master branch currently.
I have localized the pro version, switched all strings to NSLocalized string, added localization files etc. I am wondering what the best way to merge these changes into the lite version without overwriting the differences between the two. When I open a "merge into..." session in Xcode, it automatically would overwrite the differences.
Is there a way to skip a block of code in a merge?
There may not be a solution for this but before I do it manually, I just wanted to check.
It's not a git problem but a project structure problem. You should never have tried to misuse git branches for this purpose to start with. Instead, you should have used Xcode's project / workspace facilities (or a framework) to organize the code itself so that it could be shared between two targets.
I feel that using Git submodules is somehow troublesome for my development workflow. I've heard about Git subtree and Gitslave.
Are there more tools out there for multiple repository projects and how do they compare ?
Can these tools run on Windows ?
Which is best for you depends on your needs, desires, and workflow. They are in some senses semi-isomorphic, it is just some are a lot easier to use than others for specific tasks.
gitslave is useful when you control and develop on the subprojects at more of less the same time as the superproject, and furthermore when you typically want to tag, branch, push, pull, etc all repositories at the same time. gitslave has never been tested on windows that I know of. It requires perl.
git-submodule is better when you do not control the subprojects or more specifically wish to fix the subproject at a specific revision even as the subproject changes. git-submodule is a standard part of git and thus would work on windows.
git-subtree provides a front-end to git's built-in subtree merge strategy. It is better when you prefer to have a single-repository "unified" git history. Unlike the subtree merge strategy, it is easier to export changes to the different (directory) trees back out to the original project, but it is not as automatic as it is with gitslave or even git-submodule.
repo is in theory similar to gitslave, but not as well documented for non-android operations that I have found. It is fairly dedicated to the Google Android development model and only natively supports a handful of git commands (though you can run arbitrary commands) and the limited native support doesn't support, for example, a centralized repository to push to and checking out a branch seems fairly difficult.
kitenet's mr is what you would want to use if you have multiple version control systems in use, but is mostly limited for git-only superprojects due to its lowest common denominator approach. There are ways to run arbitrary commands, but they are not as well integrated.
For some use cases, I have liked each of the following two simple approaches:
Nested repositories. If your software project has a plugin mechanism, with each plugin in its own sub-directory, it can make sense to git-ignore these plugin directories and, in your local filesystem, to make each of them into its own git repository. This way, all your files form a single directory tree, but are managed in different git repositories. It will not confuse git.
Per-package repositories. For software projects where you use some kind of source code package management system (gem / bundler, npm, pear or the like) it can make sense to put your re-used code into separate git repositories, then to make source packages from them, and then to install them with the package management tool into the parent project. Your parent project's git repository would only contain a reference to the required packages and their versions, while the actual code of these packages will be git-ignored as done with all other packages and external libraries as well. Compared to the nested repositories proposed above, this is a more elaborate approach as it allows to specify which package version is to be installed.
I currently use submodules for development and not just relating 3rd party libraries. There are some ways that you can make life easier with submodules, especially when they are the source of merge or rebase conflicts. Look to ls-tree to get the 2 commits involved on a conflict in the submodule. This is probably the most difficult part of submodules for people to deal with. For now scripting will make this much easier to work with. Future versions of Git should have better native support for dealing with them.
Hope this helps.
We encountered a similar issue when using Git submodules in projects where we had dependencies in a variety of languages. To deal with them, we built and open-sourced a tool called MDLR ("Modular") that gives you declarative version-controlled Git dependencies with similar functionality to Git submodules, but without the annoying workflow. You can install it and manage your dependencies with the instructions/downloads on the GitHub repo
Trying to figure out the best way to use Nuget in a development environment to manage our own libraries.
We want to standardize on Nuget way of doing things for our 3rd party libs, but would also like to use Nuget to manage our internal utility libraries, for developers consuming the in house libs this is great and everyones happy. However, for devs actively working on the Utility lib it seems to be more problematic, their previous process of build lib , build main app , F5 and go is now slowed down with publishing, and updating and potentially lots of packages, not to mention the moaning about additional process!
We use TDD on the internal libs but everyone needs to be able to debug and modify libs along with main app, have seen Phil Haacks demo on debug packages in 1.3 and read David Ebbos blog, but that fits different scenario.
So what is the best process for dev/debug cycles? if to use Nuget then we need to accept the existing constraints, or is there a hybrid practice people are using and maybe 1.3 gets closer to automating all this, or do we just avoid Nuget for internal packages which would be a real shame.
Loving Nuget, maybe wanting way to much from the little guy, feedback appreciated.
Thanks
I'd suggest you use separate network shares or feeds (similar to what myget.org supports in the cloud) for different scenarios.
You could imagine creating a CI share, a QA share, a Releases share, ...
Make people working on the referenced library do CI builds that drop CI packages on the CI repository for instance, and have them picked up by other projects (who just need to do a simple update, could be automated through PowerShell in pre-build: check for new version, if so, update).
Just make sure that when products release their milestones, they also release with released dependencies (could be as simple as switching feeds, releases will always have a higher version number than CI builds).
Hope that helps!
Cheers,
Xavier
If you're working on the source code for the lib and the main app at the same time, I'd say NuGet is probably not a good solution. I think it'll only work in situations where you work with a "stable" version of the library that don't need to change frequently during the development of your main app.
That said - is it possible the development on your library could be done in isolation? You already mention you're doing TDD on the lib, so why can't that work be done, then built, deployed, then the main app work done?
I'm wondering how Software Development Team distribute their Standard IDE(s)?
E.g. developing with Eclipse, custom Code formatter, svn Resository, Copyright Header..
At the moment my Team has a standard zip File which is then distributed withhin the developers.
Problem:
If one file, a Plugin or the IDE itself changes, e.g. new Coding Guidlines, Upgrade Eclipse 3.5.1 the whole distribution has to be done again. Every developer needs to unzip the bundel again. Imagine your working with different Workspaces (Jetty, different Tomcamt Versions, WTP) due to Project History That doesn't scale
I know that there are some related Articels
A new version of Eclipse just came out. Is there anything I can do to avoid having to manually hunt down my plugins again?
Manage Your Eclipse Install With A Local Git Repository
And some comercial Programs.
Eclipse also has a new Update-Installer Approach
But I don't see the Killer App. How do your team solve this? Is there a best practice?
I guess best would be a Program letting you choose your current Project and then downloads the configured IDE from the Server and leting you know if Project Config Files are Updated
For eclipse look at Buckminster it targets exactly your target I suppose, didn't use it personally through.
At my previous company they wrote a custom update agent that pulled from a centrally configured server which was updated by the team leaders. It worked well, until people wanted to install their own plugins.
Basically, a developer wanted a plugin, fought in futility to get it included in the default (managed) repo, installed it himself, then updates broke on his machine when the team lead had a sudden stroke of common sense and included it.
They never did come up with a 'good' way to manage it. But, at least they didn't put us all on terminal servers with thin clients.