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
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.
I have a svn branch that I had been working on and decided to start using git-svn to work locally. Now I have two problems. I want to move my work into another svn repository (on the same host) but I'd first like to merge the latest work from trunk. How would I do this with git-svn? Also, how would I continue my work in a separate svn-repo while continually merging work from the original repo? Also, I don't want to checkout the entire history from the original trunk because the project is rather huge. I am new to git and to git-svn, though I've taken a crash course in git branching and I feel confident enough to use advanced commands like rebase and cherry-pick. I mainly need to know how to apply these concepts thru git-svn. Do the svn repos get setup as a git remote somehow? Are there good resources on the net explaining how it works? Any guidance is much appreciated.
Create your Git repo with git svn init -s <url>.
git config --edit, add several svn-remotes for each of your Subversion repos. Later you'll use the -R option to all git-svn commands to select which svn-remote to use.
Tweak svn-remote branch mappings as needed. Keep in mind that the default refs/remotes/* namespace specifies remote branches — not Git remotes. (You'll have just a single git remote named . which I don't recommend pushing/pulling to/from).
You can easily design your remote branches namespace to keep branches from different Subversion repos separated (e.g. refs/remotes/repoA/*, /refs/remotes/repoB/* etc).
git svn fetch. This has options to scan history only partially, e.g. starting from a specific revision. Please read the manpage on instructions how to do this.
You can also ignore specific paths and/or branches here.
Work with Git as usual, trying to keep your commits as linear as possible. Rebase often. Merge commits are fine (git-svn will even set svn:mergeinfo property), but holy cow be careful (and read the manpage for caveats). Understand that Git commits with git-svn-id tags are immutable, and push -f won't save you. For example, it's forbidden to amend or rebase already dcommit'ed changes.
Are there good resources on the net explaining how it works?
By far the best resource is the manpage. The next after it is git-svn source.
I am trying to use bzr for installing OpenERP. The problem is that I have a very slow internet connection.
When I try "sudo bzr branch lp:openobject-addons/7.0 addons" it takes too much time and sometimes the connection is broken. My questions are:
How can I resume the process on connection broken since every time I repeat the command I get an error "folder already exists..."
Is there any way I can restore a local backup of the files and folder structure and then just compare those files/folders with the files on the server and just upgrade the changed files/folders via bzr? This could be a solution for my slow internet connection.
If I sucessfully download all the files from a branch, which command should I use later to verify if there is any change on the files on the server and if so, how can I update this changes?
Thank you very much
Best regards
Paulo
What takes a lot of time and bandwidth is not transferring the OpenERP addons files themselves, but the repository containing the whole versioning history. It has grown quite big over the years, due to the number of commits as well as the daily translation updates exported by Launchpad.
Answering your points one by one:
If you don't actually need the revision history, you can grab a "lightweight checkout" of the addons instead of a full checkout, by using this command:
bzr checkout --lightweight lp:openobject-addons/7.0 addons
It will be much faster but will only get the files, not the history. You'll still be able to use bzr pull to grab the latest changes from upstream. See also the doc about bzr checkout.
Now if you still want a full checkout you can use the trick of grabbing only a few hundred revisions at a time (there are about 9000 in addons 7.0 right now), so you can resume at any time even after a timeout:
$ bzr branch lp:openobject-addons/7.0 addons -r 100 # grab first 100 revs
$ cd addons
$ bzr pull -r 1000
$ bzr pull -r 2000
$ bzr pull -r 3000
$ ...
There's no easy way to completely bootstrap a full addons checkout unless you manage to perform a full checkout on another machine or internet connection, in which case you should be able to simply transfer the directory (most importantly the .bzr it contains) on any other machine.
In order to see the difference between a local branch/checkout and another repository you can use bzr missing, for example bzr missing lp:openobject-addons/7.0. You can then grab the latest changes from that repository (provided it is compatible with yours) using bzr pull.
Now you should really have a look at the bzr documentation in order to get more information about the typical use cases. The documentation also contains a "bzr cheat sheet" that may help you.
Unfortunately I don't think you could resume a bzr branching.
OpenERP's official website does provide source code nightly builds,
but they use a different structure. I'd recommend you ask a friend
who has a faster Internet connection to bzr branch the source code
repositories and transfer them to you.
You could do bzr pull to get the latest changes and merge them
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.
I have a Bazaar repository on Host A with multiple branches. This is my main repository.
Until now, I have been doing checkouts on my other machines and committing directly to the main repository. However, now I am consolidating all my work to my laptop and multiple VMs. I need to be working offline regularly. In particular, I need to create/delete/merge branches all while offline.
I was thinking of continuing to have the master on Host A with a clone of the repository on the laptop with each vms doing checkouts of the clone.
Then, when I go offline, I could do bzr unbind on the clone and bzr bind when I am back online.
This failed as soon as I tried to bzr clone since bzr clone only clones a branch(!!!!)
I need some serious help. If Hg would handle this better please let me know (I need Windows support.) However, at this moment I cannot switch from Bazaar as it is too close to some important deadlines.
Thanks in advance!
bzr fundamentally works with one branch / directory (the branch are visible at the file system level), so if you need to clone each branch from your repository (not unlike svn, in a way). Hg, at basic level, works this way too (although you can put several branches in one repository using say named branches).
For DVCS, it is important to distinguish between the following:
Working tree: a versioned set of files (at a given revision)
Branch: a linear set of revisions
Repository: a set of revisions
When you clone locally a directory versioned by bzr, you are copying the repository subset which contains all the revisions in the branch you are cloning, and get the working tree. This assumes you are not asking for a branch wo a working tree nor using a shared repository.
What you want, IIUC, is to clone the full repository with all the branches. There is no 'native' way to do so in bzr I believe, but plugins to help you toward this, like multi-pull and push-repo, to sync multiple branches in one shot.
But I don't understand why that's such a big problem, or the link with working offline: you just clone the branches you want to work on your laptop.