We have decided to follow the process of creating a new SVN branch for every new feature that we add to our mobile app. The ultimate goal behind this is to preserve the history for every single code change (this doesn't happen when we manually copy project folders into SVN instead of creating & merging branches).
My problem is that so far I am unable to merge changes from one branch to another.
I have already referred the following posts without success:
How to merge branch with trunk using SVN in android studio.
Android Studio Update Project: Merge vs Rebase vs Branch Default.
How to merge branch to SVN with Android studio.
How do merge specific svn revisions from branch to trunk in Android Studio 2.0.
Here is what I have tried so far:
I have two feature branches as can be seen below in Tortoise SVN:
I want to merge the changes in the branch Feature_A3 into branch Feature_A2. To do this, I am using the Merge from option in Android Studio's VCS from the A2 working copy:
It then asks me to select the branch to merge from (A3) or configure other branches:
I click on Configure Branches, just to show you the existing branch config:
As you can see, A2 is the Trunk and A3 is the Branch. Is this correct?
It then asks me what part of A3 I want to merge into A2. I select the /src directory (where the relevant changes are present):
It then generously gives me three different ways to perform the merge operation:
I select the third option as it directly gives me the changes I need to merge:
I click on Merge Selected and BAM!!! I get this error every time:
There is no clue as to what the "unresolved conflicts" or "skipped items" are. Why am I getting this error, and what should I do to merge the changes in A3 into A2 ??? Can someone please help ? All answers will be appreciated. Thanks ...
I have been following the official Intellij IDEA documentation below:
Integrating Changes To/From Feature
Branches.
Merging, Deleting, and Comparing
Branches.
Please note that:
Currently I am using Subversion, not Git.
The directory structure of my local working copies is not exactly
identical to that of the SVN repos. Could this be the cause of the error ?
THE ANSWER ...
Thanks to Peter Parker and especially Yoav Aharoni for their valuable feedback. As Yoav correctly pointed out, it was indeed the manner in which the branch locations folder was specified. It needs to be the folder containing the branches, not the branch folders themselves: And as Peter rightly said, checking "Include merged revisions" shows the merged history. I am now able to merge from within the IDE itself, and view the merged history in TortoiseSVN.
NO command line! YAY!!!
However, one last problem is that I am unable to view the merged history in Android Studio (Intellij IDEA) as described in Viewing Merge Sources. Does anyone know how to achieve this in Android Studio?
Phew, haven't used SVN in a while... :)
But from what I can remember Branch locations should be the folder containing your branches folders (and not each individual branch folder).
You see, typically a SVN repo follows a standard naming convention and folder structure:
trunk/
branches/
Feature_A2/
Feature_A3/
tags/
v1.01/
v1.02/
and so on...
trunk is where the main development takes place, and branches are for features, long-term or risky projects, or for different stages (such as QA and pre-prod).
So, as far as I remember, Android Studio expects you to set Branch locations to branches folder. In your case I think it should be http://192.168.0.64/svn/.../Android/Feature.
Also, your trunk is not Feature_A2 - Feature_A2 is just another branch.
Although I can't see the content, I think http://192.168.0.64/svn/.../Android/Development might be your trunk.
Which shouldn't bother you much, since you don't have to merge to your trunk, you can also merge between branches (e.g. merge Feature_A3 into Feature_A2).
So, to recap:
Although not mandatory, I recommend renaming your folders to match the conventions (you can easily do it by right clicking in Tortoise SVN, but only AFTER all teammates commit, otherwise merge will be a HELL for them).
Try setting Branch locations to http://192.168.0.64/svn/.../Android/Feature
And Trunk to http://192.168.0.64/svn/.../Android/Development (only if it indeed contains sources, similar to Feature_A2/3)
Consider "tagging" your releases in a tags folder (it's pretty much just copying the trunk/branch folder to tags, but you have a command for that).
If you do so, you can also add tags folder to Branch locations, that way you'll be able to compare your current source with any previous release (which is handy).
P.S: "unresolved conflicts" error can also mean you have unresolved conflicts (duh :)). Conflicts are are usually created when both you and a teammate change the same lines in file (or if he deletes a file you changed) and you update to get his changes.
SVN won't let you merge until you manually resolve these conflicts/changes.
You can find conflicts in the Version Control tab at the bottom, they'll be mark in red.
(But I don't think that was the problem in your case)
Let me know if that works for you!
I'm not an SVN expert, but I think you will need to change you directory structure. I believe that even though it is just a convention, svn uses the directory structure for merging of branches. So your directory Structure should be:
SVN
/Android
/branches
/production
/featureA2
/featureA3
/tags
/trunk
/IOS
/branches
/production
/featureA2
/featureA3
/tags
/trunk
Even though the TortoiseSVN Repo-browser will allow you to move your directories around, a lot of meta-data is stored on each directory and is used to handle the merge process, so you may have to start your repo again. See the subversion best practices guide and strategories for repository layout for more details on how to setup your repos. All that said, I would hesitate to rely on Android Studio's svn integration to do heavy lifting like merging of branches as (although most things in JetBrains tooling is fantastic) it's handling of SVN leaves a lot to be desired.
Related
Well I face this situation for long time in multiple projects. I always solve it on different ways, but I would like to know what is the best solution and explanation why this happens.
For example I git cloned new project from git and imported it in my android studio. At the beginning I am on master branch. Now I want to change to UnitTesting branch. But when I try to do it, I get message:
"Your local changes to the following files would be overwritten....". And it shows me misc.xml and gradle.xml files.
Why are these files changed and I don't have identical project that I cloned? I guess they contain some settings info related to the IDE that I use locally and the author of project on git has so it makes some differences to adapt project to my IDE..? Can I get little bit explanation.
And what is best approach to solve these kind of situations.
Thanks in advance!
I'm working with an internal tool for a few users building in AOSP tree.
To enable the build of this tool it must be added to PRODUCT_PACKAGES variable somewhere in the make-system.
PRODUCT_PACKAGES+=mytool
Upto now I have maintained this as uncommitted changes to /build/make/target/product/base_system.mk I could of course fork this module and maintain my patch or maintain it as a diff and patch it when a new workspace is created.
The project now needs to be shared with a handful of coworkers, so this is a good opportunity to make it less hacky and more maintainable as a forked module requires constant merges of upstream patches.
The project only maintain one git repo for manifest and one for the tool itself.
How could I add this assignment of to a Makefile without having to maintain it as a shell script or a forked version of one of the android gits?
You will have to add mytool to the device configuration in device/<vendor>/<device>/device.mk.
Even if you happen to find a way to make it work from within the mytool repository you probably shouldn't, because it is the job of the integrator to add modules to the device. He can hardly keep track if packages are not collected at a single point and I can think of even more problems if the integration is spread over many repositories, potentially each with an own set of access rights.
A solution I use when I want to share an early version without the hassle of integration is providing it in form of local repo manifest which combines the mytool repository together with a patched device/<vendor>/<device> repository.
I have an app with different version.
But every version have different Git repository.
So please let me know how we can manage that every build variant have different repository.
You should have different tags or branches per version, not different repositories.
From the same repo, you would then use git worktree in order to clone the repo once, but checkout the repo multiple times: see "Multiple working directories with Git?".
That way, you have different folders, each one with a different version of your project.
Since only the name/color/logo are changing, you would need:
one repo with all the common code
one configuration file with the right values for name/color/logo per environment
one way for your code to detect in which environment it is deployed: your code you then pick the right value from the config file.
The point is: one project, one Git repo: See the 12 factors app (in particular, the Config section).
I'm novice learner of GIT. i'm developing a social networking app. with a friend on Android which is a significantly massive project, so in order to synchronize our development, i decided to use Version Controlling. Now my project is on BitBucket. i'm decided not to waste time on command line and started using "SourceTree" to manage. Now i've certain confusion. i understand the fundamentals of Commits, push , fetch , branching etc. My question is :
Lets say, both me and my friend are working on different activities in our development branches of app. and making commits , but there are some files common to us , like Manifest.xml , build.gradle etc.. so when these branches are merged to "Production/Master" , how will the changes in these "common" files will get accommodated ? what if we both added code to a certain file and arrangement of lines of code matters , then how the merging mechanism will gives us a working project with integrated modules , if i'm wrong with my basic concepts, feel free to correct and suggest me some reference material. thanks in advance
When the same file is being modified in two different instance and then merges, there are two possible outcomes. If the code that is modified in in the files are in different sections, Git will merge the two files. If both files modify the same section of the code then Git will give you a merge conflict, which you will then have to resolve.
The following link goes over the details of resolving merge conflicts.
https://help.github.com/articles/resolving-a-merge-conflict-from-the-command-line/
Another option that should be looked at is rebasing.
https://www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview
If you and your friend modify the same file. When you do the merge could happen 2 things:
If both of you modify the same file in different regions of code. Git is capable to do the merge without conflicts.
If both of you modify the same file in the same regions of code. Git will do the merge with conflicts.
If the file has conflicts, it will looks like this:
... Some code ...
<<<<<<< HEAD
Line added by you
-------
Line added by your friend
>>>>>>> branch_name
... More code ...
You need to decide which of the two lines (Line added by you and line added by your friend) has the correct code. Then, delete the line that has the wrong code and the following lines:
<<<<<<< HEAD
-------
>>>>>>> branch_name
If you want, you can setup a tool to resolve conflicts like p4merge. You can download it from:
p4merge for Windows 64 bits
p4merge for Windows 32 bits
p4merge for other OS
You install this tool and then you need to setup with this git commands:
git config --global mergetool.p4merge.path 'C:\Program Files\Perforce\p4merge.exe'
git config --global merge.tool p4merge
To verify if all is right. Your .gitconfig file (C:\Users\windows_user\.gitconfig) will look like this:
[merge]
tool = p4merge
[mergetool "p4merge"]
path = C:\\Program Files\\Perforce\\p4merge.exe
After you have run the git merge command. To resolve conflicts using p4merge, you need to execute the git mergetool command. It opens the p4merge tool and show the conflicts like this image:
Merges are done via a couple of different mechanisms. The default usually works well, particularly for smaller teams. When things get larger then one of the other algorithms can be more effective. If there are areas touched by both parties, they are flagged as conflicts and you must manually resolve. I suggest reading the Git book for more details and examples:
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
I have now switched to Android Studio and saving my projects in Git with Source Tree. Whenever I add or remove any library from my module, its .iml file also changes. It really doesn't matter if I commit the *.iml because they get auto-generated in others Android Studio. However, here
it says you should store *.iml . My question is, do we really need to share our *.iml with others? If yes, why?
General best practice is to:
make projects as IDE-agnostic as possible,
do not commit generated files.
So the answer is: it's better to make such files ignored for VCS.
Yes, .iml Files are suitable for version control (see this comment)
It is also true to make projects as IDE-agnostic as possible, however, sharing .iml files does not break anything for people developing with another IDE. For them, they are just a bunch of relatively small files that don't concern them.
A good practice for teams using different IDEs simultaneously is to store each IDE's project files in the VCS, only excluding those which contain paths, environment variables etc. specific to a single developers environment. This way, anyone using one of the supported IDEs can enjoy the benefits of a proper, shared setup, like for example:
sharing build configurations
sharing dependencies
configurations for automatic code quality checks
There are more use cases, depending on the specific IDEs in play.
Edit: For IntelliJ, also see this FAQ
I agree that they are IDE-dependant files irrelevant to code and they should not be shared. But, then you should know how to regenerate them.
You may encounter with situations while your remote repo does not contain these files and when you clone the code and open in IDEA, it just shows a bunch of errors. Why? *.iml files are not regenerated.
You must import from IDEA with "File" - "New" - "Project from Version control". Only this can generated the files for you.
Rule of thumb - "Anything thats can be generated from source code should not be checked in" .