Clear Case Merging - merge

I have merged the code from project/sub branch to main branch using version tree. I can see the merge arrow drawn from version at source branch to the version at destination branch.
But when I change my config spec to default config spec I can't see the folder on main branch and it still pointing to project branch.
Could you please let us know who to make it visible on main branch?

I can't see the folder on main branch and it still pointing to project branch.
check your config spec (it should include only element * /main/LATEST)
check that, as I explained before, the parent folder of the code that you have merged is also merged (also with a red arrow between project_brnch and main), or you wouldn't be able to see the merged code in /main.

Related

In GitLab, do I need to re-merge a branch because I added a new file to my branch?

I'm trying to make sure all of my code is in the right place and it should all be "merged" with an existing project.
I forked their project and merged when I had two source files, and now I've uploaded a third file to mine.
Do I need to remerge my branch with their project for them to see the new file? If so, how would I do that? (I get an error about there already being a merge request)
Thank you.

Hg Mercurial - Upgrading code not in repository

I have a customized local repository of NopCommerce 3.5. The new version of NopCommerce (3.6) is out and I would like to try to update to it. I downloaded their source code and I would like to somehow replace all the files in my local repository with the new files (outside the repository) and then have mercurial detect the changes and merge them with my changes. Obviously the merge would be manual but I have no problem with that.
In case I am not explaining this properly, let me give you and example:
I have file foo.cs (v3.5) which has custom code in my local repository. I downloaded the new foo.cs (v3.6) which is not in any repository. How can I merge them so that I can keep my changes and the the new changes added by the NopCommerce team?
This is what I have tried so far:
I created a new branch called "Nop3.6" and replaced foo.cs. Then I tried to merge the "Nop3.6" branch with my "default" branch hoping to be able to merge manually and keep both, my custom code and the new changes added in foo.cs (v3.6).
As you might expect this didn't work. my foo.cs file (v3.5) was completely replaced with the new foo.cs and all my changes were lost.
Any help in the right direction would be much appreciated.
Doing the merge vice versa (your changes into v3.6 might work better. Also make sure that you have selected a reasonable merge tool (internal works, but there are possibly more convenient ones out there, I use kdiff3 myself):
I assume you have a repository with v3.5 and on top of that you have one or several changesets which are your own modifications of that source. If you haven't committed your changes as changesets on top of v3.5, then do that now.
Then, in order to get a decent merge with v3.6 do the following:
update to the unmodified v3.5 again. Copy v3.6 over this and commit the complete change as v3.6. You end up with a repository which has two anonymous branches with v3.5 being their common ancestor.
Now you can merge those two branches. As you possibly want to keep your changes on top of v3.6, update to v3.6 and merge your local changes into that branch.

How do I get back my files marked as deleted in the unstaged changes area of Git staging?

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.

TFS - Cannot see Target branch when doing file Merge

We faced an issue with file Merge at TFS2010. Until now, we merged files from one branch to another without problems (right click at file -> Merge -> Choose Target branch and Merge files). Initially, we added new file at Develop branch, after that added same file at Main branch. After some period we had changes in code at Develop branch and when tried to do Merge with Main branch, cannot see Target (Main) branch. I have two questions regarding to this situation:
Is this good way for 'uploading' new files at TFS. Separately add files at both branches or there is some better practice where we could add new file to Develop branch and after that make copy of that file at Main?
What can be reason for 'hiding' Target branch during the Merge operation?
When tried to solve this problem, I found some articles that can be useful to someone else, but didn't solve problem in my case:
TFS not showing Dev branch in target locations for merging
How to merge new files into another branch in TFS?
http://revweblog.wordpress.com/2010/03/31/missing-target-branch-while-trying-to-merge-in-tfs-baseless-merge/
TnX in advance!
Nemanja
I think the case you should look closer is this, it's a case you have already mentioned.
To your first question:
No, your method of committing new files multiple times is not optimum. Adding a new file into source control (any source control) more than once, doesn't make sense.
To your second question:
The reason behind this behavior was best explained by AakashM in the post above: "In TFS the unit of change is the changeset, and it is changesets (not files) that are checked-in and merged. In the version (changeset number) that the target branch is at, this file simply does not exist, so there is nothing to merge to."
The proper way to operate is to add new files in your 'Development' branch and then merge into your 'Main' branch.
This will not be possible if you right-click on the newly added file & choose "Merge.." (no target-branch will be presented). This will be presented if you do this in the folder containing you new file(s).
I had this issue, when for the Main Branch i did not had the latest code. I Took latest code in Main Branch and then tried Merge to development branch and it worked.

Eclipse Merge Branch into Trunk

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