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.
Related
I'm new to JavaFX 8 and the IntelliJ IDE. I have a JavaFX8 project that works but not as I would like. I'd like to try another approach but the substantial changes may not work. I don't want to loose code I have working.
To save code I have working, I've been creating a new project and then locally copying all the folders(.idea, out, src) and files except .iml, of the working project into the appropriate folders in the new project with the newly generated .iml.
This always seems to work but is it proper procedure?
I'm not on a team of developers and have yet to learn Git/GitHub.
Please advise. Thanks.
Maybe you should learn how to use a Version Control System like Git, then you can create a project repository and have different branches for things you want to try out. Keeping the working code in your master branch will prevent you loosing your working code. Also, when using a vcs you can always revert to versions of your code that have been working. The IntelliJ Idea IDE has perfect support for working with all different types of version control systems. If you don't want to learn any forms of vcs then there is no other way to "backup" your working code.
Is it proper procedure? It's probably not how most people would go about achieving what you want to achieve but it's certainly workable. If you wanted to stick with that for simplicity now, I'd copy the whole directory structure, delete the .idea and .iml files, and then create a new project in IntelliJ on that clean copy: IntelliJ will automatically set up folder structure based on the existing source without you having to go through any additional manual setup.
If you're willing to experiment with the git route, to achieve the basics of what you want to achieve is not very complicated and I've written a small quick-start below. IntelliJ offers very good support for Git, and once your repository is created you can do everything you need from the IDE. I'm going to assume you're working on Windows, although the steps shouldn't be too far removed on other platforms.
Install Git
You can download and install Git from https://git-scm.com/download/win, which will install a command shell called Git Bash.
One-off setup for your project
Open up git bash and go into the directory containing your source. Rather than seeing separate drives as Windows does, Git Bash assumes there is a logical 'root' directory under which all your files are accessible. Your C: drive will be /c. To move around you can use cd to change directory (using / instead of ) and ls to list files instead of using dir.
Assuming your source code is in C:\projects\myproject:
cd /c/projects/myproject
git init
The second line above creates a git repository in that directory. This doesn't affect your code, it just creates a folder called .git that contains all of the book-keeping information.
You don't want to have every file under version control - in particular you don't want your build outputs. You need to set up a file in your project directory called .gitignore which tells git which files and directories should be ignored. As a starting point you can copy https://github.com/github/gitignore/blob/master/Java.gitignore and rename the file to .gitignore
Basic Commands and committing your initial version
There are a small number of basic commands:
git status
Running git status will tell you which files have been modified, which are not under version control, and which files have been added to the staging area to be committed next time.
git add path/to/file
This adds a file to the staging area waiting to be committed. You can add multiple files to the staging area before committing them in one go.
git commit -m "description of your change"
This commits all of the staged files as a new version, which the specified commit message.
If you go into your project directory, do a git status and check through the list to make sure there's nothing you don't want to have under version control, then you can do git add . to add everything to the staging area and git commit -m "Check in initial version of the source code" to commit it to the repository.
After you've committed, you can run
git log
To see a history of all of the changes. IntelliJ has a view that will show you the same thing.
Creating an experimental branch
This is where git shines; if you want to try something experimental you can create a branch of your project while allowing git to preserve the original version.
git checkout -b experiment1
Will create and switch to a branch called experiment1. You can delete, rename, move, rewrite and develop whatever you like on this branch. The changes you commit will be independent of your original working version.
You can switch back to your original version (preserving all of the changes you've committed on that branch) using:
git checkout master
Where master is just the name of the default branch created when you ran git init. The experimental version will still be there and can be switched to again using git checkout experiment1 or from IntelliJ using the branch selection in the bottom right corner of the status bar.
If you decide that the changes you've made in experiment1 are to become your new "good" version, you can merge them back into the master branch and repeat the cycle from there.
My SVN repository contains several folders for different projects. 'Desktop program', 'iOS app', 'Web app' etc. All revision entries are shared between these (as it's under one repository. Revision #100 might be on the 'iOS app' folder, revision #101 on the 'Web app' folder etc).
What I want is to roll back to an earlier version on just one of these folders. Usually this is done with a 'reverse' SVN Merge as it's SVNs job to keep track of all history, even the bad times. I don't want that however. Lets say I have twenty commits on 'iOS app' since revision #5. I want to rid these from history and I want that specific folder to return to revision #5. No one should ever again be able to check those twenty commits as they 'never happened'. Is this even possible?
I have two different machines I am interacting to SVN with. A Windows PC with VisualSVN and a Mac with Subversion on Terminal level. I would be thankful for a solution on either.
From client side, there is simply no way to do this. No matter if commandline, Tortoise, or any other client.
If you have access to the server account that owns the repository, then there is some chance - but it is quite complicated and may involve a nontrivial manual work.
Roughly, these are the steps:
get the repository UUID - svn info http://svnserver/svn/repo - see the UUID line
dump the svn repository: svnadmin dump /path/to/repo > repo.dump
edit the dumpfile to exclude the commits
a) either open it in vi and delete your undesired commits
b) or use svndumpfilter command to filter them by path
create new repository and import your modified repository into it:
svnadmin create /path/to/repo2
svnadmin load < repo.dump
svnadmin setuuid /path/to/repo2 THE_ORIGINAL_UUID
Now, check that repo2 is working fine and has the content that you expect. If so, you can remove repo and rename repo2 -> repo.
Keep in mind that manual changes to the dumpfile are extremely prone to errors, and often these errors can be quite difficult to discover. It is usually bad idea to do things like this.
What I want is to roll back to an earlier version on just one of these folders. Usually this is done with a 'reverse' SVN Merge
Terrible... In order to return back part of WC-tree into some previous revision you have to cd SUBTREE-ROOT & svn up -r REVNO (commit from WC-root for this modified WC will create new revision in repo with partially rollbacked tree)
No one should ever again be able to check those twenty commits as they 'never happened'
Cheated and rewritten history in SCM is BAD IDEA. And Subversion history is immutable, you have to change history using svnadmin tools and access-level, as #petr-kozelka wrote
In Xcode we pulled someone else's push and merged with local copy. However now the pulled copy has corrupted storyboard. The worst thing is we accidentally pushed those corrupted file to remote repo. Now is there any way I can solve this issue?
we are using SourceTree as our interface to Git.
One of our member has the last working copy as we haven't pulled any corrupted data from server to his copy.
Any potential solution for this situation? Thanks
Sorry but I'm not enough of a Git expert be be able to give you the exact commands, but there are git commands you can enter to revert a file to a specific revision/commit. If you hunt around the web you should be able to find them and revert the file.
You may have to use command line Git.
This may help Reset or revert a specific file to a specific revision using Git?
and this Rollback file to much earlier version using Git
A pull and merge is commited to the history like any other change so you just need to undo that commit. The git command to delete the last commit and restore your working tree to the previous commit is:
git reset --hard HEAD~1
(from Delete commits from a branch in Git)
This change could then be pushed back up to your server.
I've started using git-svn for an SVN-based project, so that I can make local commits.
However, the SVN repository contains a lot of directories that I don't need to work with. When I solely used SVN, I was able to partly check-out stuff with:
svn co <repos-url> --depth empty
and then update the needed directories:
svn up <repos-dir>/<subdir>
As far as I've understood, partly checking out a project isn't an option with Git, so I'm looking for alternative way of saving some space. Any suggestions?
Edit: what I am thinking myself is something in the lines of creating a branch thatonly contains the files I need. I'd then want to be able to push the changes to these files without pushing any removal of the files I don't need. But I am not too deply into the way Git works to figure out if this is possible?
Are the extra directories really that big? One advantage of Git is that you do most of your work from your local harddrive (you commit to your own branch, not to the server) so it's fast even when there are many files.
Is there a way that I can review the changes made to a file?
Basically, someone has logged onto my server and made unauthorized changes to a file, this has taken down a whole site. I want to see what the file read before the changes were made. The server is a standard install of centos and apache.
Unfortunately, this file lives outside of the svn (it's a config file).
If the person used copy and cut in vim, and didn‘t clean the registers afterwards, you might find remnants of the changes with :reg in vim.
Which might at least make it easier to identify some parts of the file that were changed.
In vim7.3 there is a setting that allows you to undo changes between sessions. You have to have in your .vimrc the following
set undofile
if you vim did not have this setting there is no hope to recover what the original state of the file before editing it with vim.
If it was set then you can just type u in vim to undo the changes there were made.
The is a vim plugin, gundo, that allows you to have a nice visualization
of the past state of the file (again, you would have to have the option set, and the file were the changes are kept would have to exist).