In my repository I needed to revert to an older revision. I did reverting and made the changes I needed to. How do I push the new revision upstream?
I was on rev 17 when I needed to revert back to rev 13. Now that I've made my changes, I'm on rev 18. Thing is, when I go to push these changes up (I'm using TortoiseHG), I get an error "abort:push create new remote head.
I don't want to do a merge. Do I want to do a force with the --force command or do I need to delete rev 14-17. If I need to delete, how do I delete 14-17.?
Proper solution is to actually merge with option Discard all changes from merge target (other) revision. But sometimes life is harder on us and we really need to drop some changes (eg. we committed nuclear launch codes or some other security sensitive data). Is that your case? If yes then follow.
Assuming that original changes were not published you could:
enable mq extension
r-click on offending changes and execute Modify history->Strip.
This will permanently remove changes from your local history.
You don't want to delete revisions and therefore destroy history. That goes against the reason version control exists.
You can do a merge and discard.
You can also do this in tortoiseHG.
Related
I just accidentally merged to a branch that I had 40+ local changes on - so now my changes and the merge are together, which I definitely do not want, with a lot of the files having edit & merge changes. I want to completely revert out the merge, is there a way to do this? If not, I'm in trouble.
I haven't checked anything in, I just only want to keep my local changes that I made.
If you merge to a branch via pull request in Azure Devops, then you can revert the completed pull request directly.
In Target branch, select the branch where you want to undo the pull request changes.
In Topic branch name, select a new branch where the reverted changes are created, then select Revert.
Select Create pull request to merge the newly created branch in a second pull request to complete the revert. For details ,please refer to this document.
If I ignore something, you could attach detailed steps or flow for this issue , this would be much easier for me to understand and reply.
I agree with Leo BL. You can try to copy your current project folder into temporary folder. Then checkout the merge source branch and compare it with temporary folder by some diff/merge tool. However, that maybe difficult to cut your changes if they were in the same files with the merge operation.
Just a quick hint: Basically, this is a git question. So maybe you should consider giving it the git tag aswell, so you can reach a greater audience.
Regarding your question: What means local change? Is the stuff not committed at all? What does git status show?
Assuming the changes are not committed, you could use git stash. I recommend this SO question:
Cancel git merge but keep local changes
I would try it this way:
1. Backup the directory (so you have a backup if something goes wrong)
2. Stash your changes
3. Revert the merge
4. Load the stashed changes
—> You should be fine
sorry but you are in trouble. After the merge the files are replaced
Basically what has happened is this:
I moved a bunch of files from one directory to another directory.
I then committed my change and pushed it.
Then I notice that my "move" actually wasn't a move but Mercurial, I guess, actually copied the files I wanted to move and pasted them in the new directory and then deleted the original files.
The unintended result of this is that all the history is lost since it is no longer the old files but new ones.
So what I would like to know is how do I revert/rollback/backout this change?
I have read about all three ways but I'm still not sure which is the best way to approach this. I just want to backout my push so that I can move the files correctly without losing all the history.
You can't directly "undo" a push but there are ways to essentially negate its effects.
Option 1: The most straightforward option is if you have full control over all clones which have received the pushed commit which was in error. If so, use hg strip on all of them to remove the bad commit(s).
Option 2: If you cannot do that, you could delete the incorrectly added files and revert the deletion of the original files (example), and then just redo the operation as you originally intended.
Option 3: Update back to the commit prior to the bad one. Then use hg move to correctly relocate the files, and commit that which will create a new head (since you were working off a revision older than the current tip). Then merge this new head with the tip. That should cause the history to be retained.
I am new to SVN , we are using SVN version controller in eclipse (Lunar), We have a module,that module code's may go to Release or may not go to release depends on the business approval, is there any way in SVN to commit/rollback set of changes(different File changes) on single action ?
Thanks & Regards
S.Sathiya
To roll back changes in Subversion while maintaining the history of all events, you need to perform what's known as a reverse merge. You're essentially applying a patch which reverses the changes that were done between "now" and the state you want to roll back to.
You can apply a reverse merge to a whole tree/subtree, or individual elements (files/directories). To make things easy, work in the largest chunks you can manage.
Simply check out the version of the file you would like to have and commit it to the repo. Reverting is a feature to undo accidental whole commits (so it would have an effect on other files too, which is probably undesired). If the whole thing you want to undo is a complete commit, then yes, reverting under the Team context menu or in the history is what you are searching for.
I have heard this several times, that one should always update before committing to a version control system. Why is that ?
If you don't update you risk facing a conflict if someone else has edited any of the files you want to commit while you were editing them.
In source control systems like Subversion you won't be allowed to commit before you update even if changes belong to different lines - you will have to first do an update then possibly resolve conflicts, then you'll be allowed to commit. It works like this: you start committing, the Subversion repo server checks whether any of your changes conflict with recent changes, if any of them does conflict the commit is rejected as a whole.
In older systems (I can't name an example) that perhaps could cause serious problems like overwriting changes or doing an incomplete commit (some files committed, some not).
So that you are in sync with the repo and if any conflict happens it happens in your local checkout files, which you can resolve and then commit.
You need to update so that you can get the latest changes before you check in. If you don't take an update, when you come to check in then the VCS will tell you that you need to update.
you can then effectively know your changes are fully integrated with others before you check in
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?