> Finally, if you wanted to implement that in Subclipse the hardest part
is
> going to be the local actions. You could not select the Project root
or
> src folder and do Team -> Commit/Synch/Update/ anything because that
> folder is not a working copy. So you'd have to root out all code that
> might make these assumptions and fix them. The actual checkout part
would
> not be too difficult, you would just need do the right validations and
the
> UI changes.
I've started to look at the code, and I just want to get a check
on my understanding so far. The class I've found that seems most
relevant is SVNWorkspaceRoot. In particular I'm looking at the
SVNWorkspaceRoot.localRoot field. I'm hoping this might be the one
central point through which "all the code that might make these
assumptions" would flow.
The localRoot field is used by two methods: getRepository() and
getLocalRoot(). If we can come up with another way to associate a
repository with an SVNWorkspaceRoot, that might solve most of the
problems. (Of course, subsequent checkouts into that project would have
to verify that they're using the same repository. But I think that's a
limitation we can live with.)
getLocalRoot() is clearly more problematic, but it's only used
in three classes: SVNProjectSetCapability, StatusAndInfoCommand, and
RepositoryProviderOperation. (I haven't had a chance to figure out the
purpose of the 1st and 3rd of these classes yet).
LocalResource.getURL() also seemed a bit worrisome, but I think
I have talked myself out of that. It looks like it ends up calling
StatusUpdateStrategy.statusesToUpdate() -- and both implementations of
that explicitly avoid calling getRepository(), so I think it's okay.
What I haven't yet found in the code is where e.g. the Update
command makes the assumption that a folder is a working copy. Maybe
that's in UpdateResourcesCommand.run() where it just passes the File for
the folder to ISVNClientAdapter.update(), but I don't yet understand
enough to tell for sure.
Anyway, any corrections / comments / suggestions are appreciated
...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Wed Aug 9 22:45:01 2006