I want to move files from Project B to Project A.
There are answers on stackoverflow about Modules, but that also looks like a lot of work to refactor the Project B as a module.
Another way is the manually move the files from Project B to Project A, but there would be sync issues when the files from Project B are updated. Is there an easier solution?
The reason I am doing this is Project B is a checkout system that can be used for various projects.
It sounds like project B really needs to be gemified into a rails engine.
When you say files do you just mean code?
You can create a gem from Project B (and treat it as an external service, if it is set up to act as such), or you actually mount Project B onto Project A. There is a RailsCast on Mountable Engines, or you can check out the official documentation on Engines.
Related
We have a very big iOS application with multiple features, each feature has their own flow, some feature depends on another feature and a common datasource class to divide between each feature. Since because of this much code project taking lots of time to compile.
Can i divide the project into multiple projects and add into a workspace and compile only those projects in which making change.
I am not able to find how i can create dependency between projects and how can i access files form one project to another.
I don't want to create static library and into another project.
Any suggestion would be helpful.
I'm actually working on a project in a similar manner.
I saw this blogpost from hubspot which has some insights on what you are trying to do. It talks about separating the application 'flows' into cocoapods which can be worked on separately.
http://product.hubspot.com/blog/architecting-a-large-ios-app-with-cocoapods
I'm working on several personal ios apps using xcode/git to dev and manage my projects. Now as time goes on, lots of classes have appeared to be reusable so I would like to build a personal 'engine' out of them.
Ideally, I would make a separate repository in my git account for this engine, and make all other projects refer to the engine by importing header files and linking compiled modules, i.e not caring about engine implementation.
What would be a reasonable way to do this? My problems are essentially:
How to organize repositories on both remote and local machine? Let's say there are project A, B and engine E. Both A & B wants to take advantage of using E.
How to configure A & B so that in linking stage, compiled modules from E are available to the projects?
Thanks.
If all projects have deployment target greater than or equal to iOS 8.0 you can setup your engine as a framework (watch this WWDC if you don't know how to set it up). Otherwise a static library is another good choice.
This is the extension of the following Stack Overflow question
Scenario:
Visual Studio Solution has projects A, B & C.
Project A is core library used by B & C.
Remote employee has permission to access only project C (which needs project A).
Question:
How can remote employee build and test project C which references project A, while remote employee has permission to access only project C.
Is it necessary to share project A with remote employee or is there any way around.
You can simply remove Project A from the solution. Obviously, the other projects would still need the relevant dlls.
If there is very sensitive information in project A then I have the following suggestion (of course this will depend on your architecture):
Create a public interface for project A, put this in Project D or something.
Make project A use this, then create a mock for the Project A interface and provide this project instead.
This would give all the dependencies necessary, and mean that you don't have to provide the dependant dlls. It is also good practice for unit testing.
In order to solve this, you need to
Move project C out of the solution into a solution of its own.
Change the project reference from C to A to a binary reference so that C references the compiled output of A. In order to do this, place A.dll in a directory under the newly created C-solution. Also add A.dll to source control so that the remote employee can retrieve the solution and A.dll from source control.
If you make changes to A that are required in project C, you need to check out A.dll, substitute it by the new version and check it in again.
Of course this means that the effort is higher if you want to propagate changes made to project A to the newly created C-solution. But it separates the environments cleanly from one another.
This approach also works if you want to follow the excellent suggestion of #pm_2 about extracting the relevant interface of A and provide only a mock version to the remote employee. In this case, you place the interface dll and the mock version to source control.
If I'm creating a rails app and will also be writing other code for the project (think tools and background processes that will be run separately from the website), how should I structure the repository?
If my project is called Foobar, is it better to name my repository/top level directory foobar and then name my rails app "website" so that I don't end up with a directory structure like foobar/foobar/...? Should I create them as separate repos on Github so my rails app can be its own repo?
You don't need to move your supporting tools outside of your project directory.
There are already subfolders which are meant to include things "to be run separately from the website" (for example, /lib/tasks and /script folders). It's absolutely ok to create your own /tools or /any-other-name-you-like subfolder inside your project directory tree.
And especially background processes - it's so likely that they will be closely connected with project internals... they are certainly part of the project.
If it's an actual self contained entity, roll it up in a gem so you can use it in other projects easily. That way it can have it's own repository, test, etc... The more you can break apart your application at logical components, the easier it is to maintain in the long run.
Just because the other code runs separately doesn't mean you have to have separate repositories. If the code is somehow related to each other it's fine to keep it in the same one.
I have an app that I've been using to develop some ideas that now seem to belong into a reusable framework (a lib). The whole thing is in a local git repo. I've lots of classes that belong to a lib and a some other classes that use them and present views for testing.
I want to move out the test code and leave a library and a separate app for testing. Have you done this? Do you have stumbled into something specific? Any advise?
Of course I could just move everything piecewise into different projects but I'd like to evolve the thing so I don't lose my GIT history and everything is seamless..
If you are going to develop libraries, use submodules or subtrees. Subtrees is a contribution project to git. Submodules come with it out of the box. Check http://progit.org/book for more info on submodules.