Hi again,
I did some more testing now. With JavaHL it worked right away. With
svnkit it did not work until I added all the svnkit source to the
subclipse core plugin - then all worked. The svnkit code is calling
attrib -R using a Process object on Windows. When I debugged it it
worked...
Well, I suppose it will work when I export everthing as real feature /
plugin. I did not try that until know.
Anyway if it does not work it is a svnkit problem.
So I think that no more changes on subclipse side are necessary.
Thanks,
Thomas
-----Original Message-----
From: Thomas M. Hofmann [mailto:email@thomashofmann.com]
Sent: Freitag, 5. Januar 2007 12:34
To: dev@subclipse.tigris.org
Subject: RE: [Subclipse-dev] Another bug in new locking code in 1.1.9
As far as I have seen there is some code that should change the
read-only attribute in svnkit. I wonder why it doesn't work.
It worked in previous versions so this is really strange. I tell you
what I find out.
-----Original Message-----
From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Freitag, 5. Januar 2007 12:20
To: dev@subclipse.tigris.org
Subject: Re: [Subclipse-dev] Another bug in new locking code in 1.1.9
On 1/5/07, Thomas M. Hofmann <email@thomashofmann.com> wrote:
>
>
> sorry for replying so late. I loaded your changes and now the file is
left
> read-only when it is locked by another user.
>
> Unfortunatley, I noticed another problem while trying to lock a file
that is
> not locked at all. The SVN decorator turn to the black and white
checkmark
> but the file stays read only (I refreshed the resource manually and
checked
> on the file system). I know that svnkit will chnage the read-only
attribute
> and I tried to debug into the code that does so but I hadproblems
because it
> it not so easy to find the source code for svnkit that matches the
line
> numbers used in the svnkit jar bundled with subclipse. Since I did not
have
> much time the past days I did not succeed to find the cause for this
> problem.
>
> I hope that I have some time this evening and I will 1) check if this
also
> is a problem with javahl and 2) try to get svnkit debugged.
>
> I thought I'd report this now since you might already know what is
causing
> this. If you don't I'll post more info hopefully this evening (CET).
The current code is back to how it used to be in this regard. Namely,
we now expect and assume that the client interface (JavaHL or SVNKit)
will behave properly and make the file writable when the
svn:needs-lock property is present and the file is successfully
locked. I'd be surprised if JavaHL had a problem here. We could
report the problem to SVNKit. I'd assume it would be consistent but
it sounds like it is not.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Fri Jan 5 23:43:32 2007