Eugene Kuleshov <eu@javatx.com> wrote on 08/16/2005 08:58:05 PM:
> Mark Phippard wrote:
>
> >>If I have an existing project and I want to hook it up to the same
> >>project in a repository (ie: if I am changing URLs or using a
> >>different repository location or username/pw combo), I end up with a
> >>StringIndexOutOfBounds exception with this stack trace:
> >
> > I have good news and bad news. The good news is that I fixed this
problem
> > recently and it will be in the next release (this problem has always
> > existed in Subclipse). The bad news is that it is not fixed the way
most
> > people will want. The Subversion libraries do not currently have any
way
> > to do what needs to be done here (turn an existing project into a
valid
> > working copy). So all I could do to fix this problem is head it off
in
> > the UI and make it clear you cannot do what you are trying to do.
> >
> > See: http://subclipse.tigris.org/issues/show_bug.cgi?id=345
>
> Mark, as you've seen in the list, this is a very common and very
> annoying issue. I believe there is a more user-friendly approach that
> shouldn't be difficult to implement and that should give acceptable
> results. What I think is to warn user that there is no copy and give him
> two choices:
>
> -- First one. Forget about it like you've suggested.
> -- Second. Try to recover (with some chance to succeed) using the
> following approach:
> -- move all the files from existing location into a temporary/backup
> location (let user to choose where it will be and also provide default
> location somewhere in user.temp)
> -- checkout project from svn into emptied project location
> -- merge checked out project with the backup copy. Match files by
> name (ignore case when files are moved around) and compare file content
> and if it doesn't match - copy backup file over checked out one.
> -- run synchronization and as result all changed files should appear
> on synchronize view (practically very similar to CVS).
> -- if something went wrong user can always move backup copy over the
> original location (again could be done in Subclipse UI after previewing
> and confirmation).
>
> I believe this will be way less confusing and much more convenient
> than checking out into a separate location (with conflicting project
> names!) and manually compare/copy different files.
I have thought of this too. In the end, I just do not think that is the
kind of code we should have in Subclipse. I think the end result of this
is what people would want, but I doubt this is how they want it
implemented. Ultimately, this is a feature that ought to exist in
Subversion. It looks like their developers agree. I am willing to wait
for it.From the conversations I have had with the Subversion developers,
they feel that their checkout command ought to just work this way be
default. The biggest area of debate is whether they ought to try to make
this work like rsync and only send down the files that are different. Some
of the Subversion developers think that would be too much code, others are
not so sure. All agree that at a minimum, checkout ought to be able to at
least do this inefficiently.
Perhaps Alex will add it to JavaSVN before they add it to Subversion? That
would be nice.
If you want to try to make the above code bullet-proof, as well as work on
all plaforms and permissions systems, be my guest. It sounds like it
would be a lot of work for a feature that might be available in Subversion
in the near future.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Wed Aug 17 11:08:45 2005