I just reverted some changes in files. These changes were not staged or commited.
Is there anything I can do?
thanks!
There's not much you can do to recover your changes.
If you are using Intelli as your IDE there is a "local history" you can access be right clicking on a file in the project view.
Related
I am using Visual Studio 2012 on my home PC and I have been looking for a way to implement version control locally. I use Team Foundation Server at work, and have never used anything else. I am not trying to connect to my work server, I just want version control for my home projects.
I tried Git Tools for Visual Studio, which works ok - but it doesn't support reverting to a previous commit. Every time I've needed to revert, I've had to go to the Git repository website, download that commit, and replace the files on my machine.
Is there anything out there that supports similar version control to TFS?
Git is a good option because it keeps a complete copy of the repository version history locally-- you never need to push changes to an external server. You can read about setting up a local repository here.
Once you have a repository set up and some changes committed, you can use git reset --hard <commit> to reset to that commit. See documentation here. Note that this will wipe out any pending AND committed changes on top of the referenced commit.
I created folders in TortoiseSVN's repo browser. Then I copied all files in it. Then I wanted to delete all files from previous folders. But I couldn't because those files were already locked by someone else.
I want to completely undo the changes I made today and commit those changes and start working fresh. I tried using update to version but it only updates the working copy and does not commit it because no changes are made.
How can I completely undo changes made in TortoiseSVN and commit latest file
You need to perform a reverse merge of the changes and commit that. Then copy your "latest" version in and commit that.
After I add and commit changes from my VS2008 solution folder, I have noticed that the the exclamation mark on all files and folders changes to a checkmark after the commit is completed to SVN repo, except for the file which is in the same folder as the folder. Even after I hit Refresh or perform SVN update and then Refresh, the exclamation mark stays. Is the problem between the chair and the keyboard or a known SVN issue. Please note that I am using Tortoise SVN 1.6.9 on Windows. Thanks in advance.
Firstly, you should notbe adding *.suo files to source control. It is bad practise, especially if you have multiple users working on the same project or solution. You should add all *.suo files to the SVN ignore list.
That said, the problem you describe is fairly common with Tortoise SVN and SVN in general, in my experience. Sometimes Tortoise SVN / SVN can get a bit confused, the .svn meta-data folders can get out of sync with the server copy, or even corrupted. To solve this problem, your working copy needs to be 'Cleaned up'.
Try the following:
Select the folder of your working copy in Windows Explorer, then
Right Click - Tortoise SVN - Clean Up.
If this doesn't work immediately, try multiple combinations of updating your working copy, then cleaning it, then updating again. This usually fixes the problem.
Read here and here for more.
The problem is also quite often with Windows/Windows Explorer itself. Refreshing of the SVN status icons doesn't always happen immediately. I believe it is a problem/limitation of the combination of Windows Explorer and the Tortoise SVN shell plugin.
Please do this
Directory ->Right Click->Check For Modifications -> On Modifications(select all)->Right click -> "Commit"-> In the bottom pane click "Refresh". Now it should have removed that warning sign.
I had a pending changelist in my workspace.
By mistake I reverted one of the files by reverting to depot. Eclipse wiped off the local history. I am not sure if perforce keeps any history for pending changelists.
Is it possible to recover such file?
The simple answer (to my knowledge) is "no". Perforce doesn't keep a history for (non-submitted) changelists.
Unless you happen to be on an operating system that offers snapshots (or your file-server does), you are out of luck.
Another thing you might try for the future is to get in the habit (e.g., by defining a local alias) of always using 'p4 revert -a'. It would be nice if 'p4 revert -a' had been the default, and you had needed to pass a special flag to indicate that you wanted to revert a file that you had locally changed, but that's not the way it currently is, unfortunately.
I was also facing the same issue. my workspace over written from cvs by mistake and I lost all the changes in some of my local files.I found that in eclipse UI resource history has shown as blank for the files but the history file created by the eclipse still exist in *$eclipse-workspace.metadata.plugins\org.eclipse.core.resources.history* folder. Use any text editor like notepad++ to search for the name of your file in all the folders and you can easily recover the file from there. I just did the same to recover my files.
If Visual studio is the IDE undo under edit menu recovers the files
Drive snapshots are your best bet to prevent this in the future. For my personal non important projects, I use a Git for checkins; but dropbox for easy multi-machine work and snapshotting of non checked in code (even to local repo)
The only solution is having backups/snapshots. If you're in a corporate environment, contact your IT department.
If you are in a unix corporate environment, you might have a ~/.snapshot directory that keeps hourly snapshots of all your files for the last few days.
Had to relocated our SVN repository, I edited the ccNet.config removed our state files and the old build directories. My build will start and pulls down the project for SVN but right after getting my project from SVN the build hangs and the .sln file gets deleted. Any Ideas?
From the question it is not really clear what you mean by build. I understood it is the complete CruiseControl build process [Event -> Checkout/Update -> Compilation -> Tests], not the compilation.
I would check these in order:
Did you relocate the local copies used by CruiseControl.NET?
Check the SVN URL path associated with the working copy, and its revision, did it really update to what you expect?
Check the credentials, do you provide them in the CC config or do you rely on the SVN client credential cache. This might have to be updated.
Activate Debugging in the CCnet config and have a deeper look at the log file.
What sounds strange is why the .sln file would be deleted, was it really in the repository or only created in the past because you opened a project file? A reason could be an uncommitted SVN delete made by mistake. A revert on the local copy can help in this case.
Jdehaan, your answer was very helpful. We had a couple projects on the build server pointed to the old repository that needed to be relocated.