I've been learning to develop against the Android source tree, and while things are going well I'm not sure I've completed things in the most efficient way to merge into future versions.
Background: Android has many repositories that fit together. In some cases, a repo uses branches with names like "android-5.0.0_r6" to delineate a specific release. In other cases, that branch doesn't exist, instead, a tag exists with the name "android-5.0.0_r6".
My method: What I've done is create a new branch, called "nowsci-5.0.0_r6" based off the branch or tag (depending on which that repo had) for the repositories I needed to modify. I then made my changes, and pointed the android manifest at my new repos and everything seems to work fine.
My question: What should I do when "android-5.0.0_r7" rolls out? Is there an easy way to create a new branch of "nowsci-5.0.0_r7" and merge my modifications from r6 into r7? Or should I have done this completely different?
Here's one of the repos for example: https://github.com/Fmstrat/platform_frameworks_base
Thanks.
Follow their lollipop-release branch instead of the android-5.0.0_rX branches.
Related
I am working on Android project with 4 developers.
and the Client order the following :
New design for the app (4 developers)
Keep updates and fixes till new design ready (1 developer)
My issue is :
How to apply the above on Git repository (branches)
Shall I create a new branch for re-design and another one for update and fixes ? and what is the best usage to avoid code moving and repeating ?
some updates and fixes may affect java classes that under design changing.
Advice, please.
Very thanks
Since you are using Git, this can be done easily via Basic Branching and Merging workflow.
Your team should know how to apply Git operations like branch switching, merging and how to solve branches conflicts.
A full article about this can be found in Git documentation here
is covers a case similar to yours.
We currently offer an Android product to our customers. We are looking to branch our application into two to serve two purposes. But much of the code and the domain layers will be the same. We might add different features henceforth to the two different products.
Maintaining two code repos for these two products wouldn't really cut it because if we were to fix bugs or change things in the domain layer, we'd have to do it twice. Is there a way to deal with this situation?
I did read upon Product flavors. Is this the only solution?
Product flavors can be helpful, but isn't always practical if you try to implement different features.
If a large amount of code is going to be equal in both apps, consider moving that code to a library. Then you can create two separate projects to offer different features and use the library in both products. This way you can easily serve two purposes but the common code is still maintainable.
though non-convectional you can use Git to do this have remote repo that carries all the common files/branches clone the repo twice each local repo with common branches and diffrent branches representing where the app differs
all update your remote repo with work from common branch and always merge your local repo from the diffrent branch to common branch hence all common branch will always be carring all that is common while the diffrent branch will be updated from the common branch that is passed from the remote repo to the other project
I am using Mercurial (with TortoiseHG) to manage my Android project and recently had to branch it due to the app getting a parallel, branded version with different package name.
I have done some research and succeeded in separating everything, but now after a few days I am starting to find it hard to maintain both branches. Any change in com.myapp.firstbranch needs to be transited to com.myapp.secondbranch manually.
Worse still, I have every reason to suspect that more branches are to follow, which would require me to introduce any changes and bugfixes between many branches.
Does Mercurial and/or Tortoisehg offer any support for such situation? A simple merge does not work, because of different package names (the VCS sees everything as separate files and puts two versions of the app in one folder).
Ideal solution would be a tool which would allow me to sync only selected parts of selected files with no regard to imports, packages and so on, just plain text replacement.
I can't imagine (please explain deeper), how different package name can interfere with Mercurial branches. You have different trees inside repo? Or renamed files in branches (anyway, Mercurial track renames and can correctly merge renamed files in branches)?
When I faced such task (maintain different customer's branches, based on historically common codebase), I finished with MQ-patchset (patch per target for customer-specific changes) and single branch with common code in changesets
You can create+define different merge-tools for your repo, which will merge different files according to different (your) policy, not just interactive merge in GIU-merger (see internal:* mergetools as example)
Additions
I'll ask to show (at least part of) hg manifest for branches (or just ls of Working Dir) (just because I know nothing about packages, it's structures and Android-development in common), but, AFAICR, if you have /firstbranch in initial branch, which in second branch was renamed to /secondbranch, Mercurial will honor this change in branch-merges. Another idea is eliminate parent-tree from versioning as much as possible and move task of creating proper tree of package into build-tool
No, I had "trivial" tasks of adding|changing|removing objects (customer's branding), but, from my POV, "all imports, package relations and so on" are, technically, just changes in code (and possible - trees), which patches can hold
Custom mergetools have to be mostly easy hand-made scripts with minimal logic in it. Try to read Wikis: Merge Tool Configuration (part 2) and Merge Tools as starting point and this excellent example of creating own merge-tool for merging .hgtags
Imagine mobile application that is planned to be implemented for both iOS and Android.
Development was started from the iOS version only and now the time has come to start with Android one.
iOS application's code is stored at its' own Git repository that named after the apps name, e.g. "MYApp".
Now I would like to create one common repository for both iOS and Android applications and name it again after application's name: "MYApp".
It is not a problem at first glance.
Just create repository, create 2 subfolders there and start working.
But.
I would like that Android developer could work only with his folder and iOS developer only with his one too and both of them could see only their own folders related history (log).
I worked with SVN previously.
Usually I created subfolders and you could checkout any of them to work only with this subfolder.
History was also filtered to your scope.
I'm stuck with implementing the same under Git.
Please, help me to find right direction.
I will sum up solutions suggested.
Use branching for different platforms. I don't think that it is good idea, because branches used for another purpose. It seems to me very "jacky".
Use submodules. Just create as many repos as platforms you are targeting to, name them "MYApp-iOS", "MyApp-Android", etc. and finally end up with "master" repo, that could be names as "MYApp" (without any suffixes). Then add all related repos to "master" one with git submodules feature.
Use git slave. Investigating...
Please, feel free to edit this list to brainstorm the problem.
There is a way to keep to kind-of-related separate projects in a same git repository utilising git branching.
But keep in mind that that is not why branching was implemented into git. One of its uses would be development of a radical new functionality to your app that might not see the release any time soon for example.
On the end: it is a matter of opinion. If you are prepared to administrate a more complex repository just to keep both codes on the same place - you can.
I would definetly make two separate repositories though. Couple of opinions on this topic can also be found here on SO: Git branches with completely different content
EDIT:
gitslave seems to tackle your problem. You might want to give it a try.
I am working on new version of an app. What SVN structure should I use for creating the new version of the app? Should there be a trunk and than branches for each version 1.0, 1.2 etc? 1.2 is really based on 1.0 and not on the trunk? So I would like clarification on how to structure this? Its really a several projects like model, ui etc and and the model does not change quite so much with reach major version/release, but the ui project does. So I would like advice on how to setup branches for say version 1.2. Also with SVN should each developer have their own branch?
If you are starting a new project, it is good to start with typical layout like this:
trunk
tags
branches
At least the trunk should be created initially, as you will probably put your initial code there.
Under branches, you can store feature or maintenance clones of the trunk, or just any other branches.
In any case, all this is just a widely used convention; SVN functionality does not depend on naming or layout at all. However, some higher-level tools can - for instance maven-release-plugin...
Before you commit to SVN, please, take a few minutes to read http://hginit.com/ and think about using distributed version control system (DVCS), like Mercurial or Git. It makes life so much easier.