File structure is detached from SVN repository.

[John Vorwald]

I reinstalled eclipse, and imported my project. But, after installing svn, none of the files are associated with a repository.
The repository is still there, but doesn't include modifications made in the past 24 hrs.
So, apparently, I have unknownling detached a file structure from the repository. So, how do I upgrade the repository with the current files. Is it possible to identify which files are different than the repository before starting?

I did an export on the repository to create a current copy that was not under repository control. Possibly, this caused the working copy to become detached also.

[John Vorwald]

More information.
The file structure in Windows does not appear to be under SVN control any more.
In eclipse, I imported a project from the file structure before installing SVN plugin.
The repository is still there, but, I believe that some of the files in the Windows structure have changed.

I think I need to move the current files into the repository, but they are not under control.
And then checkout the project again.

[Jeff Verdegan]

This question has nothing to do with Java. Somebody here may know the answer, but you'll probably have better luck on an Eclipse forum or an SVN forum.

[John Vorwald]

I agree Jeff, that this issue is not related to Java. But, I don't know where to look for the answer. Spent a few minutes googling, but haven't found anything yet. I see you can import into a repository, which seemed to pick up the changed files, but I'm not sure.

[Peter Johnson]

Do the .svn folders exist in the various directories of your project? You will have to view the directories in Explorer to find out. If they are not there, then the project has been detached from Subversion. If they are there, and exist even in the base project directory, then the Subversion plugin in Eclipse should recognize them. Note that the .svn folder in the base project directory is key - it must be there before the Subversion plugin will recognize that the project is in Subversion.

If you are detached, this is what I do when it happens to me (I often detach on purpose):

1) Close the project in Eclipse and move the project directory somewhere.
2) Within Eclipse, import the project from Subversion again
3) Using a file diff tool, merge your changes from the side directory (from step 1) into the Eclipse project.

By the way, are you using subclipse or subversive?

[John Vorwald]

Hi Peter,
The windows directories do not contain the svn sub-directory, so it looks like I detached from svn.
In eclipse am using subversion.
For windows, I am using Tortoise.

Your suggestion is to copy the files to a new directory, delete the files, check out from svn, do a file diff, and check back in. Unfortunately, I don't have a diff program to do diff on directories to identify which files changed. The project has a fair number of files/directories.

John

[Peter Johnson]

In eclipse am using subversion.

There is no such Eclipse plugin. Is the plugin named "subversive" or "subclipse"?

I don't have a diff program to do diff on directories to identify which files changed

I use CompareIt! and SynchronizeIt! from http://www.grigsoft.com/files.htm. I think that you can use them for a short period before paying for them. Google search should yield others. Microsoft even provided a tool called windiff, but it didn't let you easily merge changes within files.

If you are confident that only you have changes to the originals in Subversion, you can simply copy over the backed-up files to the Eclipse project.

Also, the checkin process within Eclipse lets you examine the changes made. This is one way to manually check the differences.

[John Vorwald]

The eclipse plugin is Subclipse, which includes Subversion Client Adapter

[John Vorwald]

OK, I'm trying to recover the svn structure and determine the difference with current files.
1) Zipped current files and copied directories to different drive, about 250 MB of files.
2) Delete original directory
3) Use SVN Checkout to checkout copy to original directory
4) Download synchronize it and compare it from http://www.grigsoft.com/files.htm
5) That was an unexpected result, all the .java files match. Did a svn version before extracting a copy to share. Possibly, the repository has all current files.
6) So, I tried doing a svn diff by holding down the shift key and selecting the top level directory of the branch of interest, and selecting "Tortoise SVN/Diff with URL". That generates an error because .bin was removed from svn and is indicated that it is not found.
7) Then selected branch/src for comparison, that shows while files changed, can't see the recent changes. This isn't the information that I was looking for.
8) Went back to synchronize it, and changed options from "Update Target" to "Synchronize", with .java file filter. Now a handful of files appear. This may be the set of files that I was looking for.

I'm not seeing the change that I was looking for. Currently, the Java code fails due to a hashcode mismatch when a data file is read. I've deleted the data files, so that the files would be recreated, and presumably, then the hash codes would have to match. They still don't match (hashcode read from file compared to calculated hash code after reading the data file). One possibility is that something is in the hash code calculation that is not stored in the data file. There was some recent changes to the hash code calculation by using the Eclipse generated hash code calculation instead of the hand coded hash code. But, the above comparison is not identifying the java classes with the eclipse created hash code routines.

I need to think more about this...

[Tim Holloway]

My brain is too fuzzed this morning to understand all that, but I'll throw out some observations and suggestions. Maybe they'll help

#1 is that there are 2 ways to get a tree from an SVN repository. "svn checkout" will download all the files and build local hidden SVN context. "svn export" will download all the files, but NOT build any local SVN context. In other words, you get the files, and only the files, as though they'd never been checked into SVN. This can be a help if you're tossing stuff around and running afoul of the SVN context.

#2 is that svn looks more at content differences than at timestamps, so a change that is no change may not register.

#3 is that Eclipse (actually the eclipse svn plugins) doesn't maintain any svn information of its own, it simply works with the SVN context in the ".svn" hidden directories. However, Eclipse does occasionally need to be "thumped" (refreshed), if files in an Eclipse project change - even when they're invisible, like the svn context files/directories are. Occasionally, I've even had to restart Eclipse after refreshing in order for it to get the hint.

When you import a project that was checked out from svn into Eclipse, normally, Eclipse will pick up on that. However, a "team share" might occasionally be required. As mentioned, sometimes Eclipse doesn't take the hint. Better is to check out the project via the SVN repository view in Eclipse. However, do allow for potentially long delays if it's a big project. Since Eclipse does a lot of things asynchronously, it may allow you to move on to other tasks while it's still doing work on an SVN import.

[Peter Johnson]

These (#1, #2, #3) are all true, and deserve to be made known to anyone working with Subversion, especially in conjunction with Eclipse. These are things that I have sort of instinctively learned over the years, but it is good to see them pointed out, and for that I thank you! I sure that Ranchers that come across this post in the future will thank you also.

[Peter Johnson]

After reading both of your last posts, I am not sure at what point you are at. Have you successfully run SynchronizeIt! and have it identify files you know changed? Usually, I will tell SynchronizeIt! to ignore files in the folders: .svn,target. The first so that it doesn't look at the local Subversion info, the later so that it will ignore built files (my builds use Maven, so all non-source stuff is in that directory). At times, dues to timestamp issues, I also need to tell SynchronizeIt! to "Compare files of same size". Oh, and make sure "Include subdirectories" is selected.