In our mercurial project configuration we have 3 branches in a single repository. One is a stable release branch where urgent bug fixes are done, one is a feature branch which contains new feature code and one is a UAT branch where both bug fixes and new features are merged into to provide the most up-to-date code base.
We have merged a whole load of new feature code into the UAT branch without any issues at all. Following that we merged the stable branch with the bug fixes into the UAT branch but this seems to have the effect of removing the new feature code. I have discovered that this problem has been caused by someone merging UAT into stable a while ago (which should have never happened!!). Now when I try to merge the bug fixes into UAT it removes all the new feature code.
Is there a way of removing the effects of the merge from UAT into stable, whilst still retaining the bug fixes that are descendents after this 'bad merge'? I've tried backing out the merge but it seems to have no effect at all. Can I do a strip and re-add the required changesets back in?
Thanks in advance.
I've actually managed to fix this one myself through a bit of trial and error.
First you need to enable the transplant and mqMerge extensions in your mercurial.ini file. Add the lines following lines below the extension header
transplant=
mq=
Clone a your repository to a new location.
In your new repo, remove the bad merge by using the strip command to clear history the effect of the bad merge is removed. (Beware that this will remove all descendent changesets)
Then you need to cherrypick all the required changesets in chronological order from the other repo by using a command similar to below
hg transplant -s "otherRepo" -b "branchName" "changesetHexNumber"
Repeat the transplant command for all the required changesets. Ouila!
NB: If you are using a central repository you will need to strip the offending merge/changset on there too otherwise your local repo will think you have outstanding changesets to pull.
Related
The problem that i am facing is that when i merge my branch with the development branch to update my branch it deletes a big part of my work.
The strange thing is that when i try to solve it with Visual Studio to merge it doesn't not show any merge conflicts.
My branch is fairly up to date but the only diffrence is that the Entity frame work of our database is updated and the Entity frame work of your SQLite database is updated.
The are also placed in seprate projects should that should not effect my work.
The previous merge from dev did have some conflicts but all of them i had solved and my app work fine.
I got my work back with a Restoring a Revision in a New Local Branch but the problem still stay there that i have to merge my branch with dev to test the functions.
I couldn't find any solutions to the problem online.
File structure
Instead of merging dev to your branch, try instead to rebase your branch on top of dev (if you can afford to force push it, meaning if you are not several collaborator working on that same branch)
git checkout myBranch
git rebase dev
The rebase method that VonC suggest did not solve the problem.
But by creating a new branch with information of the older feature branch we could solve the problem by letting some other developer merge the dev branch to the new feature branch.
But i still don't know what the real cause is of the problem.
I have set up an SVN repository that currently has the stable code in trunk and a branch on which new development is happening.
I would like to fix bugs on trunk and have the people working on the branch pick up bug fixes by merging from trunk on a regular basis. My problem is that I can't figure out how to access the trunk version from Eclipse when I need to fix bugs, then access the branch when I do new development.
The only thing I can think of is using the SVN Switch utility to swap between trunk and branch. But, this seems very clunky. I tried switching without committing some changes I made to one of the files, and the file was then in a conflicted state. This doesn't seem like the right way to me.
Any ideas? Thanks in advance for any help.
You have not access trunk-version from Eclipse, because if you want to have sync-merge from trunk to branch you have to have Working Copy of branch, and ^/trunk will be referenced only on merge (which is Eclipse-specific interface)
The normal way to do this is to use switch. Before beginning work you should do switch to make sure you are on the branch where you want the changes to go when you commit. If you have local changes, it is OK, but when you switch it is just like doing an update. You can get conflicts if SVN needs to make updates to the files you have local modification in.
If you do not have any local modifications or unversioned files, then switch will not create conflicts.
My development team recently doubled in size from one (myself) to two. As the sole developer, I was maintaining the trunk as the stable version of our software. I'd make changes in my working copy, test, and only push to trunk once I was sure it was stable.
With the new team member we are trying to come up with the best flow for co-developing the codebase. We have decided that trunk will stay stable; changes are pushed there only after code review and thorough testing. The teammate will create feature branches for features he works on; when he requests a code review, I will do it and then once approved, he will merge the branch into trunk and delete the branch.
We are both using eclipse and the subclipse plugin to manage our working copies.
The problem is that while I can view differences between my working copy and his branch (Team -> Compare To -> Branch), I do not know how to get the code from his branch to merge with my working copy. I want to be able to get his changes without losing any local changes I have made, run his code locally, and have none of this affect trunk. That seems to rule out the option in Eclipse/SVN to switch to another branch/tag/revision, since I need to have his code merged with mine (in order to make sure my working copy's code is consistent with my local database).
We've looked at the SVN Patch feature, instead of using branches perhaps he should send his changes over through a patch which I run?
So the concrete question here is: how do I merge/incorporate changes from a branch with my working copy without touching trunk? I would also be grateful to get suggestions on how we should implement our workflow in a way that takes advantage of the power of svn and eclipse in a way I am missing.
Both of you should have checkouts of trunk and any branches you're both working on. When he is ready to have his branch merged into trunk, you should:
Ensure that his branch builds successfully.
Ensure that your trunk checkout is pristine (no SVN added, modified, deleted, unversioned or ignored files).
Conduct the merge, resolving any conflicts with his help.
Perform a code review, including ensuring that trunk is stable with his changes.
Commit the merge.
Conduct the merge outside of Eclipse, using the SVN command-line. I've seen enough questions here on SO related to Eclipse and Subclipse that tells me the plugin is unreliable.
If it was me managing this workflow, I'd have two checkouts of trunk: one which is meant for merging and is always in a pristine condition, and another in which I can actively develop. That way, I wouldn't need to create a patch of my changes, then merge, then apply the patch.
Hope this helps.
The sad truth is that SVN will probably not be fit for this pattern. Branching creates a lot of pain in Subversion
Check here to get more details.
It was enough for me to update the branch from command line with 'svn up'.
I often see the below errors on doing git pull on totally untouched files which I am NOT working on.
Pull is not possible because you have unmerged files
It is clear the conflicted files have changed in the git repo. But I don't understand why git pull cannot over-write on these untouched files - which I've not touched?
What can I or my team do to avoid getting these errors?
Edited -
Along with the solution I want to understand why the errors are coming.
Just to make clear, the other team members are working on other files (say xyz). And I am working on a separate set of files having no dependency on xyz files. So if I pull the repo changes after a long time with no changes from my side in xyz, why the conflicts in those files?
use git diff to see problem files
look at this git cheat shets for usefull commands
http://www.cheat-sheets.org/saved-copy/git-cheat-sheet.pdf
http://jan-krueger.net/wordpress/wp-content/uploads/2007/09/git-cheat-sheet-v2-back.svg
There are some tips from my own experience. i'm not sure whether they're 100% corerect)
Split work with your team on paralel threads. Try not to work in the same files.
Try to avoid situations when 2 or more persons are adding new files simalteniously. When one added new files others should make pull as soon as possible
the last but not least - make git push very often. this will keep your project git up to date
Since git pull does not pull individual files, it's git merge phase will stop for manual correction of any merge conflicts. git merge and/or git pull (and by nature of the fact that git pull is essentially git fetch followed by git merge) is an all-or-nothing operation - you either successfully merge the changes introduced on both (or all) of the branches you are merging together, or you don't merge any of them. The catch in that is when conflicts arise that must be manually resolved - but in that situation, you are in an in-between state, having neither completed and committed the merge nor rolled it back to your previous state.
The message you are getting implies that you have previously done a git pull or a git merge, which stopped in the middle, requesting that you manually resolve some conflicts, which you have not yet done, but have rather continued on doing other stuff, and are now trying to do another git pull / git merge without ever having completed the first one.
Take a look at git status, and follow the suggested directions for either resolving your in-progress merge issues or resetting back to a not-in-the-middle-of-a-merge state.
Me and my friend are two days into using Git now but we still lack the know-how to use it properly and utilize its full power though it is a tremendous step in the right direction, compared to using Facebook messages to sending and syncing files. We have searched over the net and most of the guides for Egit either assume you work alone or that someone else clones and branches off to their own repo. However we are collaborating on the same project (a 2D RPG) and don't know how to properly use Egit to work together. Some of the problems we face:
1. We had the exact same copy of the project, he changed some of the methods we used, I changed some of the classes and resources we use. He committed and pushed to repo first. Now I cannot push or commit or even pull because of conflicts in the files (repo vs local) which Egit complains must be resolved.
2. How do you properly synchronize code that you are collaborating on? Lets say either one of us is first out to push to repo, what must the other (the puller) do to make sure his own code is not completely overwritten, only accept parts that have changed, parts that we think should be changed.
3. Do we always have to make a (new) local branch, pull to this, see changes, and merge the changes we want with the master/main? How do you properly do this.
Any input is most welcome, we are already much more efficient with our broken knowledge, more will only do good :)
Ok here are my answers:
We had the exact same copy ... because of conflicts in the files (repo vs local) which Egit complains must be resolved.
First you should make sure you use separate branches so that you can always commit.
Then you have to resolve any conflicts when you merge.
How do you properly synchronize code ...
Use separate branches to make sure code is ok before you pull it into master branch.
Do we always have to make a (new) local branch ...
Yes, git is built on the assumption that this is the best way to work. "Everything is local"
This is the way I or we usually use branches:
Main dev branch (Master)
Project branch, used to merge in features added by this project. When all features have been added and seems to work this is pushed/merged into the master branch.
Developer branches, every developer has his/her own branch to develop a specific feature before pushing/merging that into the project branch.
What could sometimes be good to have is also specific release branches. I.e. when a project has merged all added features into the master branch and everything seems ok, a release branch is created for regression testing. This branch will eventually contain the released software when all testing has been done.
The benefit of doing a separate release branch is that the main branch can continue to be developed, but if a fast bugfix has to be done on an earlier release it can be done on that release branch and then later merged into the master branch.
//jk