[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[Subclipse-users] FW : Mylar and team support thread

From: JoŽl Cheuoua <jcheuoua_at_gmail.com>
Date: 2006-09-11 04:56:13 CEST

Hello there,

I'm forwarding here a discussion thread from org.eclipse.mylar newsgroup.
Hopefully there are some comments there that you could analyse and register
as bugs or maybe just consider as enhancements.


Joel Cheuoua

"Mark Phippard" <markp@softlanding.com> wrote in message
> Joel Cheuoua wrote:
>> What I didn't like :
>> - Some annoying bugs : Indeed rename/move is not working the "svn"
>> way when you rename/move a resource twice : it's considered deleted
>> and the renamed one is considered added. and this is not only a side
>> effect of the Synchronize view that even on subversive case shows the
>> old resource name as deleted and the new one as added (a bug in my
>> opinion in both cases because you're able to commit the "added" one
>> and not he "removed" one and that doens't make a lot of sense). In
>> the subclipse case, if you look at the history you cannot see that
>> the new resource in fact has had another name ... hence back to cvs
>> age.
> Subversion does not allow a resource to be moved twice, without doing a
> commit in between. The Subclipse team has enhanced this limitation in
> Subversion and it will be available in 1.5. I thought that Subclipse
> just threw the error from Subversion back at you in this case, but it
> sounds like there might be a workaround in place so that the operation
> can still run. The JavaSVN library already has this "feature" in it,
> which is why Subversive does not have the problem.

Ok, I can understand that ... and yes I do not have an error, I "just" lost
the history. However I'd rather stick on a JavaSVN-like behavior meanwhile
as I've no clue to when Subversion 1.5 will be out. I tried switching to
JavaSVN in Subclipse preferences, but I still loose the history when I
rename the resource twice. Is it a "side effect" of the workaround applied
for javaHL in Subclipse ? Another problem is when I commit the rename (hence

commit the "addition" and the "removal" ... but again this is a common bug
to subclipse and subversive), then I try to show the resource history of the

new resource, I see in the "affected path" that there is indeed a deletion
and an addition.
When I double click on the deletion to see the content of the file that has
been deleted I got this error in the console :
svn: URL

non-existent in revision '26'

>> Another one I remember : I've set a SVN server on windows and
>> defined a username/password, but Subclipse never asked me these
>> credentials to perform SVN operations. Subversive did.
> In Subclipse, the prompting is done by the client adapter (JavaHL). If
> you did not get prompted and you were using JavaHL, then one of two
> things happened:
> 1) You did not do an operation that required credentials. For
> example, if the repository allows anonymous reads you will not be
> prompted during checkout.
> 2) Since JavaHL is just Subversion, it shares the same credentials
> caches as all other Subversion clients. So if you used TortoiseSVN, or
> the SVN command line to access the repository, and cached the
> credentials, then JavaHL will be using those same cached credentials.

Number 2) is probably what I experienced, as I used TortoiseSVN before. I
just tried to change the password and perform a commit, and subclipse indeed

asked me the password this time. So I guess what I thought to be a bug in
Subclipse turns to be a feature (that Subversive don't have) ... nice ...
and sorry for my misunderstanding.

>> Also Initial
>> sharing of the project do not set all the resources as checked for
>> commit ... cosmetic bug, but a bit strange ... and at first I had the
>> feeling that the plugin wasn't working at all.
> It is a preference whether unversioned resources are initially selected
> in the commit dialog. It used to be on by default but several users
> made convincing arguments that it should be off by default.

hmmm ... well ok, I don't know what arguments they gave, so they might have
been very persuasive :) the only one I have is it looked stranged to me as I

would have "naturally" expected my files to be shared after performing the
action "shared project" but that's alright, maybe I'm too acustomed to the
CVS plugin.

> If you have found any other bugs that you would like to report, we
> would appreciate hearing about them on our users@subclipse.tigris.org
> mailing list, or our Eclipse newsgroup.

Thanks for your answers and comments. I've CC the Subclipse users mailing
list so that bug descriptions I'm putting here can be
investigated/registered. If I remember or experience more problems during my

Mylar demo I'll let you know.

Thanks again.

Received on Mon Sep 11 05:02:19 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.