How can you keep, on SVN, the reference to its original location on a folder/file when moving it? - eclipse

I've created a feature branch to work in parallel with the trunk.
In the brach I've done a big amount of structure (folder) changes. For example, I've moved folders that before were on:
application/views/scripts/users/*
to:
application/modules/user/views/scripts/users/*
Now, I'm trying to do a merge from the trunk to this feature branch and I'm founding a million of tree conflicts! And the issue is that since this tree conflicts appear, no file inside that tree is merged against anything.
I mean, I find a tree conflict on:
application/views/scripts/users (SVN message: "The last merge operation tried to modify the directory 'users', but it was deleted, moved or renamed locally")
and none of the files and other folders that were inside that path have been merged.
Is there a way to recover the "link" between the original location of a folder and the current one?
Can I do something to deal with this issue?

More than a solution, I can give a workaround, that is the one that I've used, becuase it seems that there's not really a solution for this.
After a little research I'm close to sure that SVN doesn't support this kind of feature for merging. In the documentation of TortoiseSVN it is said that:
Local missing, incoming edit upon merge
Developer A working on trunk modifies Foo.c and commits it to the
repository
Developer B working on a branch moves Foo.c to Bar.c and commits it to
the repository
A merge of developer A's trunk changes to developer B's branch working
copy results in a tree conflict:
Bar.c is already in the working copy with status 'normal'.
Foo.c is marked as missing with a tree conflict.
To resolve this conflict, Developer B has to mark the file as resolved
in the conflict editor dialog, which will remove it from the conflict
list. She then has to decide whether to copy the missing file Foo.c
from the repository to the working copy, whether to merge Developer
A's changes to Foo.c into the renamed Bar.c or whether to ignore the
changes by marking the conflict as resolved and doing nothing else.
This means that you have to decide, one tree conflict at a time, what to do. And this is not the worst part. What is really unacceptable in my case is that every time I do a new merge from the trunk to this branch I'll be forced to deal with this conflicts again.
The workaround
Replicate the structural changes made on the branch into the trunk (with its required changes on code) and make it work with them.
After commiting this changes both structures of files, the trunk and the branch will match, so later merge operation won't complain anymore.

What i understand from your issue is that you have done a lot of folder structural changes in your branch and since these changes are not there in your trunk and when you are trying to merge you are getting the error.
As per your statement, "Now, I'm trying to do a merge from the trunk to this feature branch"
At the first place when you have taken a branch out from your trunk and did the structural changes in your branch then you should merge these changes from "branch to trunk" or if you simply want to get the original structure ("recover the original location of folders")back then just revert the changes you have done in the branch.
Hope this helps.

Related

Switch branches and take only specific changes with you

I’m still fairly new to the Git way of thinking, and I use it almost exclusively through the VSCode GUI and the Github desktop application, so bear with me if my thinking or terminology is backwards or sideways.
I frequently find myself in the situation that I do some work, then realise some of the work I’ve just done should have been done in a different branch than I’m in and need to move those changes to another branch. But this only applies to some of the changes in the current branch – the rest of the changes in the branch do belong where they are and should stay put. Usually it’ll be just a small handful of files I want to move, while perhaps 40 or 50 files should stay where they are.
There are lots of questions and tutorials on how to change branches and move all your uncommitted changes to another branch; I can also find questions on how to cherry-pick from an existing commit (like this one – but Google as I might, I cannot find any descriptions of how to move only specific, selected, uncommitted changes to a different branch. That is,
the changes are not committed in the current branch (and I don’t want to commit them there, because they don’t belong in that branch)
the changes to move are only a subset of the total number of changes in the current branch
after the move, the changes should disappear from the current branch and be added to existing changes in the other branch so that I can commit them in that branch
I can cherry-pick the files manually (file by file) or I can stage or unstage the particular changes I want to move or not move; either way is fine with me (or if there’s another way, that’d be fine too).
Theoretically, I would imagine I should be able to stash the changes in current branch excluding the files I want to move, and then switch to the other branch. I’ve found a description of how to stash specific files, but not a way to do the opposite, stashing everything except specific files.
Is there some relatively simple way to accomplish this?
Of course, as always happens, a solution occurred to me right after posting here… Very possibly not the best or easiest way of doing it, but it works.
It can be done in a few, relatively simple steps combining staging and stashing:
Stage the changes you want to bring over to the other branch
Stash your unstaged changes with git stash -ku (k for keep-index, which limits it to unstaged changes, u for including untracked files)
Switch to the branch you want and commit the changes there
Switch back to the branch you were in and apply/pop your stash with git stash apply git stash pop
For reasons I don’t really understand, the staged changes also reappeared when I applied my stash, but since they were now committed in the other branch, I could just unstage and discard them in the current branch.

Why does git stop commit when some other file was changed?

I've got a project on git, assume it has the following files:
HelloWorld.java
README.md
pom.xml
I edit/commit README.md using Github's editor; no problem. Then, in eclipse using eGit, I edit HelloWorld.java, but when I attempt to commit and push that file, I get an error: non-fast-forward. Unless I do Pull first I can't commit the java file. Why is this the case? Using SVN I never had such a problem. Why does Git not allow me to commit a file when some other, unrelated file in the project is changed? I read up on this but I still don't understand the rationale behind the issue.
BTW, I'm making all changes on master for now.
That is because git is making sure your repository is up to date with the master before you commit changes. The problem is with pushing not committing. You can't push to a repository that you haven't got all the changes for. What you can do is create a new branch with your changes and merge that with the master later if you want, that is the system git uses for what you want to do.
An SVN server will do some types of merges itself, particularly when the changes are to different files as in your case. Since SVN represents branches and tags as different parts of a single tree and a single repository can contain multiple, unrelated projects this is necessary.
But git will never do a merge on the server. And since a commit represents the entire tree, your situation is a merge even though no single file was modified by both sides that need to be merged.
Even though changes being restricted to different files guarantees that there won't be any textual conflicts between them, there can still be semantic conflicts. Imagine if you're working on a change to a library function which requires all callers to be modified, and before you push that change out another developer adds a new file which contains a new call to that function. If that new file is the only change the other developer made, SVN would allow you to commit your changes and handle the merge on the server even though that will cause the code to be broken. By requiring that all merges happen under developer control, git at least gives the opportunity for this type of conflict to be caught; even though in many cases a developer may just do an automatic merge and push the results without any checking.

Branching and merging in Subclipse

After following all the articles I could find and trying it myself in many different ways, I'm getting a bit desperate towards performing branching and merging in Subclipse.
All I get is tree conflicts (even for example projects), errors ("file already exists")...
I've used svn copy as well (which apparently is a better practice than setting a branch property) as the built-in branch support.
How to branch a directory to a second one, in the best way possible?
And how to merge changes from any of these directiories to the other one?
So I figured it out:
Creating the branch
Right-click the trunk folder, select Team > Branch/Tag. The Copy to URL: path must be an absolutely new, non-existing path; you can't either select an already existing path, or create a directory through the dialog and then choose that one.
Then click finish unless you need something else.
Switching to the branch
Update to HEAD, right-click the project folder, select Team > Switch to another Branch. Click the Select... button. If the folder you just created doesn't appear, right-click the browser and refresh. Done.
Merging from the trunk to the branch, or viceversa
First, make sure the Collabnet Merge Client is installed. You'll find it in the same directory that one uses to fetch Subclipse 1.X. Otherwise chances are you'll get tree conflicts.
Right-click either the branch or the trunk select Team > Merge. Choose Merge a range from revisions if the merge goes from the trunk to the branch. Otherwise select Reintegrate a branch.
Click Next. Select the merge source and you're done.
You should only branch and merge the whole project. Not individual directories inside the project. It makes things much simpler. For how to do it, refer to the SVN book. It's very well explained and details the usual techniques : feature branches, maintenance branches, etc.
http://svnbook.red-bean.com/

Merging of branch to trunk in SVN using Eclipse

I am looking forward to merge my code which I developed in a branch of SVN to the trunk. I am using Eclipse and I have been using Team->Commit to commit my updates to the SVN. But I haven't done a merge before. Please help me with this.
First of all make sure you are up to date. Update your working copy of the target branch, ie. where you are merging into. In this example we're working on the trunk of "core" and we want to grab the changes that have happened in the maintenance branch and merge them.
Resolve any conflicts. There should be no conflicts at this stage between the working copy and the repository.
Select the SVN merge option on the working copy. In Eclipse this is going to be found under the "Team" menu and called "Merge Branch".
SVN: Merging in Eclipse
Change the From URL to the specific branch you want to be merged into your working copy. In this example we're looking for the p400 maintenance branch (./core/branches/p400).
Change the From Revision to the last revision that was merged into the target branch. Essentially you don't want to keep merging the whole branch history, you just want to include those changes since the last time you merged. There is no easy way to determine the last merge point at this time in Subversion. You have to review your message log and look for the last commit that talks about merging. If you are disciplined about the commit messages you use for merging this should be easy (see below). Make a note of what that revision is -- you'll need this later when you commit your changes.
SVN: Merge with Eclipse
Change the To Revision to the latest (i.e. head). Make a note of what that revision is -- you'll need this later when you commit your changes.
Click Merge and wait. Depending on how big the differences are this may be quick or Eclipse my just fall over. If you have such an enormous change that you can't get it done in Eclipse you may need to make the range of revisions you are merging smaller. Or you may even have to skip certain revisions and do them manually if they are massive. We've had this problem from time to time when updating large third-party libraries. The vast majority of the time you will be fine.
Review changes and resolve conflicts. Once the merge is complete, look through the changes made to your working copy and make sure you address any conflicts you find.
Once all the changes have been resolved in the target working copy, check them in with a single commit. The reason you're not doing lots of commits is that these are changes that should have been documented in the branch from which you merged. The commit message needs to be in a specific format that details the merge and is easy to find in the future. We use the following format, but you can use anything that works for you -- as long as you stick to it.
Merging [source] to [target]; [repository]. Merge rev [start]:[end]
Enjoy!
In eclipse we have an option to merge. Right click the project , you will see "Team" option and on clicking it you will see merge option. There are three different options you can see in the merge.
To successfully merge the changes from the branch to the trunk, we need to switch the local workspace to the trunk (but make sure all the changes are committed to the branch before that). Once we do that we can use merge option and select "2 URLs" option. I put url for trunk as url 1 and the branch I wanted to merge as url 2. I could see all the incoming changes I selected "OK". All the changes are in my local now (at this point my workspace is linked to the trunk). Then I committed my changes to the trunk and hence merge from branch to the trunk was successful.
I would like to add for Point 8 .Review changes and resolve conflicts. ---
When working on conflicts manually- when you do copy from right to left on chunks of code - Be careful
Sometimes chunk of code gets added, sometimes it properly replaces the chunk.
Make sure there is no duplicate chunk of code.
Also, this is helpful-- What is the proper way to do a Subversion merge in Eclipse?

Subclipse: how to keep a branch in sync?

¿How would I do the operation described here, which is very simple from the command line, with the subclipse plugin?
I think I would make sure that my working copy is in sync with the branch, then I would go to "Merge...". I'm not sure what to do in the popup!
Edit: I have read somewhere that in the popup I must indicate the merge range as a range of trunk revisions: from the revision where the branch was opened, to HEAD. Makes sense. But I'm trying this out now with a test project and I don't get the new trunk changes on the working copy that points to the branch. I must be missing something, or it's not working!
Note: Subclipse 1.4.8
I got it now. It's how I said in the edit, as read in a number of websites...
in the popup I must indicate the merge range as a range of trunk revisions: from the revision where the branch was opened, to HEAD.
Apparently many people get confused with the from-to range. This is the range of revisions of the trunk/branch you're merging from. These changes are merged into the working copy you selected in the package explorer.
What I said about not getting it to work in spite of doing this was due to my mistake in selecting the trunk URL: the project was below a subfolder in the repository.
Assuming you're using the latest version of Subclipse (in the absence of information otherwise), select "Merge a range of revisions" and "Next >" -- you should be able to select the trunk (or another appropriate source) in the "Merge from:" box on the next page.