I hope this is OK to ask here instead of superuser since I get very little response there to very specific questions like this.
I have a project that's under mercurial revision control and I'd like to move where it is located on my computer (from ~/workspace to ~/Dropbox/Projects). But if I move the project and then re-import it, it loses the mercurial connection.
I can just commit, push, delete my project, and re-import from hg in the new directory. But there has to be an easier way, no?
I don't know specifically about Mercurial, but with some version control systems, moving a checked out copy of the code is very hard (some VCS keep metadata with absolute paths, etc.). So I would commit and re-fetch, personally.
Also, consider the possibility of losing that uncommitted work during the move...
When you move the project, can you confirm if the .hg subfolder (which holds the repository data) moved as well?
Is the moved repository accessible using a command-line or a different mercurial (say TortoiseHg) client?
In Eclipse, what happens when you do "Team -> Share Project..." again?
Related
Decided to take the jump from CVS to SVN.
I setup a new repository in subclipse for my project. When I go to 'Finish' the setup it wants to do an initial commit and presents me with a flat list of files to select the files for version controlling.
The problem is I have thousands of generated binary files I dont want to commit.
So I click on cancel because it would take me all day to go through and unselect all the unwanted files. Annoyingly when I click on a parent category for the files I want to ignore it is not recursive!
So I click cancel then go to the eclipse directory structure for the project and manually set svn:ignore on all directories I want to ignore. Then I try and do a commit again and all the files are once again presented - ignore seems to have done nothing.
Can anybody point out what I might be doing wrong?
For the first commit, I recommend writing a small script to delete (of course you'll have a backup) all the files that are not meant to be committed.
Afterwards, if you find you accidentally committed a file, you can
svn delete file
Upon the first checkout, copy back (or better yet, regenerate) all the binary files. This will trigger svn to notice that your local repository is out-of-sync with the remote repository.
cd <Root of local repository>
svn status
You will see lots of "to be added" items. Go to the parent directory and add in svn:ignore properties for each of the generated items.
cd build
svn propedit svn:ignore .
which will open an editor (if it doesn't, you need to set the environmental variable SVN_EDITOR to a suitable editor). Then you can add in entries that svn will know are not tracked.
(in the ignore property editor)
target
build
image*
*.o
(and so on)
Save the file, and it will be staged for the next commit. Subsequent runs of svn status will no longer show these files as "needing to be added", but they will show the directory as "needing to be committed (it's a revision on the directory)"
Quick Aside
So I'm not entirely certain exactly which functionality of Subclipse you were using in order to create a repo and share a project to it, I'm assuming you created like a file based repo through the eclipse SVN repo view and tried to share and then commit to it. It looks like your problem got solved but I did want to add an answer on here because I ran across this post looking for the answer to this same problem of handling initial commits even just in general with SVN and wanted to offer help to anyone else looking for the help.
Intro
To start off I would recommend not working through an IDE extension like this just for the initial commit as they can miss a lot of the options for handling opening a repo in SVN. I personally really like the command line form of SVN to work with but TortoiseSVN is a good option for a GUI.
Whether you create a local file-based repo or are connecting to an SVN server and you want better control over your first commit in an previously unversioned project here is what I've found as the best general workflow for doing so.
Create the remote folder to save to.
On command line this will be:
$> svn mkdir your-url-scheme://your-site-address.domain/path/to/repo/example-directory
Or on TortoiseSVN open your repo for browsing, right click, and select "create new folder"
This will give you a location in the SVN repo to checkout from for our next step.
Checkout in to the already started project
Make sure to use the empty, newly created folder in your repo to checkout with. SVN does not actually require a folder being checked out to to be empty, which is an important part of what makes it actually very flexible and able to subsume parts of your directory into it fairly easily if used correctly.
Now you will checkout this empty folder into the root folder of your already started project. This will add your project to the working copy of this folder without any commit being made yet. The command is:
$> svn co your-url-scheme://your-site-address.domain/path/to/repo/example-directory /your/projects/root/
"co" standing for checkout. In Tortoise svn you can right click on or in the empty repo folder and select "checkout..." and then select the project root.
Set ignores and commit
Finally, you can easily set your ignores on certain files before adding any other files to the tree using the command:
$> svn propset svn:ignore file-or-directory-to-ignore
And to add all non-ignored directories and files:
$> svn add * --force
The force is technically unnecessary in this case but ensures full recursion. You can also now do all of this in your file explorer if using TortoiseSVN or you can even use your IDE extensions to do this at this point(make sure to ignore all files you need to before mass-adding files for commit), all that's left is to make sure to commit the newly added files to the repo and you're up and running with source control :)
Added this method here simply because this method allows you to avoid any unnecessary copying of those stinky binaries that no one wants to lug around with them.
My service provider changed URLs on SVN repository. We were unable to reconnect from Eclipse SVN plug-in.
Based on their suggestion, tried Share Project, which allowed us to redirect to new URL, but ended up screwing
up repository files.
Still have intact local copies with SVN state on a client machine.
Is there a way to build a new SVN repository and load in local working copy WITH SCN HISTORY intact.
When we did this with Eclipse plug-in Team prompts, it ending up recreating projects but lost the
original SVN change history, which we would like to preserve.
Thanks
If I understand your question correctly, the short answer is "no".
An SVN checkout does not donwload the complete history to your workstation. It just downloads the current state. When you make changes, it remembers what it downloaded so that it can compare what it downloaded to what you have now. So you could reconstruct "last revision" and "updates since last revision". That's about it.
Eclipse keeps track of edits, but I don't think it's going to remember edits across checkouts, because that's going to look like a new file. It has a finite buffer anyway.
If you were so fortunate that you have a directory where you checked out revision 1, and then you kept that and checked out revision 2 to another directory, etc, you could reconstruct the history. But few people do that because it would normally be pointless because the history is in SVN.
You can't get history from Working Copy, because WC is always only slice of repository
If SP inly changed URL and you can and know how to work with pure CLI SVN and WC as directory in FS - you can
switch or relocate working copy
or
checkout from new URL new project
I am working on an enormous project ("the project") which is open-source, and I am changing the project but don't have a permission to commit. I'm looking for strategies for maintaining my own branch of the project. Some issues I am contemplating:
How to put my own work in a version control system, given that I'm altering the project's source code, adding new files and so on.
How to keep in sync with the project without having to manually merge my own changes over and over again.
I've never been in this situation - I've always maintained my complete project in some version control system. My plan right now is something like that:
Creating a directory tree in my SVN, similar to the one in the project.
Keeping all the changed files (and only them) in my svn.
Every time I decide to sync with the new baseline of the project, I'll do a checkout, merge my svn tree into the new version, test, then commit my changes to my svn and distribute them along with the latest project baseline.
The problems here are ENDLESS. Way too many manual steps, more and more work over time, and so on. The correct way to go would be, of course, to be a part of the original project, but this seems to be quite irrelevant right now for various reasons and is out of the question.
Ideas?
I'd use git or mercurial for this; simply import the project into git or mercurial, and merge the upstream changes into a branch in your project for easy merging into your trunk.
If the upstream project has a repository of their own, the import is even easier. Both git and mercurial have support for directly importing other version control systems. I did this recently to adapt an existing project that lives in SVN: https://github.com/mjpieters/rod.recipe.rabbitmq
Note that that project has an 'upstream' branch. That particular project has now accepted my proposed changes after reviewing the changes in github.com.
There are a few questions here on SO on the subject:
Fork and synchronize Google Code Subversion repository into GitHub
Tracking upstream svn changes with git-svn and github?
Best way to fork SVN project with Git
It should be trivial to create a similar setup with mercurial.
You can use git to maintain your source control on your local system. In fact Git can be used to maintain just about any directory under version control. There is no need to sync to anything, git maintains all changes locally.
If you need to commit to SVN check out the documentation http://git-scm.com/docs/git-svn
[answer auto-selected by bounty system against my will]
I'm using subclipse, and always when delete a folder in Eclipse, and try to commit it, the following errors raise:
svn: Item <folder> is out of date
svn: DELETE of <folder>: 409 Conflict (http://myintranet)
Deleting and commiting via command line works fine, but what's wrong with doing it via subclipse? Is anyone more experiencing this problem?
(I experienced this problem in Ubuntu 9.10 and 10.04; last Eclipse version; and subclipse 1.4 - as the next versions of subclipse have much more bugs)
--updated: Its when I delete folders, not files
Isn't that addressed by the Subclipse FAQ?
Whenever you see "out of date" in an error message it means that the revision of the item in the repository is newer than the copy in your local working copy.
The solution is always going to be to run an update, so that your working copy is up to date with the repository, and then do the commit again (assuming that the update did not generate any conflicts).
For files, this is usually pretty easy to understand how and why this happens.
However, Subversion also versions folders, and it is usually with folders that this problem most often happens.
Subversion does not allow you to delete/rename a folder OR change its versioned properties, UNLESS the local copy of the folder is at the HEAD revision of the folder in the repository.
Your next question might be:
"OK, I can maybe understand that, but why is my folder out of date? I am the only person working in this repository."
That is a valid question, the answer lies in the way that Subversion works.
When you commit a change to a file, the revision of the file in your working copy is updated to that new revision when the commit completes, however the version of the parent folder(s) of that file is not updated.
This is because there may have been adds/deletes to other files in that folder and until you have run an update, the folder is not really at that new revision.
This is called "mixed revision working copies".
In summary, the answer is always to do an update so that the folder or file is updated to its HEAD revision.
About "Mixed Revision Working Copies":
One special kind of flexibility is the ability to have a working copy containing files and directories with a mix of different working revision numbers.
One of the fundamental rules of Subversion is that a “push” action does not cause a “pull,” nor vice versa.
Just because you're ready to submit new changes to the repository doesn't mean you're ready to receive changes from other people.
The fact is, every time you run svn commit your working copy ends up with some mixture of revisions.
The things you just committed are marked as having larger working revisions than everything else. After several commits (with no updates in between), your working copy will contain a whole mixture of revisions
(and that is why, I believe, you cannot reproduce your "out of date" message on subsequent commits with folder deleted: your update did solve the "mixed revision" state.)
Mixed revisions have limitations
You cannot commit the deletion of a file or directory that isn't fully up to date.
If a newer version of the item exists in the repository, your attempt to delete will be rejected to prevent you from accidentally destroying changes you've not yet seen.
i think if you UPDATE before that it should work.. it did work for me
There's a simple solution without installing some extra software. I also had this "problem" and what you can do is the following:
1) open the SVN Repository view
2) there go to the folder you want to get rid of and delete it
3) go back to the java view
4) update the folder in your project you actually deleted / update your project should also work
That solved the problem in my case, as updating only retrieved the files I deleted
Subclipse has many problems like this. It works 90% of time, and then it just DOES NOT work as it should! I am using subclipse, since it is very well integrated into eclipse, and when I have problem or some bigger moves needed in svn (like merging some branch) I use Tortoisse.
I had the thing with directory like you. Then I just run the TortoiseSVN like #luiscolorado suggests, and it helped. Tortoise is so great tool (it has many great features for diffing, applying patches, getting patches and so on.).
Today I had a problem when I have removed a file, and someone had changed the same file! Then subclipse shows conflict (up to this point everything is ok), so I wanted to revert! But then the revert button is missing (disappears when inconflict mode!) so I have to do merge, and merge does not work, throws some kind of error. I didn't bother to read (maybe I should read and file it as a bug to subclipse maintainers ;-(), I knew the tortoisse will work, and you know what, it worked. There was a REVERT option.
So #Tom Brito, try command line, try Tortoisse, and then you can look at the subclipse changelog and file a bug. I think that subclipse just forgets to show us some directory changes and updates (or it is designed not to do it?), but I may be wrong.
Tom,
You might want to try TortoiseSVN, and manually update the project workspace. Find the location of your project directory in your hard drive, and then try TortoiseSVN (or the command line if it's your preference) to do the update.
A frequent cause of this problem is to delete the directory without "informing" SVN. For instance, if you manually delete the directory using the operating system instead of using SVN, you will have this problem.
If you removed the directory before you installed the subversion plug-in, but the project already existed in the repository, you will experiment this problem. A solution, in this case, would be to recreate the directory, updating/committing, and then delete again the directory.
Good luck.
My solution to this was
Delete all items in folder
Commit to repository
Update folder to HEAD
Delete folder in Eclipse
Commit to repository
A bit cumbersome, maybe, but it always works
The only working way in same cases is via command line. The subclipse is still not perfect..
I want to use Bazaar on Windows XP for web-development and related tasks. Most of the files are edited locally and then transferred via FTP to the server. Just now the repository sits on my local workstation. Later on it should be shared locally with some co-workers. Perhaps we will use a local Linux server as a centralized repository, but this structure is not decided for now. But first I need to understand the impacts of the different repository setups, which I do not at all.
Using Bazaar-Explorer on Windows XP I’ve created a ‘shared tree repository’ from the option list of the init-dialogue in some location dev-filter/. Bazaar Explorer tells me:
Created repository with treeless branches at F:/bzr.local/dev-filter
Created branch at F:/bzr.local/dev-filter/trunk
Created working tree at F:/bzr.local/dev-filter/work
OK so far. Now I move a bunch of files into the work directory and add and commit them as Rev 1 ‘Start Revision’. Then I work on some of these files and commit them again as Rev 2. Here my confusion starts. Shouldn’t both revisions go into the trunk? The trunk is still empty, beside the .bzr directory which only holds some management information. If I delete my working directory, which I have tried during these first experiments, everything is gone. There’s obviously no hidden storage of those files.
OK. Perhaps I need to push it into the trunk? This does not work either. Entering the work/ directory and initializing the ‘push’ to the trunk, Bazaar-Explorer tells me
No new revisions to push.
So what? This looks like a severe conceptual misunderstanding about what should happen on my side.
Edit, 2010-02-03: Some conclusions
What I learned meanwhile is this:
I think I should switch to the command line until I really understand what’s going on, at least for creating the repositories and branches. Bazaar Explorer introduces a new level of abstraction which I only can handle if I understand the level beneath
One of the secrets of working with Bazaar at least for me is to understand those .bzr directories, their particular properties and states when created with ‘bzr init’, ‘bzr init-repository’, ‘bzr branch’ etc. in all their variants and how they are plumped together.
While there’s a whole chapter of ‘Organizing your workspace’ in the Bazaar User Guide, it’s more or less workflow oriented. The manual contains a lot of directory structures for the given examples. What I would prefer beside this and have not (or only rudimentary) found so far is some graphical representation of those ‘Lego like’ .bzr building blocks which create the linking of all the parts. So I started to invent some simple notation while working through the examples and looking into the .bzr directories to document what information is stored there, where does it come from, how and to what is it linked, is it complete or shared, etc.
Erich Schreiber
Created repository with treeless
branches at F:/bzr.local/dev-filter
This part of the output looks suspicious to me. Are you sure you chose 'Shared repository' and not 'Shared repository with treeless branches' from the init dialog?
Treeless Branches are branches without the working tree, if you indeed created a treeless branch for trunk then it makes sense that there are no files there.
Your changes are still saved in the F:/bzr.local/dev-filter/trunk/.bzr, and have indeed been committed there. You don't see those changes reflected in the file system because Bazaar has created trunk as a treeless branch, with `` as a lightweight checkout. See checkouts in the Bazaar User Reference.
If you open F:/bzr.local/dev-filter/trunk in Bazaar Explorer, you should see your revisions. If you create a new branch with a working tree or checkout based on trunk, Bazaar will create the files with your changes for you.
typically it goes like this.
bzr init-repo --no-trees F:/bzr.local/dev-filter
cd F:/bzr.local/dev-filter
bzr init trunk
bzr branch trunk work
---all above will not create any tree
Now in new directory say F:\temp
cd F:\temp
bzr checkout F:/bzr.local/dev-filter/work
bzr add
bzr commit
---back to F:/bzr.local/dev-filter/work
cd F:/bzr.local/dev-filter/work
bzr push F:/bzr.local/dev-filter/trunk