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

Re: Seeking JavaHL developers for RC

From: Daniel Rall <dlr_at_finemaltcoding.com>
Date: 2005-10-20 23:17:23 CEST

On Thu, 20 Oct 2005, Marc Sherman wrote:

> Mark Phippard wrote:
> >
> >No, I am not trying to say either of those things. One way or another,
> >the combination of these two API's ought to be sufficient. I was merely
> >trying to articulate that I think the "get" API you added today is all
> >that we will need and use in Subclipse. Of course when I look at the code
> >I might find that I can in fact make use of the "is" API. All Subclipse
> >has today is a constant of ".svn". I replaced the constant with a method
> >call that returns the same value. Perhaps that code could be written
> >differently in some places to use the "is" API, but at a minimun the "get"
> >API should be all we need.
> I think what Daniel's saying is that what Subclipse is doing today isn't
> sufficient for what subversion is doing in 1.3.

I tried, but it's always easier when someone else says it for me with more
clarity. ;-)

> Curently, Subclipse
> only knows about one directory. In svn13, subversion potentially knows
> about 2 different dirs, ".svn" and "_svn". The get api returns _svn,
> but the is api returns true for both names, as I understand it.


You'll see this behavior on Windows or Cygwin when the SVN_ASP_DOT_NET
environment variable is set.
> In places where Subclipse is just comparing a dir name against the adm
> dir name, subclipse could use the is api through javahl. However, in
> many places where Subclipse is using the get api, such as to register it
> with Eclipse for hiding, it should actually call a third api that
> doesn't currently exist, get_all_possible_admdirnames, which returns
> {"_svn",".svn"}.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 20 23:17:10 2005

This is an archived mail posted to the Subversion Dev mailing list.

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