I am trying to merge my development branch back into the trunk of my repo. Steps I took:
Switch to trunk
check that it is up to date, resolve any conflicts
Go to Team->Merge
Select URL : development branch
Start Revision: Revision when branch was created
End Revision: HEAD
OK
This should do the magic - it opens up the syncronize view which is fine, shows me all the conflicts, but there the problem happens:
In the compare editor I see two files:
Local File | Remote File (306)
This is really strange, the revision number of the remote file is actually the one of the file in the working copy (trunk) and so is the content. The local file has the content of the file in the branch.
Now the arrow shows correctly that I am merging from left to right (branch to trunk). This also happens when I click ok.
BUT I can only move changes from right to left!!! That's not what I want - I do not want to overwrite the changes in the branches with the old content of the trunk. I want to move the content from left (branch) to right (trunk). But I can't even write in the right file.
I do not know why it writes remote file there?? It's clearly showing the working copy file in the remote file window, and the file from the branch (for merging) is shown in local file.
Some bug in Subversive?
Thx,
Martin
Merges are never been easy with subversive (as mentioned in this old SO question), so may be doing the merge externally (or with subclipse) would be easier here.
If your client and repository are both at least in SVN1.5, Subversive new merge capabilities are better, but still dangerous as illustrated by this thread.
Since Subversive has been modified for SVN 1.5 the whole merge behavior has changed. One thing I really liked is the ability to choose what changes I wanted, apply that to my working copy and then commit to trunk.
Subversive now no longer does that but forces all changes onto your working copy and then you choose what to put in the trunk.
This is not only undesirable behavior but it's also dangerous (if you ignore the possibility of a revert anyway). I prefer to commit things I know work. We have a release branch which gets changes which may or may not need to be migrated to the trunk.
Well this seemed mysterious at first, now I shall provide a decent stab at updating this answer for everyone. This regards merging using the SVN Subversive client for Eclipse:
You are doing your merge correctly, starting in Trunk and then pointing to your file under your local Branch. Your files open up in the "Text Compare" window under the Team Synchronizing tab. If you do not see conflicts over in the left hand navigation column, then your merge has just happened. Yes, this is confusing and non-intuitive.
What the Text Compare window offers you is the ability to undo your change (or any others that may have gotten into your merged file unawares) before you commit it. Remember that you are pulling in the file from Branch, so the idea is that the Branch file is in Trunk but in a kind of virtual limbo until finally committed, and changing or undoing unwanted changes here references the file in Branch (obviously). That is why you only have a one-way pipe (Trunk to Branch) to overwrite those changed merged into Trunk via your working copy. Your merge has taken place, but it's not quite official yet.
If all looks as it should, right click the file in the navigator window (left pane in my Eclipse Helios install) and choose Accept from the drop-down. Then click back over to your main code-viewing tab (in my installation it's PHP but it could be whatever you are using) and then commit the file to Trunk.
If you want to test this, do a view of the file "as is" in Trunk before committing and you should see your changes reflected there if you have done your merge correctly. This appears to be the way it is working for me on an OSX Snow Leopard Macbook Pro. Not sure if it's the same for Windows or Linux folks. I assume it's essentially the same/similar process.
it's easy
check out trunk with check out as... give a different project name.
Now you have both locally as working copy, trunk you wanna commit to and the branch you are working on and whose changes you have comitted to the repository.
Now rightclick the trunk project (and I mean the project, not single files) - merge - select the branch project (again, PROJECT)
accept all changes to local copy
commit what you need to trunk as used to
all fine, delete trunk again and keep working on the branch
especially with branches this seems super easy and worked like a charm for me
Related
My team is supporting a small Java development team that had been working on a development branch with Eclipse and Subclipse. We've been periodically merging their changes associated with appropriate tasks and defects from this development branch to a release branch which eventually gets merged into a trunk that represents production. Based on best practices advice from CollabNet, we recently created a new development branch from the trunk and moved the old development branch to an archive directory. (The motivation for this is that eventually changes would accumulate in the development branch that never get merged anywhere else, and the development branch would become impractically different from the release branches and the trunk.)
Our java team was disappointed to discover that once they'd created their new Eclipse workspaces with the new development branch, file histories in Subclipse did not show all of their individual changes. Only the merge operations are listed. This makes sense since the new development branch was copied from trunk, which only ever had these merges performed on it.
But our Java team would like to easily reference the histories in the old development branch. What is the easiest way for them to do this? Some options I can think of are:
Navigate to the old branch in the SVN Repository Exploring perspective and examine file histories there. This involves lots of clicking through the repository hierarchy, especially to an individual source file. Is there a way to enter a path in this perspective and jump to it? Or is the only way to click through the hierarchy?
Maintain a separate Eclipse workspace with the old development branch. This means switching workspaces to see the individual developer histories. And it's easy to forget which workspace you're in.
Use Team -> Switch to temporarily switch the file or project to the old branch in your same workspace. Then view the history of the switched file(s). It's easy to forget what you've switched, which can lead to committing to the wrong branch.
Also, none of these options make it easy to compare what's in the new branch to what's in the old branch.
Are there any easier ways I'm missing? Thanks a bunch!
If you really want to follow best practices then you should look at trunk-based development. https://trunkbaseddevelopment.com
There is an option with svn log to show the original commits for a merge. This is the -g option when using the command line. In Subclipse, it is a checkbox on the History view. "Include Merged revisions". This will then expand the merges to show what was merged. Same option exists on Blame. It will make these operations take considerably longer to run in many cases.
The only way to fix this is to use a better process.
I'm running Eclipse Kepler Service Release 1 with egit for versioning. I've been using eclipse and egit for just a few months and am not up on all of it's intricacies yet. I've found some related questions here for git, but I don't really understand how to use egit to accomplish what the answers propose.
The immediate problem I have is that no files are visible in the project tree except for the libraries and WEB-INF under war. The files show up in the unstaged changes area of the Git staging window marked with an x as deleted. This is a jsp project running google app engine if it matters.
What got me to this point was attempting to checkout the master branch. I got an error saying the branch could not find 2 files and afterwards my working files in the current branch disappeared. The Git repositories view shows my current branch is the same as the one I had been working on, so these files should normally be visible.
Since I never chose to delete these files I have no idea what stage egit thinks it's in. I don't have a backup and my other branches haven't had recent changes merged in.
You can always see the state of Git as a text decoration next to each repository node in the repositories view of the Git perspective. Normally that should only show the branch name, but it might also be something like "Interactive rebase", if Git stops for user input in the middle of an operation.
If that is not showing the branch name you want, then just the context menu Switch->[branchname] should bring you back to the wanted branch.
If everything else fails, you can always throw away all local changes and have your local working directory reset to the state of any commit (or branch) by using context menu->Reset->Hard and select the commit (or branch) to which you want to reset. Be aware that this wipes out any uncommitted local changes.
In case of more questions, you should read the very detailed EGit user guide.
my problem is that sometimes I change git branch while working live in eclipse. But I do not know what should I do (in what order to to, to don't make mess in both projects).
So my procedure is:
eclipse is open (working on some problems)
git change branch
eclipse > selecting projects and clicking to refresh
work on eclipse, continue job
Is it all right or I should use first Clear&Build and then refresh projects? What do you think, is it important witch order do this while changing branch ? Please help because I am working with friends on big project and I do not want break anything.
If you are working on a particular branch and you want to preserve whatever it is you have been doing, you should add or commit those changes first (git add or git commit) to that branch before changing to a different branch.
If you have the same projects in both branches, then refreshing the projects after changing branch should be fine, but ideally followed up with a clean/build.
If you want to be really safe, you can first close the projects before changing branch, then refresh and re-open them after changing branch.
I have seen behaviour in Perforce that I am unable to explain. I took a branch of the trunk and worked on this regularly committing my changes and occasionally merging from the trunk to my branch to ensure there were not going to major conflicts when I reintegrated.
When this work was complete, I used the Perforce Merge/Integrate option to apply the changes to the trunk. After sending these changes for code review, I made some changes on the trunk. At this point, none of the changes had been committed to the trunk.
When I went to commit all of these changes, the diff showed the files exactly as I would expect. After submitting the changelist, the changes which were submitted were not the same as what was shown in the diff window. Instead, the changes that I'd made since the Merge/Integrate were not there. Doing a diff between the server and my local copy on the trunk had all of the changes to the same files made after the code review. As such, I had to do a second commit to mend the broken build.
I'm confused how this happened as I thought Perforce only kept one local copy of each file on the client?
Even if there is a flag showing the files have been tampered, where were the files it submitted? It definitely showed the trunk paths in the commit window, but I guess it could have got the files from the branch?
Another question would be, how should I have best dealt with the above scenario when using Perforce version control?
One mistake we've all made is to (a) integrate a file from one branch to another, (b) resolve it as "accept merged", (c) make local changes to the file prior to (d) submit. If you don't explicitly open the file for edit after step (b) and before step (c), the server has no knowledge of your local changes.
You made your first mistake editing things directly on your copy of trunk. Always use a task branch. It probably didn't cause the issue you were seeing, but if you'd messed up your task branch it wouldn't have broken the build. When looking at your local copy of trunk, ensure you've refreshed it from the depot. You'll get little yellow triangles if your local copy of a trunk file is out of date, editing and committing an out of date file on your copy of trunk is bound to lead to "odd" behaviour.
I'm confused how this happened as I thought Perforce only kept one local copy of each file on the client?
One copy for trunk, one copy for each task branch.
Specifically:
Why do I need to explicitly enable "Enable baseless merges" all the time? I am integrating from my branch to the trunk.
What does "Enable integrate over
deleted targets" mean? Shouldn't it
do this by default? If the file
doesn't exist, and you integrate to
that branch with the file, it should
create the file, right??
What does "Do not get latest revision
of selected files" have to do with
integrating? I should be choosing a
source revision, and a target (to
create a new target revision).
What does "Disregard indirect
integration history" mean? I've never used it, since it sounds scary.
I would be grateful to know, as I am a little unsure of what options to enable when I am trying to do various integration tasks from our trunk to various branches or vice versa. (I am not the buildmaster, but hey, I want to know what he knows).
Why do I need to explicitly enable
"Enable baseless merges" all the time?
I am integrating from my branch to the
trunk.
Can't help you here. Something is not right.
What does "Enable integrate over
deleted targets" mean?
If the target file has been deleted and the source file has changed, will re-branch the source file on top of the target file. Without this option, a file on the branch, that has been changed on the branch and deleted on the trunk, would not be allowed to be integrated back into the trunk.
Shouldn't it do this by default?
Not if you are integrating a file back into the trunk, which you branched from the trunk, then deleted on the trunk. Normally 'p4 integrate' avoids mixing outstanding edits with a deleted file. You have to use the advanced options to tell it how to deal with a deleted file.
If the file doesn't exist, and you
integrate to that branch with the
file, it should create the file,
right?
When integrating a file, that previously never existed (i.e., it was added to the branch), from one location to another, yes, Perforce will simply create it in the location into which you are integrating. However, if the file originally came from the trunk, was deleted on the trunk, and now you're trying to integrate it back into the trunk from the branch, you have to tell it what to do via these integration options. Here's the command line switches to which these options correspond:
Enable integrations around deleted revisions = -d
Integrate over deleted targets = -Dt
Delete target file when source is deleted = -Ds
Try to integrate changes when source is deleted and re-added = -Di
You can learn more about them in the integrate command help (type "p4 help integrate" at the command line).
What does "Do not get latest revision
of selected files" have to do with
integrating?
This tells Perforce to use the workspace revision of the target file. By default, the head revision of the target file is automatically retrieved into the workspace before integrating. Say you have made one revision to a branch file and integrated it back into the trunk. The trunk and branch now have two revisions of this file. You submit a change to the branch file so it now has 3 revisions. You sync the branch file back to revision 2. If you were to do a normal integration right now, Perforce would assume you want to integrate everything up to the head revision and would integrate revision 3 of the branch file into the trunk. If you were to select this option, it would say, "all revision(s) already integrated" because you have revision 2 in your workspace. It would be the same as attempting to integrate with the "Limit the range of the integration:" option set to "Integrate all revisions up to:" Revision 2.
What does "Disregard indirect
integration history" mean? I've never
used it, since it sounds scary.
I can't figure out, nor find any info about, what this does.
In general, to merge two files, perforce looks for a "base", the closest revision to the two files, and uses that to provide a much better diff than just directly running a diffing the two files. See Knowledge Base Article. Without knowing your perforce setup, I couldn't say what was going wrong, however, p4win has some nice graphical tools to visualize branches, you might be able to determine why perforce can't find a base for you. This is also what "Disregard indirect integration history" does: stops it from looking for the base.
For the "don't sync to head": when integrating, your "target" is the files in your local client, which you aren't specifying a revision for; instead, perforce will either sync your revision head (if you don't use "-h"), or will use the one you currently have. You can't specify an arbitrary revision because your local client only has a particular one.
"Enable integrate over deleted targets" can lead to problems if done blindly. Here's an example: Imagine you refactor your code in your next release branch, and eliminate a source file as a result - the functionality was merged into some other source files. You then fix a bug in that original source file in a maintenance branch for the previous release. If you integrate over delete by default, the dead source file comes back, but it won't be built and the bug wouldn't have been fixed. It'd better to be warned that this occurred so you could manually merge the fix into the other source files.