I have made all my modifications in my branch and going to another branch(or main). I had given the detailed comments while I checked in my work branch. But with clearcase merge manager, I have to reenter the same comments again which is really tough. Are there some way to use the original comments of the corresponding source version of the element?
The ClearCase Merge Manager, based on cleartool findmerge shouldn't ask you for any comment, and perform all merges automatically (except for the non-trivial ones).
The merge manager wizards should allow you to merge automatically files and directories, and the merge comment should be a default one.
Related
I am new to Perforce and find it really hard to follow its workflow..
I have used Mercurial before (not in any advanced ways), but what I lack most in Perforce is the idea of named branches.
Let me explain what I'd like to do:
I get the latest revisions of all files and want to work on a new feature/story/task..
I create a brach, say "Feature 3021"
I code, save changes in this branch (hg commit)
I can save changes to a central server (hg push)
When I'm done coding, I merge the changes from "Feature 3021" with the main branch (default, master, etc.) - after that the main branch has the code I wrote
I can close the named brach ("Feature 3021") so that further commits are not possible.
I don't need this exact behavior in Perforce, but something analogous. I know that Perforce is centralized, so the commit-push step would be probably one, but this is a minor problem here.
All I care is to be able to save my work in version control at any time, even if it's not 100% ready - perhaps to a different branch. I'd also like other users to be able to be able to get my code (from this different branch), but only if they want this - the default branch should stay unafected as long as I don't merge my changes with it.
Is it possible? I am using Server 2012.2
Can you upgrade to Server 2013.1 or later? There's a great feature there, called Task Streams.
Here's some references:
http://www.perforce.com/blog/130627/task-streams-even-if-you-are-classic-perforce-shop
http://www.perforce.com/blog/130206/task-streams
http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html
The analogous flow in Perforce would be:
Maintain a main-line "branch" at some path, say //depot/default
To create a feature branch, integrate from //depot/default to //depot/feature-3021
Work under //depot/feature-3021 and submit
When you are ready to merge back, integrate //depot/feature-3021 to //depot/default
Regarding closing the branch after its use, there are a couple of options that I can think of. You could either change permissions or simply delete it. The delete could always be recovered.
Also note the paths don't need to be at the same hierarchy. A more reasonable branch strategy might use paths like this.
Main-line: //depot/default
Developer branches: //depot/dev/${user}/${feature}
How to pull changes from one branch to other in MercurialEclipse plugin?
I can't find any info. Also I saw few options: rebase and merge, but I'm afraid to use them, because I work on commercial project.
This is not really a MercurialEclipse question - an answer for plain mercurial would be valid too. The short answer is to use merge. Merge will apply all changes that were made on the other branch to the current branch since the last merge (or since the branch point if there had never been a merge before).
Rebase removes the source changesets so usually isn't appropriate for applying changes from one named branch to another.
A 3rd option is to use transplant. This lets you chose specific changesets to apply onto the current branch.
We are using TFS2010 for source control, the source repository has 3 main branches; MAIN, REL and DEV
Consider this scenario:
Several developers are working in the REL branch (fixing shipping issues). As they work their changes are checked into the REL branch tested and subsiquently merged back into the MAIN branch.
When developers perform their merge (using the source code explorer in VS2010) if they pick the "selected changesets" option the dialog performs some sort of query and presents them with a list of candidate changesets that exist in the source (REL) branch that have not yet been merged into the target (MAIN) branch.
Given that there may be a delay between the DEV commit and the subsiquent merge we are finding people "forgetting" some changesets.
What I would like to do is create a work item query or Excel report that can reproduce the dialogs query results so we can add this to the projects SharePoint portal.
Specifically: given the current user, and a source and target branch name can I use WIQL or a Excel document to retrieve a list of changesets not currently merged into the target branch.
Can anyone tell if this is possible? and better still tell me how to do it!
The question TFS: List changesets that have not been merged asks a similar question but the aswer alludes to a "write your own code" solution, I would like to pull this off with the "out of the bag" tools; Excel or WIQL.
Take a look # this answer
How can I check which branches a TFS 2008 changeset has been merged into?
They outline the tf merge command to list the changesets that need to be merged.
When I had to do something like this I ran a command similar to the one in the answer above and fed it into a text file, with a little bit of tweaking, you could probably turn it into a .csv then open it in excel and filter it by user etc.
To my knowledge, WIQL is all about retrieving exclusively Work Items - so this aspect is a dead end.
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/
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?