Android Studio - Unable to Merge from Svn Branch

Android Studio - unable to merge from SVN branch

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:

1. 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).
2. Try setting Branch locations to http://192.168.0.64/svn/.../Android/Feature
3. And Trunk to http://192.168.0.64/svn/.../Android/Development (only if it indeed contains sources, similar to Feature_A2/3)

4. 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!

How do merge specific svn revisions from branch to trunk in Android Studio 2.0

I've find out what was wrong.

It doesn't depend on the version of Android Studio.

The problem was in wrong path to my trunk location:

My trunk folder contains multiple folders (yes, it's bad) and in configuration of SVN there was:

https://my_trunk

instead of

https://my_trunk/my_concrete_trunk_folder

---

---

After I specified location of trunk I got the dialog I wanted:

---

svn merge with renamed directory in branch

If what you are asking is just would you able to commit, the answer is yes.

If you are lucky enough that files been changed in r24 and r29 are just different files with what's changed in r30, then it would just work without any problem.

If some files got changed in r24 or r29 has also been touched in r30 then you might run into a svn conflict, it will work still as long as the person perform the merge understand code changes in both branches(trunk and your branch), this person not just need to solving obvious svn conflict(same area in one file been changed in both branches), but also need to solve the code logic conflict, that I mean things like no svn conflict but it won't compile anymore, or the logic conflict between changes introducing new bugs in your code.

My suggestion here though, after the merge, commit immediately after solving svn conflict, don't worry about any logic conflict. You solve the logic conflict in a separate new commit. This will save your some rare trouble when you merge back into trunk from my experience. As what the svn does with the merge, it modify the mergeinfo attribute, for your example mergeinfo in your branch would be something like

trunk: r30

svn would be using this information to figure out how should it perform a merge when you decide to merge back into trunk, if your branch has everything from trunk to date, it simply replace trunk with your branch assuming your solved all conflict, if you do cherry-pick however, it use thing merge info differently to try to solve conflict automatically if possible, so if you commit logic fix in a different commit it would less likely run into svn conflict.

The longer a feature branch runs the more problem you would be facing if trunk keeps changing in the meantime. But it is what it is, that's how branching works, you should have a plan about how often you are going to merge from trunk and how long you want to keep your branch. Try to slice your task to smaller pieces so your branch has a shorter life span, for example two weeks, it would make a big difference comparing you keep a branch for three month and then merge back all those changes into trunk.

Getting unexpected changelist during svn merge of folder of different branches

As described here, your command line has the following format:

svn merge SOURCE1 SOURCE2 [TARGET_WCPATH]

This generates the differences to apply to go from SOURCE1 to SOURCE2.

So in you case, this generates the differences to apply to go from branch accos_2.1.3b_ludz to branch accos_2.1.3_ludz. What you observed is fully compliant with this explanation.

For your expected output, you just need to invert the arguments, as follows:

svn merge .../accos_2.1.3_ludz/... .../accos_2.1.3b_ludz/... --dry-run

svn -- Time since last merge

svn log gives you the figure semi-straight.

If all merging is done on the highest possible directory level (as is best practice), then execute the following command:

svn log -g https://myrepos.tld/branches/single-private-feature-branch

you will get the usualy history plus revisions that were merged into this branch. Look for the string "Merged via: ". The first hit will be the last merge into this branch. You can optionally fetch the log entry of the revision given to make sure it is comming from the integration branch and was not merged from some other place.

All this can be done with simple shellscripting.

Hope it helps :)

C

Merging changes from two SVN repositories

It looks like you are looking for Vendor Branches.

As described in the Vendor Branches section of SVNBook, you can do the following:

This is a sample workflow which follows SVNBook instructions; you may
need to adjust to fit your needs.

1. Perform the initial import with svn import to your repository to
   <repo-URL>/vendor/current

2. svn copy the <repo-URL>/vendor/current to
   <repo-URL>/vendor/1.0 in order to create a tag, for example. (1.0 here corresponds to the open-source project version, you can use any name or version number in your real case).

3. svn copy <repo-URL>/vendor/1.0 to your development branch in the
   repository, for example to <repo-URL>/project1/trunk.

4. svn checkout <repo-URL>/project1/trunk to the same directory on local system which you've imported initially.

5. Now you can modify the data stored in the working copy and commit it to the project.

6. If some time later you want to upgrade the open-source project to a newer version
   (for example, OS developers release 1.1 version) with keeping your
   changes, you should svn checkout the <repo-URL>/vendor/current
   atop of the unversioned folder that contains 1.1 version of the OS project. You
   will be required to svn add and svn remove files that have changed
   their location between 1.0 and 1.1 version. This way you'll get a
   working copy that contains 1.1 version which you commit to <repo-URL>/vendor/current. This way you commit only changes between 1.0 and 1.1 version. Later you can svn copy the
   <repo-URL>/vendor/current to <repo-URL>/vendor/1.1 to create a tag for it.

7. If you want to upgrade the OS project in your development branch to version 1.1 keeping your changes, you can perform 2-URL merge with a working copy that contains your modified project data, the command-line would look like this:

   svn merge "<repo-URL>/vendor/1.0" "<repo-URL>/vendor/1.1" "<path-to-WC>"

The above description does not pick up file layout changes made between 1.0 and 1.1 versions of the OS project and you will be required to manually process them. If you want to automate the task of adding / removing files, you can use svn_load_dirs.pl Perl script (or similar python script) for this task. The script is available at
http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_load_dirs/
and is also explained in the SVNBook 1.7.

How to merge branch back to trunk in SVN with all commit history?

With Subversion 1.5 or later the merge is recorded on your local working copy in the svn:mergeinfo property. So this information is not lost.

You can see the merged revisions if you use svn log -g instead of the normal svn log.

Normal merges are performed as

svn merge -rREV1:REV2 svn://server/branch my_trunk_wc 

But if you use a branch it is sometimes more convenient to use a reintegration merge. In this case you should first merge all trunk changes to the branch using something like

svn merge svn://server/trunk my_branch_wc

(This merges everything that is not already merged)

And after you commit this change to the branch you can use

svn merge --reintegrate svn://server/branch my_trunk_wc

To move all changes over as a single commit.
(After this operation you should remove the branch)

svn strange tree conflit when a branch trying to merge from another branch using Intellij IDEA

1. Yes, it's possible
2. It doesn't correlate in any way with Intellij specially
3. While you don't show log of branches nobody can tell you more details

"Tree confict" error is ordinary case for Subversion, Subversion merge. It appear 100% on merge-trees, when in two future merge-sources,the same file (in different parts) is changed and renamed

In order to workaround: merge conflicted files (you'll see filename of file-in-question in temp-file name) and only after it - parent dirs

---

Related Topics