I'm trying to commit my changes to my SVN repo, by clicking on the file, team, commit, but then in the Console in eclipse, it says
commit -m "" /Users/admin/Documents/workspace/Challenge5-Ghostomatic/GhostList.java
Skipped
And it does that for all the files, even though the local version has changes that the SVN doesnt have. How do I fix this?
This "skipped" thing comes from the fact that somewhere, somehow, you corrupted the two trees of files between the repository and your local copy. It is most likely that the issue comes from the fact that you did not merge the two repositories, your local copy, and the subversion copy, before making changes to your file, or adding a file.
Following this tutorial all the way through might help. It's very short and should clear up all your errors.
http://www.eclipse.org/subversive/documentation/gettingStarted/aboutSubversive/mylyn.php
If you checked out your project using subclipse or the built in subversion client then it should be a local working copy. You should verify that as kraftan suggested.
If you have somehow corrupted your local copy you can always check out the head revision to a new project area and copy your locally updated files over again. I would suggest backing up your working area before mucking around too much.
What happens if you run a compare with latest from repository?
Related
Is there any build tool like maven,gradle support to build only staged/committed code not to include unstaged/untracked file.
Basically while development some scenarios arise in middle I want to check what committed package vs uncommitted one.Though I can achieve two different directory but such flexibility in any build tool will help a lot.
Ex: Consider I have one maven project I modified and committed & pushed the code to GIT Repo.Later I started my further development.When I do build, it builds including all the files but I wanted to know If there is any way I can skip the unstaged/untracked files in maven pom.xml to build only committed files.Any plugin like that which helps to achieve this or any other build tools.
I think git stash comes in handy for this:
Use git stash when you want to record the current state of the working directory and the index, but want to go back to a clean working directory. The command saves your local modifications away and reverts the working directory to match the HEAD commit.
Something I use and find very convenient is particular Source Code Management plugin for Jenkins, see complete list of similar here. In my case I use Git plugin, which provides Refspec configuration property. I put there either committed or uncommitted changes' refspec. The build uses source code built until the change pointed in the refspec. Due to my understanding - this is exactly what you need.
P.S. I also build with maven, even though this doesn't matter for this case.
I have made a few changes, then pulled from git.
I have had merge conflicts after pulling from git.
I have resolved these conflicts, but my app doesn't work as expected.
How can I revert my solutions (undo) conflict resolution?
I'm using 'egit', and 'source tree'
btw, what is a recommended conflict resolver tool?
You can use git merge --abort to abort the whole merge process and take the repo to the state prior to merging.
git reset --hard HEAD~1 will put your code and git repo both back to where they were before the last commit, which is probably the merge commit. Then you can try merging again.
If you don't care about the changes you had, you can always nuke everything local and start with a fresh git clone.
I've been working on a Java package using eclipse and have been using git for version control. I accidentally git rm'd a file, committed and pushed it.
In order to revert the effects, I did a checkout of the deleted files from a previous commit, did another commit and pushed it back. Now I have my files back.
However, those files do not show up in the package in Eclipse -- what could I be doing wrong?
I sometimes get inconsistencies between Eclipse and Git, to solve this I usually just refresh the Eclipse project. I could be more complex than this, but eliminate the simplest solution first.
I'm trying to share a project between my desktop and laptop using Subversion. The project has 3 modules. I've imported the project folder into a repository in a shared folder that my laptop can access over the network.
I checked the project out on my laptop and then tried to open the project. None of the modules are visible, only the project's .iml file, as in the screenshot below.
I notice that the .iml file has a line for "content url", which refers to a location on my desktop. Maybe this is the problem. What can I do about it? Do I have to create a new project on the laptop and import the modules - so there would be 2 different top level .iml files, one for the desktop and one for the laptop? Am I going about this the wrong way?
UPDATE: The problem seems to be with committing. When I make a change in a file, save, and hit Commit Changes, I get a popup saying "No changes detected". This is the same on both laptop and desktop, and meant that I downloaded the wrong version onto my laptop before. I deleted the repository and created a new one, and my project works on my laptop now, but I can't commit changes from within IntelliJ (only with TortoiseSVN via file manager). Also, when I imported my project into version control from my desktop computer, the working copy wasn't put under version control. So I can't update from my desktop unless I check it out to a different folder.
I think there is something wrong with the SVN plugin with this version of IntelliJ (10.5.1). Does anyone else have problems with committing changes?
RESOLUTION I needed to
1) Update Settings | Version Control to map Subversion to the working directory
2) Import into Version Control
3) Check it out again
It may possibly have been caused by the fact that the modules were originally standalone projects which were in separate repositories. Whatever the cause, IntelliJ's "No changes detected" dialog isn't the most helpful.
VCS -> Refresh File Status solved this for me, when Intellij suddenly stopped noticing changes.
Please refer to the FAQ.
As for the content root, make sure that it's located under the project root or module root, in this case the path will be stored relatively to the project/modile root inside the iml file. If the fixed system specific path is used in the iml, such module will not work on other systems.
UPDATE:
Make an explicit mapping between the actual working directory and Subversion in Settings | Version Control dialog. If you are using the default placeholder and your project files are not under the checkout root, it could be the case.
After performing the initial import you need to do a checkout in order to use version control in IDEA.
Sometimes doing VCS -> Refresh File Status works for me.
Other times, it does nothing.
A solution is to
COPY all your file contents to clipboard / external notepad (for backup)
Choose Rollback on the file which needs updating. Now it is up-to-date with the server and does not contain your new changes.
Edit file again (checkout), and PASTE your original file contents.
Attempt to commit changes. It should detect them now.
I just ran into this today- checked out an existing project and had to update the SVN scheme from 1.6 (I think) to 1.8. That seemed to make Subversion not recognize that it was wrong it its belief- even though I could DIFF and see changes relative to the latest repository version- that "No Changes Detected."
I got so fed up that I shut down Intellij...on a whim I reopened it, and the file in question appeared blue...hmmm...yep, now it detected the changes.
I had the same issue it seems it may have been caused by having a file with the same name in two different GIT-repositories.
I was able to fix it by opening File -> Settings -> Version Control and then un-assigning and re-assigning GIT as the VCS of the two directories which both had the file. First the directory in which there was no changes in the file then the other active one which did have changes (but which did not detect them before).
I got into the similar issue today and I tried VCS -> Refresh File Status, but it didn't help me. When i looked at Version Control->Subversion Working Copies Information, i found an svn error The working copy at /home/project is too old to work with svn client 1.9.4. First i ran svn upgrade and then doing VCS -> Refresh File Status resolved my issue and i was able to commit my changes.
None of the other solutions here helped me.
Ended up checking out the entire repository again, copied all the sub folders over to the newly checked out folder and submitted the changes.
Deleted the old folder and renamed the new folder to the old folders name.
Over the course of having this repo (originally SVN) I've not been to good with keeping file links together. I've changed IDE's twice, split the project into Netbeans modules, and mavenized the project over its time. Most of the file history is lost, mainly because during mavenizing I deleted the entire trunk, committed, copied over the maven project, and committed. Not exactly the best idea, as I later found out all history reset to that point. Its gotten so bad that a repository stats program is useless since it says I have 50,000 lines of code invested instead of ~8,000.
Is there any way to fix all the broken file histories? I have access to SVN and Git if Mercurial can't do it
Hrm, and the time you did your delete and copy you'd've been fine had you just done hg addremove --similarity 90 which says "remove everything that's gone, add everything that's new, and if they're 90% similar to one another count is as a rename".
Now that that opportunity has passed there's no way to move one w/o re-writing your repository, which invalidates all the clones out there in the wild as all the node ids (hashes) change. If that's okay and you have a largely linear history you can probably get by with something like this:
hg export --output "../patch-%n.patch" 0:tip # exports every changeset to a patch file
cd ..
hg init newrepo
cd newrepo
hg import --similarity 90 ../patch*
That takes a linear history from your first commit to your last (excluding branches and other heads, etc.) exports them to patches, creates a new empty repo, and imports the changesets using the rename detection feature.
This is a pretty drastic act so make sure it's really worth it to you and keep your old repo around for good measure.