A colleague of mine was working on a VS project this morning, which he claims was in a folder clone of our central repository. He built a release version of the application which is still there with the correct date/time stamp on it.
He then said he committed several times during this time, but at some point, he tried pulling down changes from the central repository and merge them in with his changes. He can't really remember what steps he took, but the end result is that all the changes he did to the source were lost. now, i'm trying to help him to see if we can recover any of those changes.
He told me after he committed his changes (several commits), He went into the tortoisehg workbench, pulled, and saw that there were many changes in the central repository. He decided to either "Merge with local" or "Update" to the tip pulled down - he can't remember which. I showed him the two dialogs, and asked him if he discarded changes, shelved or anything else. He couldn't remember, really, but he did remember he had to back out because tortoisehg didn't like what he was doing. Eventually, he did seem to be able to update to the repository tip.
I'm thinking that unless he physically deleted the folder in which he was working, and then got the latest, those commits he claimed to have done would have been recorded somewhere? What are common errors people do when pulling the remote repo? Are there any log files or history i can check to see if i can salvage or at least tell where he was working on this stuff?
any hints to troubleshoot this would be greatly appreciated.
First of all backup the tree somewhere including .hg and everything under it. Then...
hg heads
...to see if he's just lost track of his commits. If it's there, it's just a case of updating back to it and doing a proper merge.
hg log -u 'His Username'
...to see if the commits are anywhere in the repo. If they're are there you can then work forward from them.
hg shelve --list
...to see if he's managed to shelve things somewhere
Take a look in .hg/strip-backups, to see if he's managed to strip his changes somehow. Anything else destructive should have left backups in .hg too.
That should be a good start. If none of those give any clues then others may be able to suggest some things.
I don’t know about TortoiseHG, but usually the first thing would be to check hg out.
Related
I admit that I have very little experience with source control and git, however, in my past projects it has been useful to make commitments as backups. During this project, I decided to test out making a new branch. After working in it I decided to click 'checkout' master not knowing what it really did, now all my commits 2 weeks prior have been deleted, it's like I traveled back in time and all those commits I made never existed. All the files I had been working on are now gone and nowhere to be seen. I searched trash, I searched the project folder. They vanished. Did I screw up? Is there any way to recover this files? I searched all the branches without any luck. Thanks.
I don't know how Xcode's UI spells it, but the git command is git checkout #{1}. Look up reflogs and revisions, #{1} is how git spells "what I had checked out just before I did whatever just changed it".
Did I screw up?
Not necessarily! If you made commits on the new branch, everything is still there, on the new branch you created and worked on. So just checkout that branch again, and it will return!
now all my commits 2 weeks prior have been deleted
Ah, so you did make commits. In that case, be assured, nothing is lost.
But if you did not commit on the new branch — if you checked out master without committing your work from the new branch you were working on — then yes, you screwed up and it is all gone. The substance of git is commits, and whatever is not committed is not in the purview of git and is subject to unexpected loss. Loss due to checkout is a classic git trap; you would think it would warn you of the danger, but it doesn’t always do that.
I am working with the GitHub GUI on Windows.
I did some work on my project which was successfully committed about a month ago going forward. Unfortunately other person who also works on this project recently committed the files I changed without realizing that he removed a huge portion of my work.
Now my question would be: is there an easy way of restoring my commits. This is not one commit. For the past month I made several very important commits to the project which got killed by the other party error.
I really don't want to go thru each file individually and re-aaply the changes manually, especially since I already got paid for that work.
How can I get my commits back?
IF you don't see your commit anymore in the history of the repo, that would mean the other developer has done a forced push (git push --force).
In that case, use git reflog (as in this answer) to find your commits back.
If yo do see your commits, then you could revert (git revert) the commits introduced by the other developers in order to cancel them, which should leave your branch in a state reflecting your work.
In both cases, this is a communication issue: you need to coordinate with the other developer in order for both of you to agree on a state from which to move forward.
I have a few CVS WCs and, today, I took a look at one to make sure such-and-such code was present, but before I tell my colleague that it's okay, I need to make sure I'm looking at the right branch.
Somewhere I read that cvs log is the right way to go, so I cvs log [filename] and it listed all the branches in the project, but I wasn't sure how to see which branch I was using at the moment.
You want to do a cvs status and look at the Sticky Tag: line. there should be a branch listed in parentheses.
Sorry, I can't capture the output for you, thankfully it's been almost a decade since I touched CVS.
A developer in my team has been using a branch bound to the server (IE, only using checkout, update, and commit), but also often uses the --local flag on commit and then commits to the server in a batch. She recently experienced a situation where she is missing some local commits, and can't find them in the repo OR her local code. She suspects that this is because she did a pull at some point in bettween local commits and server commits.
Neither of us are particularly experience with Bazaar -- What may have happened, and where can we look for this missing code? She is fairly certain that she never did anything destructive, and I am fairly certain that Bazaar would have asked her if it was going to do that. I vaguely remember that Bazaar has some notion of "hidden" repos/trees/whatever where it puts things before changing a bunch of code, from which someone might recover lost code, but I can't manage to google for what that is.
I figured out that the "'hidden' repos/trees/whatever" that I was referring to are "dead heads", viewed with bzr heads.
We found our dead head and merged it back in -- code saved!
$ bzr heads
$ # output shows various heads, with names like: revision-id: john#mycomputer-20100630175358-39qro1z5qdq2o9ay(dead)
$ bzr merge john#mycomputer-20100630175358-39qro1z5qdq2o9ay
If all else fails, you can try asking in the bazaar IRC channel.
Go there now* and wander into the #bzr channel. There are usually people there and they are usually helpful.
**That's freenode's web interface. If you haven't used IRC before, you make up your own nickname, choose the #bzr channel, and no need to auth (as long as your nickname is unique).*
At any time you can do a
bzr status
and this will should you if there are any uncommitted changes, including merges that have not been committed. This may help in determining where everything is at. If you do a merge and you haven't followed it up with a commit (whether or not there were conflicts) then the result of the merge will remain uncommitted.
Doing a bzr pull shouldn't have wiped out any work - as I understand it, it should just fail if the local branch has uncommitted changes.
What is the concept of each?
When is it ok to shelve your changes instead of checking in?
Shelved means the changes are set aside for you to work on later.
Checked in means that the changes are made available to the rest of the team, will be in the build and will eventually ship.
Very different. Think of shelving as a tool for context switching when you're not done with a task. Checking in means you're done (at least a part of it).
Shelve your changes when you want to save the changes that you have made, but need to go back to the previous version to make other changes (perhaps, bug fixes) that you want to deploy without the updates you are currently working on. Since you're usually checking in pretty regularly, I find this to be a rare occurence -- like I just deployed to the QA box and an error was immediately found. I'll shelve that day's changes bringing me back to the QA deployed version, make the update, then unshelve my changes -- merging the two as necessary. Any longer than that and you'll probably be looking to check out a previous version and branch instead. I'd be happy to hear of other experiences where shelving has proved more useful, though.
Other users can download your shelvesets by searching for them, so it is a good way to pass code around for reviews. however you will get an error if you try to unshelve code files that you already have checked out, so you need a clean environment ready.
I often shelve my changes at the end of the day if I'm working on something big that I can't check in. That way, if my PC dies overnight, I've got a backup on the server.
Darcy gets it spot on. You can also think of shelving as a private branch that is not publicly visible for the most part. Shelvesets can also be deleted completely, not like deleting checked in code. If you delete a shelfset it is gone forever.
Everyone above has said so much true and I learned allot from it.
Just to add my experience, correct me if I am wrong. In a project, we have a configuration file mypc.json specific to each PC of the developer. We usually override it when running server locally. Other team members have the same file name with different configurations in it. No one wants their file to be pushed with the same name to the development branch. So I use shelve to save these type of changes. Whenever I need these configurations I can easily apply changes from shelve and my environment configurations are back in my project.