I know how to use Mercurial to rename a file. And I understand that the hg log command does not display file history prior to renaming the file unless you use the -f option, and also that you can force the file history to be displayed as described in the accepted answer here Why 'hg mv' (mercurial) doesn't move a file's history by default?
However, when I rename a file, and then check the File History using TortoiseHg, I am unable to view the full history of the file including any changes prior to renaming the file, even though I updated my ~/.hgrc file to include those changes as explanined in the aforementioned link. How can I do that? How can I force File History to include changes that happened to the file prior to renaming the file, and display that history list on TortoisHg?
UPDATE
TertoiseHg version 3.1 shows the full history. I had version 2.8 that did now show the history.
Thanks to Lazy Badger for his answer.
Linked answer is outdated (partially, at least in part of existing section [default] - now it's [alias])
I see full history of renamed file in TortoiseHG without any additional tricks (TortoiseHg version 3.0.2)
Related
When I create a new file in IntelliJ IDEA, it gets automatically ignored by Subversion, no matter what, and it is impossible to commit the file. While in Spring Tool Suite all I need to do is right click and select Team>Add to version control in order to commit that new file. I have try several approaches with no success since many options are disabled.
When I create a new file in IntelliJ IDEA, it gets automatically ignored by Subversion
What do you mean by automatically? There is no any automatic rules - file is either configured as ignored, or not. Make sure there is no svn:ignore property set on the folder (probably not since other tools work).
Also, make sure nothing wrong is added to Settings | Version Control | Ignored Files. The description looks like you have the entire project or sources folder added there as ignored
Finally I found a solution: the problem was that a parent directory was being ignored by SVN, so I searched directory by directory starting with the current directory until I found a parent directory that had a configuration to ignore all directories, for this task I used tortoise, just right click and select TortoiseSVN>Properties look for ignored files and delete the directory you want to synchronize, if no you don´t find the directory look for (*).
I was working on a project in IntelliJ, where I put in some code to delete some files from my project. This accidentally deleted the whole project from the filesystem (Windows 10). The only file left is the .idea directory that probably stores some IntelliJ configuration. The Local History option in IntelliJ has been disabled ever since (which means it wiped the Local History of this project), so there is no way of recovering the project via Local History either.
I used recovery programs like Recuva and EaseUS which for some reason didn't recover the lost files (EaseUS in particular shows files from 2 or 3 days ago instead of today).
I also doubt I can recover these files via Git since Git does not use a single file to store its history.
Any suggestions?
We have the need to remove a file from Accurev existence. We have defuncted the file, but versions of the file can still be viewed which enables a user to re-create the code found in the file.
Is there a way to delete a file from the Accurev database, or at least remove the contents from being visible from all versions of a specific file?
Thanks in advance!
Look at the command 'accurev archive'.
This will remove the data containers which will prevent someone from viewing the file.
I am trying to figure out how to correctly rename files with git while using Xcode.
I made a test project, with a few commits, then renamed a file in Xcode, verified that the git status did say it was being renamed, and then committed outside of Xcode. This was in accordance with this answer to a SO question (Handling file renames in git).
I go back in to Xcode, try to look into the history of that file before the name change (in the version editor assistant window), and I get the error "This file does not exist in the index." While that is true, the file did not exist at that point, its predecessor did. When I go to the terminal, and run git log --follow myFile.m, I do see all commits, even those before the rename. So with that, the history is there, but Xcode doesn't seem to know how to find it.
How can you follow before a rename of a file in git version control when using Xcode?
PS. It does seem that the blame functionality can see before the name change, but the version editor can not.
I had the same error today and as suggested by matt
the best solution is to use an alternate Git GUI.
I finally solved this by installing the great GitX app by rowanj.
Then i saw the uncommitted change and simply commit it.
TY Xcode for being too git-simple and renaming-painful !
I was wondering if I right click on a file in the SVN repo browser, does it get permanently deleted? can it be recovered?
This question/answer from the SVN FAQ might interest you :
How do I completely remove a file from the repository's history?
There are special cases where you
might want to destroy all evidence of
a file or commit. (Perhaps somebody
accidentally committed a confidential
document.) This isn't so easy, because
Subversion is deliberately designed to
never lose information. Revisions are
immutable trees which build upon one
another. Removing a revision from
history would cause a domino effect,
creating chaos in all subsequent
revisions and possibly invalidating
all working copies.
The project has plans, however, to
someday implement an svnadmin obliterate command which would
accomplish the task of permanently
deleting information. (See issue 516.)
In the meantime, your only recourse is
to svnadmin dump your repository, then
pipe the dumpfile through
svndumpfilter (excluding the bad path)
into an svnadmin load command.
If it's that hard, there are little chances it can be done easily from Tortoise SVN...
(And it's not the goal of Source Control...)
You'll find that you can only delete from the Repo Browser when you are viewing the HEAD revision. This is identical to deleting a file from your working copy and then checking in the delete. In both cases, you'll be able to restore from the previous revision.
Deleting a file via the repo-browser context menu basically creates a new global revision where just that file was deleted, so it appears in the log as such - you can always revert to that revision to get the file back, or you can just pull it directly from the repository into your working copy.
No... Deleting a file (even using the repo browser) only affects working copies. It would be a pretty lousy revision control system if you couldn't recover a file from the past. It is actually pretty difficult to modify files in a committed revision, even if you have root access to the server.
Doesn't right-click just bring up some sort of menu? And with SVN is that you can always revert anyways.
I deleted a top level directory from Repo Browser by accident and the only way to get it back was the following:
Export the top level folder from a previous version history
Make a new folder in the repository to replace the one deleted.
Add the exported files back to the new directory (same name as previous)
Update the working copy, it will delete and then re-add the same files.
Its annoying but at least the working and repo will be back in sync. The "Revert Changes from this Revision" didnt work for undoing repo deletes, it only reverts in working directory not the "Undo" the delete to the repository.