SVN Structure for new version of app - android

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.

Related

How do developers who customise AOSP keep their changes under version control?

Fetching the AOSP source, is 134GB.
A checkout of a particular version of Android is likely to be many GBs.
How do developers who customise AOSP keep their changes under (their own) version control? (Given that checking-in a snapshot of an Android version's source will be many GBs.)
This is my flow, maybe not the best....
I don't like dealing with repo tool and multiple remotes, so I get rid of all the .git subfolders and create just one tremendously huge repository. This has the bad effect of essentially removing all the "history". So we have a server with the original sync for git blame if we need to.
First check-out for a developer will be time-consuming either way. To make it faster, we have a local bare git repo cloned. So people run git clone on the local server, and the switch the origin to the actual remote.
After all is set-up, the day-to-day dealings are not time consuming. Commits and pushes are quite fast ( maybe 5-10s ) even for a large repo like this. Thanks GIT!
Sorry for necro-posting, but maybe somebody find it useful.
I just use repo utility from Google, e.g. repo start.
Only first repo sync procedure take a long time,
even subsequent checkouts do not like so time-consuming.
If you check some popular ROM, e.g. GrapheneOS, you find they repo too.

alternative to git-repo ( aosp repo )

I have recently started to look into android development (aosp) and read about "repo" tool/wrapper that takes care of all the android's sub projects .
While I think repo does a fairly good job at what it does, I wanted to know if there are any alternatives to it.
I thought git submodules are sufficient for this but many posts on internet discourage use of submodules ( due to some "drawbacks" which I feel are not drawbacks at all ).
Keeping in mind that the source code for different sub projects should have their own releases or indipendednt code bases I am not sure if git subtree is a good solution for this.
It would be great if someone can point out some alternatives to repo or any other information about this.
The repo tool is the standard way to work with AOSP code base. Sure you can manually manage the repos yourself but that is going to be rather tiresome and error prone.
Otherwise using submodules or subtrees won't let you inter-operate with Google and everyone else working on the AOSP codebase, so unless you are planning to do a one-way fork of AOSP there are no alternatives to the repo tool for working on AOSP.
repo has one huge disadvantage: it detaches HEADs. You can't switch to specific branch under specific subrepo. Unless you do repo start
tsrc, as far as I know, has less functionality but doesn't have this specific problem.
Also, you can use embedded mechanisms of build systems like Bazel (git_repository/new_git_repository).

Git. Store several projects under the same repository

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.

How to backup relevant files?

My app is getting to the point where I will be highly perturbed if I lose the source somehow. This is a personal / single developer project, so something like Subversion might be overkill. I'm thinking more along the lines of the "Backup" agent that is a part of the GExperts add-on in the Delphi world. Is there such a thing (that would backup all the .java, .xml, sqlite, etc. files) specifically for or suitable for the Android platform?
In my opinion using a version controll system is not overkill at all. You can keep hand on changes all the time. Making features that you don't even know whether to include or not into main branch. Not only features but every complicated task also, for example refactoring. With VCS that's no problem to make fast fix to released product during development of a huge task which is incomplete.
I can't imagine working without any VCS. I prefer Git because is fast and easy.

How to version Android app in Eclipse?

I would like to know how Android app versioning is done when creating apps with Eclipse.
Now I've completed my first working application and would like to develop it further. But I dont want to mess with code of a working application until improved application will be in working condition. Now I can open up new project and copy/paste all code+resources, but it will have different package name (because of duplicating variables) and as I know same Market app should be within same package.
How is this done and what tools are needed?
Use version control for this. For your needs I think Git or Subversion would be enough. So take your working app code, check it in the VCS you chose (Git, Subversion etc), tag it for a release and go from there.
There are some other aspects here. You need to learn about version control and how to use it. And you need to learn about Eclipse workspaces. To address your issue here, you can copy the eclipse project into new folder, create a eclipse workspace there, and import/add this new copy of project in it. This way, you will have one workspace for the working app, and another for your improved app.
Hope this helps you understand. If you are new to programming it may take a bit to wrap your head around it. Good luck.
You can keep your code under version control. Google offers free hosting but it can be seen by other people (if they look hard enough for it). The safest bet is to set up a free SVN server on your computer.
After you have the code under source control, you can access it through a free SVN client.
On Eclipse I use Subclipse together with my own Subversion repository. It works great.
Here is the link, Androids website accepts Git as a standard subversion system, with Repo and Gerrit as helper tools based on Git.
http://source.android.com/source/version-control.html

Categories

Resources