I am developing the following application and I'm thinking of making it opensource (add it to Github).
http://actibities-uniongr.rhcloud.com/pages/view-demo
In my local environment I have scripts loading temporary data for development purposes. Should that be included in the code pushed to Github?
In general, you should:
Include
Source code (duh)
Scripts related to the building, packaging, and/or releasing of the software
Documentation, explaining how to use those scripts
License (important!)
Not include
Sensitive data, including private keys and passwords (remove these before you initially commit or they can still be accessed). To remove data from an existing repository you should try git's filter-branch command.
Proprietary code (duh)
Large binary files, including:
Prebuilt toolchain (this should be present in the environment)
Large binary data that can be recreated easily using build scripts
Library source trees -- make these either a requirement for building, or use a Git submodule to include them.
As for the initial commit and upload, GitHub themselves have a pretty good tutorial.
I applaud your decision to open-source the project. Good luck!
Related
How can I download the source of an overleaf project with a command line script? I want to make regular backups of the source and it'd be better if I could automate the download instead of having to do it through the web interface every time. I'm not aware of any API that would allow me to do that, is there any?
I know that an ideal solution would probably use git-overleaf integration for proper version control and that's what I do for my personal projects, but for some projects I have to work with collaborators who find git too confusing and do not want to enable the git features to avoid possible confusions between the git history and overleaf's history, so that's not an option.
You may want to look into scripts that download zip archive of your project, for example overleafv2-git-integration-unofficial
This python script will download zip of your project, extract it, and delete the zip. It offers basic git functionality albeit largely experimental.
Sample usage:
overleafv2-git --email=your#email --password=yourpass --message="commit message" project-URL
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)
We have a project that utilizes SVN for source control, as necessitated by company policy. The project depends on about a dozen external libraries, which are found publicly on github. Until now, we've simply been downloading a zip file of each library we use, then add the source code directly to our project, but this is bad practice for obvious reasons.
We would like the ability to update the external libraries, and use them in other projects as well. Additionally, we will modify some of the libraries, and would like to be able to merge in changes as the main branch of the library updates.
How would one go about setting up this kind of project? I had thought about forking each git library, but I'm not sure how I would add the dependency to xcode and have SVN properly include the libraries. I've also looked at cocoapods, but if I'm not mistaken, they seem to be more for read-only dependencies.
Use a python based build system and install pysvn and one of the python git bindings - your build system can then handle (inter-)dependencies cleanly.
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 like to backup up the source code set for a project when I release a version. I use GExperts project backups, which seems to gather up all the files in the project manager into the ZIP file. You can also add arbitrary files to this file set, but I'm always conscious of the fact that I haven't necessarily got all the files. Unless I specifically go though the uses clauses and add all the units I have sources for to the project, I'll never be sure of storing all the files necessary to recreate the installable/executable.
I've thought about rolling an app to traverse a project, following all the units used and looking down all the search paths and seeing if there is a source file available for that unit, and building a list of files to back up that way, but hey - maybe someone has already done the work?
You should (highly recommend) look into Version Control.
e.g. SVN (subversion), CVS
This will allow you to control revisions of all of your source. It will allow you to add or remove source files, roll back merge and all other nice things related to managing project sources.
This WILL save your a$%# one day.
You can interpret your question in two ways:
How can I make sure that I backup at least enough files so I can build the project
How can I make sure that I backup not too many files so I can still build the project
The first is to make sure you can build the system at all, the second to allow you to clean up unused files.
For both, a version control system including a separate build system is the way to go.
You then - for each new set of changes - can use these steps to assure that both conditions hold:
On your daily development system, check in the new revision of your source code into your version control system.
On your separate build system, get the latest version of your source control system.
Build the project on the build system; if this fails, go to Step 1, and add the missing files to your version control system from your development system
Start removing (one-by-one) files from the project that you suspect are not needed, then rebuild until it fails.
When the build fails, restore that particular file from the version control system, then continue step 3 with the next candidate
When the build succeed you have the minimum set of files.
Now make a difference overview of the files in your version control system, and the build machine.
Mark the files that are in your version control system but not on your build machine as deprecated or deleted.
Most version control systems have good ways of generating a difference between the files on your development or build system against the files in the version control system (usually fine grained for each historic point in time you added/removed/updated files in your version control system).
The reason you want a separate build system (or two separate development systems) is that you want them to be independent: you use one for developing, and the other for checking if the build is still OK.
This is the first step that in the future you might want to extend this into a continuous integration system (that runs unit tests, automatically creates product setups and much more).
--jeroen
I'm not sure if you're asking about version control or how to be sure you've got all the files.
One useful utility I run occasionally is a program that makes a DirList of all of the files in my dcu output folder. Changing the extensions from .dcu to .pas gives me a list of all of the source code files.
Of course it misses .inc files and other non-.pas files, but perhaps this line of thinking would be helpful to you in some way?
The value of this utility to me is that a second housekeeping utility program then makes a list of all .pas files in my source tree that do not have corresponding .dcu files. This (after a full compile of all programs) generally reveals some "junk" .pas files that are no longer in use.
For getting a list of all units compiled into an executable, you could let the compiler generate a MAP file. This file will contain entries for all the units used.