I am having a major issue with clearcase merge:
I have a list of files taken from clearcase long time back and updated outside clearcase. In between, the same files have changed in clearcase as well. Now, I created a new branch and checked in the updated code from outside in the new branch.
But when I want to merge from new branch to integration branch, it automatically merges and overwrites the changes in integration branch with the changes from new branch. What I would have expected it to atleast raise a conflict and not wipe out the changes made in clearcase integration branch.
can anyone help here please?
You need to be careful from which version you are starting your new branch.
If you are starting a new branch from the LATESt version of the current branch, in order to:
clearfsimport your code modified outside of ClearCase
merge said new branch to your current branch
Then, yes, all changes will overwrite the current versions.
But if you make your branch from an older version (a previous label or UCM baseline), import your code there and merge, then the merge will work or generate conflict if appropriate.
In other words, you need to start your branch from what you estimate is a common ancestor for your merge to work.
See "Rebasing and merging in ClearCase":
.
Related
I created a new branch from trunk( intended as Version 1.1.5.0) and incorrectly named/pointed the branch to an existing branch ( Version 1.1.0.5) in my SVN repository. Can I undo this? I correctly created a new branch from trunk as intended afterwards but now branch 1.1.5.0 and 1.1.0.5 are identical. Would it better to create a new project in eclipse and grab a copy of the production files (which is at Version 1.1.0.5) and commit it to the correct branch? Branch Heirarchy
Trying to merge branch back into the trunk but every time I do it doesn't seem to detect any changes. Please help
When you want to merge, you must have checked out the destination in your local workspace. The concept is, you merge from another branch (source) into the current one (destination). So in your situation, make sure you have committed all your changes to the branch, then switch to trunk, then do the merge from branch.
My current employer uses clearcase (I believe Base-CC) for version control. Our project has a branch, and each user has his own branch on top of it. The configspec of the users shows elements from the user branch, then from the project branch, and then from the company-wide branch.
The current modus-operandi, is that the users merge in their changes back to the project branch, and keep working on their own branch.
The problem is, that after the user merges his changes, he still has a branch for this element. Then, when the someone else modifies the project, he still sees his outdated version.
I want the following:
if a user has a checkedout file, display it.
if a user has unmerged worked, display it.
if a user has merged work, show the lastest version from the project
I thought of marking the element branch as obsolete after each merge, but the users still sees it, and not the latest from the project.
Then I thought of changing the config spec, to somehow ignore merged-in branches, but I do not know how to do that.
Any ideas?
You can reuse your personal dev branch, but the correct workflow, when a dev merges his/her branch to the upstream branch (here the project one) is:
first merge the project branch to the personal dev branch
resolve any conflict locally
then merge personal dev to project.
That way:
you don't have to modify the config spec after each merge,
you make sure the merge will be a trivial one,
and the personal dev branch can represent easily the LATEST from the upstream branch after merging (again) the project branch to the personal dev branch: the delta will be minimal.
Our dev team works inside existing projects, and deploys on completely separate environments. The work we do is not never expected to be merged back into theirs, but we are required to stay in line with them. They use the traditional trunk-branch (but not really tags) setup. A branch is created for a production release, and then development continues on it as they release.
The way our team does it, we copy their release branches to our own trunk (initially), which itself contains trunk/branches/tags. During development we are on trunk, and tagging for production releases. When we update from their latest release, its often impossible to do a straight merge from that branch to our trunk. It seems much cleaner and trouble-free to start with their branch, merge in our work, and eventually rename it to trunk.
All of a sudden I feel like a subversion dummy text generator...
Given the constraint that we can't change the other team's workflow, is there a better flow for us? Let me know if I'm missing something in the explanation too.
thanks.
Two main principles:
Vendor branches
Merge often
Due to ignorance of rule 2 you get "Merge hell" as expected
For more reasonable workflow (read about Vendor branches in Net, it has a lot of information) you can
Not just copy upstream branch to your trunk, but create vendor-branch (branch) in your repo, link it with svn:externals to source branch (without fixing source-revision in URL, link to moveable HEAD)
Copy branch to (empty) trunk
Monitor commits into upstream repo (SVNMonitor, CommitMonitor) and on every commit to upstream branch merge your vendor-branch with your trunk (svn 1.6-1.7 will be better than older versions)
After finishing upstream brach and starting new you can or edit externals definition in old branch (for next branch URL) or delete branch completely and start new (deleting all from your trunk not needed, only merge from new branch content)
I have an SVN branch and a trunk. The trunk changes regularly and the branch doesn't.
Every now and then (let's say once per week) I want to update the local working copy of the branch with the latest changes of the trunk.
Ideally I would want to do this the same way as I do it with the latest version of the branch: with Eclipse : Team->Synchronize, so I can review all changes before updating.
Is this also possible with a different repository (for example : trunk) ?
If not, how do people review the changes before updating then??
I looked at Team->Merge, but this seems to update the changes directly to my working copy, without the possibility to review the changes first (the Preview-function is confusing, I think, and doesn't provide the nice side-by-side view of changes/conflicts that Synchronize has).
The right way to do this is with Merge. Subclipse includes a merge client that makes this easy to do. You are right that it does not give you a true preview, but the way it works is better from a Subversion perspective. The Merge Results view UI is basically the same as the Synchronize view. It lets you easily examine every change that the merge made in your working copy and the Eclipse compare editor that it opens makes it very easy to take out any parts of the change that you do not want in your code before you commit.
The problem with trying to do this from the Synchronize view is that you are then doing the merge yourself using code editors and Subversion has no awareness of what is merged. If you let Subversion first do the merge, then it can update all of its metadata properly and it is perfectly fine for you to then fixup the code to be the way you want it before you commit the results of the merge.
I'd checkout both branch and trunk as a separate eclipse projects into workspace. Then use some merging tool, for example meld to merge changes between them. After merge you can refresh branch in Eclipse and synchronize it with svn repository - now you can review all changes. (it's how I do it, since I do not believe svn eclipse plugin ;))
I agree that it is not really intuitive by design, but Mark is right, you "synchronize" your changes when committing them back to the trunk:
first make sure your local branch is completely synchronized with your repository branch (no changes)
Team -> Merge... your local copy of the branch with the repository trunk
you now have a local version of that merge
you can locally edit this version, make sure tests are working and there are no compiler errors
finally you synchronize your local merged branch version with the repository branch and commit all changes that have been made
besides, the same way you'll merge your branch back into the repository trunk
make sure all changes of your branch are committed to the repository branch
switch to the trunk Team -> Switch...
merge your trunk with your branch Team -> Merge... (Tab 'Reintegrate')
you now have a local version of the merge, you may edit the changes and review them, make sure that you have a working version now
synchronize your local trunk (merged version) with the repository trunk
commit all changes that you want to appear in the trunk
i recommend to commit all changes that you've made locally to your merge, since you've tested them locally. if you commit just a few changes, make sure the repository version is still working then with missing changes