We built a library (SDK) for iOS. The source code of the library is closed (proprietary). The output we want to release is iOS frameworks, API documentation, setup guide, license file but NO source code.
We are discussing differant ways to release it to public.
1) One way is to create a public git repository hosted in Github and push all the output in it.
2) Other way is to host these files in our own server.
Is there any benefit of hosting it on github over hosting it on our own servers? I know git is to manage source files but in this case there is no source file that we want to publish, it is just the output. Is there any general rule to release iOS close source SDKs?
I am inclined more towards hosting the SDK (as zips) in our own server. I believe it is always the latest SDK you market in your website and not the older SDK.
Is there any benefit of hosting it on github over hosting it on our own servers?
The main benefit is cooperation/feedback: on GitHub, people can fork your repo and send back pull request.
If you choose that publication option, I would maintain a parent repo with two submodules:
one for the proprietary code
one for the public code.
You can push the former on a dedicated private server.
You can push the latter on GitHub.
Using separate Git repos (here as submodules) minimizes the risk to push the wrong data to the wrong upstream repo.
That proposition is for text files only though.
Using Release (as in this question mentioned by the OP msk) isn't a good way to distribute deliveries, because the repo would be empty (no code, since it is proprietary), and would only contain deliveries (not necessarily executables).
Release in GitHub is done to associate deliveries to codes (through tags), and cannot accommodate any binary of any size.
In the Op's case, distributing deliveries should be done through another referential (typically a Nexus one, meaning an artifact repository, without size limit)
Related
I have a Ruby on Rails project in my local machine and I use the RubyMine IDE to change the related source code.
Recently, I found a (remote) collaborator for my project, and I would like to share my code with him so that we can work on it. However, I am not sure on how to proceed to make it possible, and also have some troubles e.g. on how to properly manage Git version control with my collaborator.
Since we want our project to be private and cannot use paid services (e.g. GitHub), I thought about using Dropbox as a repository so that both me and my collaborator can change the source code but keeping advantage of using git version control features.
Have you some advice about? Is Dropbox is the right choice? Can you point me out to good resources?
Assuming you are saying GitHub is paid because you need it to be private, you can use bitbucket
You can use Bitbucket instead of Git. On Bitbucket there are 5 private repository are free...
Using facility of git which is provided in the xcode I have setup one project. I got the understanding about the branch, commit etc from This link
Now I want to share this project with the other developer who can make change in this project from his own mac. Both the mac is in the same network. So can anyone please let me know how can I achieve it. If any link from where I can refer would be great help.
What Xcode sets up is a local repository that is specific to you, and your Mac.
What you want is a central repository that developers can clone, so they can work in their own local copy of that repository. Each developer can push their committed changes to the central (origin) repository. Others on the team can pull those changes to their local copy.
You can host this central repository in-house, by using OS X Server and Xcode Server. Alternately, you can use a remote repository, as offered by sites such as GitHub and Bitbucket.
This is a much cleaner solution, and offers far more flexibility and functionality than the problems that will arise trying to work from a single local repository on a shared drive.
The scenario is as follows. I am working at a company that started out with one iOS application. Now, the company is interested in creating a second iOS application, that shares much of the same code base. The original application was not written with the intention of being reusable, as it was not known at the time that a second similar application would be created. In future, there may be even more similar applications that build on the existing code base.
We are trying to determine the "best" option with respect to how we maintain the source code going forward. So some of the options we're contemplating include single repository with shared library, one repository for shared library and one repository that contains all of the iOS applications, one repository for shared library and one repository per iOS application, etc etc. There's also the question of whether to use git submodules or not if using multiple repositories etcetera.
Currently, the two applications + library are all in one git repository. One of the advantages of this is that a developer can checkout a commit of the single repository and expect the product to build, without having to worry about updating multiple repositories. Basically, the developer doesn't have to be concerned with multiple repositories needing to move in lockstep with one another or requiring some specific combination of repositories commits for a build to work. The developer also doesn't have to worry about cases where another developer may have remembered to commit one repository, but not the other.
Here are some more things I've considered:
Submodules
I've used submodules before, but am no expert. My understanding is that the "super" repository containing a submodule also stores a reference to a specific commit of the submodule. This partly deals with ensuring that multiple repositories (i.e. application + library) would move in lockstep, though I'm guessing there are still issues with needing to manually pull changes from the sub module. Also, issues with a submodule commit not being available to pull if a developer happens to forget to push its changes and it is referred to by the super repository.
One nice aspect of submodules is that it creates a stronger semantic separation between the library and the applications which happen to use the library. Whether this is useful in practice, I'm not sure.
Single repository
As previously stated, this is what we're currently doing. Two applications + shared library code all in one repository. The greatest concern has been around the relatively non-existent ability to isolate changes between project one and two and the library. E.g. someone makes changes to both some library code and some application code in a single commit. Then, another developer just wants the changes in the library code.
One nice aspect of single repository is that everything moves in lockstep - nobody has to worry about keeping multiple repository versions matched. If using XCode workspaces, refactorings are even possible across the two applications.
Branching
Another option is to use some kind of branching model, either in a single or multiple repositories, to manage the code.
Ultimately, we're just trying to figure out a good model going forward for managing two or more iOS applications plus shared library code. Whether this be achieved via multiple repositories, submodules, branching models, or something else. Any general suggestions on the pros and cons of the various options?
Use submodules. You don't need to be an expert because they are really easy to use. Especially when combined with a GUI like SourceTree. I had the exact same scenario as you and that is what I did. SourceTree will even warn you if you are trying to commit a repo that has uncommited changes in a submodule.
A single repository is ludicrous. That would mean that every time someone new wanted to download a project, they would have to download them all.
Branching is going to turn out to be too complicated with making bug fixes that apply to all relevant branches.
The structure I have for my current project is:
Project repo (For the project I am personally working on)
-Project base repo (For shared code between team members)
--Utilities repo (For code that is reusable in any project)
Cocoapods, they make managing related code between applications simple.
We had a similar base for a suite of apps and initially it was a huge pain to manage but once you get custom cocoapods running you will never look back. You should check out this for a starting guide on managing your own cocoapods.
It's free, it's powerful and you will wonder why you never used them sooner.
I'm attempting to use some 3rd party libraries in my iOS app, as recommended by the SoundCloud API. I followed their tutorial, running git submodule add on each of the required dependencies.
However, when compiling, I had to make some tiny tweaks to the dependency projects in order to get them to link correctly - purely in the project settings.
I have never used submodules before, but from what I've heard, the parent repo tracks a particular commit of the submodule, right? If I want to include the little tweaks to the project files of the 3rd party libraries, so that a team member can pull it from origin, does that mean I will have to fork each of the dependencies first and commit each of the little project settings, just so that they can be included in the main repo? Or can I make "local" changes to the 3rd party libraries, and then push the main repo to origin?
This is quite frustrating, since I'm not actually changing the 3rd party libraries per se, it's purely a setting I've had to change so that they work correctly with my specific project. Is there a way I can include tweaks in the main repo without forking each library in their entirety?!
Thanks!!
You will have to put your modifications somewhere so that others can get them. This gives you two options, both of which start with the word "fork".
Fork the repo and maintain it.
Fork the repo and then make your changes so that everyone could benefit from them (eg, make the option you had to change into done sort of configuration parameter), then send a pull request back to the original. After it gets accepted, you can get rid of your fork, and others in your situation won't need to do this dance.
OK, I've been convinced that SVN is the way to go in a previous posting, but I haven't yet seen the epiphany. I'm not sure how I would set SubVersion up for my development environment.
Here's my current setup. I'm not keen to mess with it and it would be really nice if subversion could sit alongside it:
Work:
N:\Projects
N:\Projects\Lib
N:\Projects\App1
N:\Projects\App1\Help
N:\Projects\App1\Images
N:\Projects\App2
..etc
N: is on a separate server in the building.
There are several other development machines with the tools installed locally, but all development takes place referencing the files on the server - i.e. no source code is kept on the workstations.
Home
Laptop with same development toolset, and the sources in c:\Projects\App1.. etc, i.e. a mirror of the setup on n:\Projects at work.
The sources between N:\Projects and C:\Project are currently kept aligned with a custom app in conjunction with DropBox. File exclusions make sure that non-source files don't get sync'ed
I want to run SubVersion with this setup.
Where do I put the Repository?
Assuming I can have the repository in
a mutually accessible place, will SVN
remove the current need to sync
between work and home?
In order to embrace Subversion, you will replace your shared source directory with a Subversion repository that lives on the server. Each developer workstation will check out a copy of the whole source code locally (however, this could be a private area on a network server if you like).
You could retain your N:\Projects tree as a read-only copy of the daily build, or whatever. But one of the goals of Subversion is to mediate between two people editing the same file at roughly the same time. This is not compatible with a shared directory containing writable source code. Also, having multiple developers "share" the same Subversion working directory in some way is doomed to failure.
Why not create an internet accessible (free) trial Subversion account, and play around a bit, to get yourself familiar, before you move your entire source code tree into it. Just so you don't delete everything you own, by accident. Maybe start with one dummy project. Host something on the internet. Without even paying a cent, you could use this site:
http://www.projectlocker.com/
Then you can set up your very own starter subversion server. You can create a brand new Delphi application (file -> new delphi application), and add a button, and double click that button, and write a message box thingy, or whatever it is you like to do in demo apps. Now create a subversion repository (perhaps they call them projects, up on project locker), and add the folders you saved this project into, to that repository.
Now you can play with (a) tortoise SVN, (b) the SVN integration build into Rad Studio XE, if you have Rad Studio XE, and (c) the version control plugins that come in the JCL, if you don't have Rad Studio XE.
Also, may I suggest that if you want to have any hope of knowing what you're doing you learn how to add and commit, and update, from the command line. It's really not that hard. And it will pay off later.
Knowing you can type svn co http://reposite.something.com/svn/myproject to check out a project to your disk, is very handy. Sometimes, I think GUIs are training wheels for your brain. You cripple yourself if you don't learn command lines.
A benefit to a hosted subversion service like the one I showed above, is that you have an offsite backup. Of course, such hosting is always free even for large projects, if you are writing something open source. Then you can host on sourceforge. Otherwise, you're going to (a) need to use your own internet accessible host or (b) pay for hosting, otherwise you're not going to be able to easily access your repository at home, and at work.
Personally, if it was my own business, or my professional job to write software, I would host my own subversion server, and it would be private (LAN) only, and I would use a VPN to access it from home.
1: You definitely want a repository accessible from both locations. Either that, you you will need to use a distributed versioning system, like Mercurial or Git
2: Yes, there will be no more need for your custom sync app. This is exactly the job for your versioning system. Syncing manually in addition to using SVN is not necessary and would even create lots of conflicts.
Your shared directory should be removed and a copy of the code present on each machine that is a working copy of the SVN repository.
Use your server with the files to place the SVN server on it or any server that all including your home computer have access to.
Commit / Update every day, multiple time a day and manage merges if needed .
For the home access the simplest is to either get a dedicated server on the net or redirect the correct port on your router (but you will obviously need some access control in place) so that your repository is accessible from outside. If needed you could limit access from your home IP or from a list of IPs with a good router.
The other solution as other said is another kind of version system called "distributed" where every commit is done locally in your own repository on your own PC and this repository is merged on the "main" repository to share code and the change of other members of the team are pulled back in your local repository (You don't need any "main" repository technically on a DVCS but for a company that's what you will have).
See Git or Mercurial for good DVCS (Git syntax sucks but it's the most widely used system and technically the best one).
Put the repository in the safest place. That usually means a good redundant server (disks, etc.), in a controlled server room, and one which is properly backed up. When you switch to a VCS, source code to work on is typically in local machines sandboxes, because each developer must have its own. Then changes are get and sent to/from the server. Be aware that some tools may have issue is on a remote directory, because of the way for example the SMB protocol works - check they are supported explicitly if you need to use them. Unless you have paramount security needs, IMHO working in local sanboxes is faster and easier.
If you can access the SVN server from home (i.e. via a VPN), it will be not different than working from the office. You will "sync" (update/commit) your laptop sandbox the same way, you don't need a local server and repository. If you need a local server (reason could be you can't access the central repository from outside, need to work disconnected yet version files, etc.) there could be ways to replicate across SVN servers, but at that point maybe a distributed VCS should work better in such scenario.