You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Anderson <da...@calixo.net> on 2005/10/19 16:15:43 UTC
Seeking JavaHL developers for RC
So, blockers that prevent rolling 1.3.0 RC1 are quickly disappearing.
The one which remains now, is the support of the ASP_DOT_NET_HACK in the
JavaHL bindings. It seems that I can't find a JavaHL developer to do
this so that we can go ahead and cut the RC.
Which brings about a worrying question: are the JavaHL bindings still
being maintained? If so, this needs to be addressed fast, or at least
someone needs to give feedback on the list. Right now I have complete
radio silence about JavaHL, which to me indicates that a release will
have to be cut without the mods to JavaHL, which sucks.
Thoughts?
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by David James <ja...@gmail.com>.
On 10/19/05, David James <ja...@gmail.com> wrote:
> On 10/19/05, David Anderson <da...@calixo.net> wrote:
> > So, blockers that prevent rolling 1.3.0 RC1 are quickly disappearing.
> > The one which remains now, is the support of the ASP_DOT_NET_HACK in the
> > JavaHL bindings. It seems that I can't find a JavaHL developer to do
> > this so that we can go ahead and cut the RC.
> The Perl and Ruby bindings also need to be patched to call
> svn_swig_init_asp_dot_net_hack(). Currently, only the Python bindings
> do this.
Fixed in r16834 and nominated for backport to 1.3.x. Ruby and Perl
developers, please carefully review this fix. (It seems good to me.)
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: Seeking JavaHL developers for RC
Posted by David James <ja...@gmail.com>.
On 10/19/05, David Anderson <da...@calixo.net> wrote:
> So, blockers that prevent rolling 1.3.0 RC1 are quickly disappearing.
> The one which remains now, is the support of the ASP_DOT_NET_HACK in the
> JavaHL bindings. It seems that I can't find a JavaHL developer to do
> this so that we can go ahead and cut the RC.
The Perl and Ruby bindings also need to be patched to call
svn_swig_init_asp_dot_net_hack(). Currently, only the Python bindings
do this.
Cheers,
David
--
David James -- http://www.cs.toronto.edu/~james
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 02:03:17 PM:
> Committed revision 16854. Please let me know whether this works on
Windows,
> so I can nominate it for backport to 1.3.x. Long term in
Subclipse-land, you
> may wish to take a similar approach. For now, your existing approach
may be
> easier, given that it obviates the need for introspection or version
checks,
> and works across client adapters.
Tested on Win32 with and without the environment variable and all tests
pass.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Mark Phippard wrote:
> Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 12:47:49 PM:
>
> > Though it was the JUnit tests which you modified (which themselves have
> no JNI
> > dependency), it still seems like it might be much cleaner to rely on the
> > return value of svn_wc_get_adm_dir(). What do you think?
>
> The JavaHL tests use JavaHL (and thus JNI) so if this method were exposed
> via JavaHL it could certainly use it. And I agree it would be cleaner.
Committed revision 16854. Please let me know whether this works on Windows,
so I can nominate it for backport to 1.3.x. Long term in Subclipse-land, you
may wish to take a similar approach. For now, your existing approach may be
easier, given that it obviates the need for introspection or version checks,
and works across client adapters.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Mark Phippard wrote:
> Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 12:47:49 PM:
>
> > Though it was the JUnit tests which you modified (which themselves have
> no JNI
> > dependency), it still seems like it might be much cleaner to rely on the
> > return value of svn_wc_get_adm_dir(). What do you think?
>
> The JavaHL tests use JavaHL (and thus JNI) so if this method were exposed
> via JavaHL it could certainly use it. And I agree it would be cleaner.
I'm putting something together...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 12:47:49 PM:
> Though it was the JUnit tests which you modified (which themselves have
no JNI
> dependency), it still seems like it might be much cleaner to rely on the
> return value of svn_wc_get_adm_dir(). What do you think?
The JavaHL tests use JavaHL (and thus JNI) so if this method were exposed
via JavaHL it could certainly use it. And I agree it would be cleaner.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Mark Phippard wrote:
...
> OK, I ws able to test trunk on Windows with the SVN_ASP_DOT_NET_HACK
> variable set and not set. Both worked, but only after I made some fixes
> to some hard-coded assumptions in the JavaHL test suite. Patch attached.
Thanks for testing it out, Mark!
> I have commit access so I can commit it if I get approval. The patch uses
> the same environment variable checking we are using in Subclipse. Then
> all hard-coded use of ".svn" is replaced by call to a static method
> SVN_DIRNAME() that sets the value based on the environment variable and
> OS.
Though it was the JUnit tests which you modified (which themselves have no JNI
dependency), it still seems like it might be much cleaner to rely on the
return value of svn_wc_get_adm_dir(). What do you think?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Garrett Rooney <ro...@electricjellyfish.net>.
On 10/20/05, Mark Phippard <ma...@softlanding.com> wrote:
> OK, I ws able to test trunk on Windows with the SVN_ASP_DOT_NET_HACK
> variable set and not set. Both worked, but only after I made some fixes
> to some hard-coded assumptions in the JavaHL test suite. Patch attached.
>
> I have commit access so I can commit it if I get approval. The patch uses
> the same environment variable checking we are using in Subclipse. Then
> all hard-coded use of ".svn" is replaced by call to a static method
> SVN_DIRNAME() that sets the value based on the environment variable and
> OS.
This seems fine in concept, although exposing the underlying
svn_wc_get_adm_dir function would be better, so we don't need to have
the logic in two places. One thing I did notice about the patch was
that it seems to use a mixture of tabs and spaces. The existing
javahl code appears to use all spaces, so that should be fixed before
committing.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>Daniel Rall <dl...@finemaltcoding.com> wrote on 10/19/2005 03:10:37 PM:
>
>
>
>>I've committed a patch -- based on Philip's -- which adds support for
>>
>>
>the
>
>
>>SVN_ASP_DOT_NET_HACK to the JavaHL bindings to trunk in r16839. Now, I
>>
>>
>do
>
>
>>not have a Windows dev environment, so was only able to test this by
>>
>>
>hacking
>
>
>>out the #ifdef's for Windows/Cygwin, and examining the working copies
>>created by 'make check-javahl' (all tests pass).
>>
>>It would be great if someone who's actually on Windows could test this
>>
>>
>by
>
>
>>building trunk and either excercising the JavaHL bindings, or running
>>
>>
>the
>
>
>>tests via 'make check-javahl'.
>>
>>
>
>OK, I ws able to test trunk on Windows with the SVN_ASP_DOT_NET_HACK
>variable set and not set. Both worked, but only after I made some fixes
>to some hard-coded assumptions in the JavaHL test suite. Patch attached.
>
>I have commit access so I can commit it if I get approval. The patch uses
>the same environment variable checking we are using in Subclipse. Then
>all hard-coded use of ".svn" is replaced by call to a static method
>SVN_DIRNAME() that sets the value based on the environment variable and
>OS.
>
>
-1. SVN_DIRNAME should return whatever svn_wc_get_adm_dir returns, it
should never even consider the existence of _svn vs. ,svn.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/19/2005 03:10:37 PM:
> I've committed a patch -- based on Philip's -- which adds support for
the
> SVN_ASP_DOT_NET_HACK to the JavaHL bindings to trunk in r16839. Now, I
do
> not have a Windows dev environment, so was only able to test this by
hacking
> out the #ifdef's for Windows/Cygwin, and examining the working copies
> created by 'make check-javahl' (all tests pass).
>
> It would be great if someone who's actually on Windows could test this
by
> building trunk and either excercising the JavaHL bindings, or running
the
> tests via 'make check-javahl'.
OK, I ws able to test trunk on Windows with the SVN_ASP_DOT_NET_HACK
variable set and not set. Both worked, but only after I made some fixes
to some hard-coded assumptions in the JavaHL test suite. Patch attached.
I have commit access so I can commit it if I get approval. The patch uses
the same environment variable checking we are using in Subclipse. Then
all hard-coded use of ".svn" is replaced by call to a static method
SVN_DIRNAME() that sets the value based on the environment variable and
OS.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/19/2005 03:10:37 PM:
> I've committed a patch -- based on Philip's -- which adds support for
the
> SVN_ASP_DOT_NET_HACK to the JavaHL bindings to trunk in r16839. Now, I
do
> not have a Windows dev environment, so was only able to test this by
hacking
> out the #ifdef's for Windows/Cygwin, and examining the working copies
> created by 'make check-javahl' (all tests pass).
>
> It would be great if someone who's actually on Windows could test this
by
> building trunk and either excercising the JavaHL bindings, or running
the
> tests via 'make check-javahl'.
I will do my best to get trunk built tomorrow and to test this. I will
let you know what I find.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
I've committed a patch -- based on Philip's -- which adds support for the
SVN_ASP_DOT_NET_HACK to the JavaHL bindings to trunk in r16839. Now, I do
not have a Windows dev environment, so was only able to test this by hacking
out the #ifdef's for Windows/Cygwin, and examining the working copies
created by 'make check-javahl' (all tests pass).
It would be great if someone who's actually on Windows could test this by
building trunk and either excercising the JavaHL bindings, or running the
tests via 'make check-javahl'.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Wed, 19 Oct 2005, Philip Martin wrote:
> Mark Phippard <ma...@softlanding.com> writes:
>
> > David Anderson <da...@calixo.net> wrote on 10/19/2005 12:15:43
> > PM:
> >
> >> The one which remains now, is the support of the ASP_DOT_NET_HACK in the
> >> JavaHL bindings. It seems that I can't find a JavaHL developer to do
> >> this so that we can go ahead and cut the RC.
> >>
> > Other than that the code is written in C++ I do not think there is
> > anything overly difficult about maintaining the JavaHL bindings. I
> > imagine that most Subversion developers could handle making small changes.
> > I do not even really know C and I have been able to make small changes.
> > In this case, the function has to be called at initialization and looking
> > at the code it is not completely obvious to me where you would do this. So
> > I did not attempt it.
>
> I don't do Java at all. However JNIUtil::JNIInit(JNIEnv *env) appears
> to be the only place that calls apr_initialize, so here's a completely
> untested patch (I haven't even compiled it):
>
> Index: java/javahl/native/JNIUtil.cpp
> ===================================================================
> --- java/javahl/native/JNIUtil.cpp (revision 16820)
> +++ java/javahl/native/JNIUtil.cpp (working copy)
> @@ -28,6 +28,7 @@
>
> #include "svn_pools.h"
> #include "svn_config.h"
> +#include "svn_wc.h"
> #include "svn_path.h"
> #include <apr_file_info.h>
> #include "svn_private_config.h"
> @@ -177,6 +178,20 @@
> unsigned int inwords, outbytes, outlength;
>
> apr_pool_create (&pool, 0);
> + if (getenv ("SVN_ASP_DOT_NET_HACK"))
> + {
> + svn_error_t *err = svn_wc_set_adm_dir ("_svn", pool);
> + if (err)
> + {
> + svn_error_clear(err);
> + if (stderr)
> + fprintf(stderr,
> + "%s: error: SVN_ASP_DOT_NET_HACK failed\n",
> + "svnjavahl");
> + return FALSE;
> + }
> + }
> +
> /* get dll name - our locale info will be in '../share/locale' */
> inwords = sizeof (ucs2_path) / sizeof(ucs2_path[0]);
> HINSTANCE moduleHandle = GetModuleHandle("libsvnjavahl-1");
Invocatin of this code is gated by a ENABLE_NLS macro (which isn't what we
want). I'm working on this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
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.
Exactly.
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"}.
Bingo.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Marc Sherman <ms...@projectile.ca>.
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. 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.
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"}.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 04:51:26 PM:
> On Thu, 20 Oct 2005, Mark Phippard wrote:
> ...
> > What I was really saying is that we are more likely to need and use
the
> > "get" method than the "is" method. For example, we need to register
the
> > name of this folder with Eclipse so that it ignores it on some of its
> > operations, hides it in the UI etc... We also need it so that we can
> > explicitly look for the folder.
>
> So the "get" API is actually insufficient without additional code and
> coupling in Subclipse (to always hide ".svn", in addition to the return
> value of svn_wc_get_adm_dir), and the "is" API isn't usable from an
Eclipse
> plug-in?
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.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Mark Phippard wrote:
...
> What I was really saying is that we are more likely to need and use the
> "get" method than the "is" method. For example, we need to register the
> name of this folder with Eclipse so that it ignores it on some of its
> operations, hides it in the UI etc... We also need it so that we can
> explicitly look for the folder.
So the "get" API is actually insufficient without additional code and
coupling in Subclipse (to always hide ".svn", in addition to the return
value of svn_wc_get_adm_dir), and the "is" API isn't usable from an Eclipse
plug-in?
> I do not think we ever have a case where we have some folder name and we
> want to check if is an admin directory or not.
The idea is that you use that API as the comparator; but, it sounds like you
do not have access to the comparator (only to its inputs)?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Branko Čibej <br...@xbc.nu>.
Marc Sherman wrote:
> Branko Čibej wrote:
>
>>>
>> For what you describe, you _definitely_ need the _is_ version of the
>> API. effetively, you want to do what libsvn_wc does; actually use
>> either _svn or .svn, but treat both as special names (e.g., even if
>> the .net hack is enabled, you still can't "svn mkdir .svn").
>>
>> Reading this discussion, I'm now really sorry I ever provided the
>> _get_ form.
>
>
> Brane, I think you've misunderstood what happens in Subclipse. The
> is_ api can only replace direct string comparisons in the Subclipse
> code. However, there are places where Subclipse must pass the admin
> dir names in to Eclipse code, that is not controlled by the plugin, so
> those places cannot be modified to call the is_ api to replace the
> string comparison.
>
>>> I do not think we ever have a case where we have some folder name
>>> and we want to check if is an admin directory or not.
>>>
>> I definitely hope client code doesn't do that...
>
>
> As Mark pointed out later in the thread, there is in fact client code
> that needs to do that, in order to suppress indexing/browsing/display
> of the folder in the project tree. And that's done by the Eclipse
> core, not by the Subclipse plugin, so a get_ api that returns all
> possible admin dir names is what's really needed.
Urgh, yuck. I do understand your point, it just seems messy to export
that knowledge.
> In the interim, for 1.3 release, it's probably acceptable for
> Subclipse to be modified to always register ".svn", and conditionally
> also register the return of the get_ api, if it's different from ".svn".
adm_opt_to_target_array(2?) does something similar.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Marc Sherman <ms...@projectile.ca>.
Branko Čibej wrote:
>>
> For what you describe, you _definitely_ need the _is_ version of the
> API. effetively, you want to do what libsvn_wc does; actually use either
> _svn or .svn, but treat both as special names (e.g., even if the .net
> hack is enabled, you still can't "svn mkdir .svn").
>
> Reading this discussion, I'm now really sorry I ever provided the _get_
> form.
Brane, I think you've misunderstood what happens in Subclipse. The is_
api can only replace direct string comparisons in the Subclipse code.
However, there are places where Subclipse must pass the admin dir names
in to Eclipse code, that is not controlled by the plugin, so those
places cannot be modified to call the is_ api to replace the string
comparison.
>> I do not think we ever have a case where we have some folder name and
>> we want to check if is an admin directory or not.
>>
> I definitely hope client code doesn't do that...
As Mark pointed out later in the thread, there is in fact client code
that needs to do that, in order to suppress indexing/browsing/display of
the folder in the project tree. And that's done by the Eclipse core,
not by the Subclipse plugin, so a get_ api that returns all possible
admin dir names is what's really needed.
In the interim, for 1.3 release, it's probably acceptable for Subclipse
to be modified to always register ".svn", and conditionally also
register the return of the get_ api, if it's different from ".svn".
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Branko Čibej <br...@xbc.nu>.
Mark Phippard wrote:
>Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 04:31:19 PM:
>
>
>
>>I assume you mean that the ability to digest a full path would be more
>>desirable? (This was my thinking as well.) As the JavaHL binding I
>>added simply wraps svn_wc_is_adm_dir(), a change to that library would
>>do the trick here, and sounds like a generally more comfortable API.
>>Maybe something like...?:
>>
>>
>
>I think clarification in the JavaDoc would be fine. It would not be hard
>from Java to just pass the folder name and not the path.
>
>
Yes.
>What I was really saying is that we are more likely to need and use the
>"get" method than the "is" method. For example, we need to register the
>name of this folder with Eclipse so that it ignores it on some of its
>operations, hides it in the UI etc... We also need it so that we can
>explicitly look for the folder.
>
>
For what you describe, you _definitely_ need the _is_ version of the
API. effetively, you want to do what libsvn_wc does; actually use either
_svn or .svn, but treat both as special names (e.g., even if the .net
hack is enabled, you still can't "svn mkdir .svn").
Reading this discussion, I'm now really sorry I ever provided the _get_
form.
>I do not think we ever have a case where we have some folder name and we
>want to check if is an admin directory or not.
>
>
I definitely hope client code doesn't do that...
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 04:31:19 PM:
> I assume you mean that the ability to digest a full path would be more
> desirable? (This was my thinking as well.) As the JavaHL binding I
> added simply wraps svn_wc_is_adm_dir(), a change to that library would
> do the trick here, and sounds like a generally more comfortable API.
> Maybe something like...?:
I think clarification in the JavaDoc would be fine. It would not be hard
from Java to just pass the folder name and not the path.
What I was really saying is that we are more likely to need and use the
"get" method than the "is" method. For example, we need to register the
name of this folder with Eclipse so that it ignores it on some of its
operations, hides it in the UI etc... We also need it so that we can
explicitly look for the folder.
I do not think we ever have a case where we have some folder name and we
want to check if is an admin directory or not.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Mark Phippard wrote:
...
> Does this new method take a path, like "C:\Dev\Project\.svn" or just a
> name like ".svn"?
I had the same question myself while implementing this, and modified the
svn_wc_is_adm_dir() doc string accordingly:
--- svn_wc.h (revision 16862)
+++ svn_wc.h (revision 16863)
@@ -339,7 +339,8 @@
/**
* Return @c TRUE if @a name is the name of the WC administrative
- * directory. Use @a pool for any temporary allocations.
+ * directory. Use @a pool for any temporary allocations. Only works
+ * with base directory names, not paths or URIs.
*
* For compatibility, the default name (.svn) will always be treated
* as an admin dir name, even if the working copy is actually using an
> In the cases we need this information in Subclipse, I think the other
> method will be more desirable.
I assume you mean that the ability to digest a full path would be more
desirable? (This was my thinking as well.) As the JavaHL binding I
added simply wraps svn_wc_is_adm_dir(), a change to that library would
do the trick here, and sounds like a generally more comfortable API.
Maybe something like...?:
--- adm_files.c (revision 16865)
+++ adm_files.c (working copy)
@@ -57,7 +57,7 @@
svn_boolean_t
svn_wc_is_adm_dir (const char *name, apr_pool_t *pool)
{
- (void)pool; /* Silence compiler warnings about unused parameter. */
+ name = svn_path_basename (name, pool);
return (0 == strcmp (name, adm_dir_name)
|| 0 == strcmp (name, default_adm_dir_name));
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/20/2005 04:05:35 PM:
> On Thu, 20 Oct 2005, Daniel Rall wrote:
>
> > On Thu, 20 Oct 2005, Branko Čibej wrote:
> > > Daniel Rall wrote:
> ...
> > > >So exposing svn_wc_get_adm_dir() would be sufficient?
> > >
> > > No, it wouldn't be sufficient. You nead at least svn_wc_is_adm_dir,
> > > which is more relevant for hiding stuff.
> >
> > Brane, you suggest this because svn_wc_is_adm_dir() checks not only
the
> > current admin dir, but also the default. I agree; can someone else
put
> > together a patch along the lines of r16854?
>
> Ah well, I fell for it and made the change myself (r16864). I'm
proposing
> both for backport, so some confirmation from a Windows developer would
be
> great (nudge :).
Does this new method take a path, like "C:\Dev\Project\.svn" or just a
name like ".svn"?
In the cases we need this information in Subclipse, I think the other
method will be more desirable.
Thanks
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Daniel Rall wrote:
> On Thu, 20 Oct 2005, Branko Čibej wrote:
> > Daniel Rall wrote:
...
> > >So exposing svn_wc_get_adm_dir() would be sufficient?
> >
> > No, it wouldn't be sufficient. You nead at least svn_wc_is_adm_dir,
> > which is more relevant for hiding stuff.
>
> Brane, you suggest this because svn_wc_is_adm_dir() checks not only the
> current admin dir, but also the default. I agree; can someone else put
> together a patch along the lines of r16854?
Ah well, I fell for it and made the change myself (r16864). I'm proposing
both for backport, so some confirmation from a Windows developer would be
great (nudge :).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Thu, 20 Oct 2005, Branko Čibej wrote:
> Daniel Rall wrote:
> >On Wed, 19 Oct 2005, Marc Sherman wrote:
...
> >>Subclipse does a bunch of things with the admin dirs, such as hiding
> >>them from display in the project browsers and not indexing code in the
> >>textbase dirs within them. It currently does this with a hardcoded
> >>constant string defined as ".svn", which I had to hack to "_svn" in a
> >>local build similar to the change in the svn C code. I'd assumed that
> >>Subclipse would want to call the subversion APIs to replace comparisons
> >>with the constant, but if Mark's happy replicating the logic of those
> >>APIs in Subclipse code instead, using the env var directly, then I guess
> >>it's not needed.
> >
> >So exposing svn_wc_get_adm_dir() would be sufficient?
>
> No, it wouldn't be sufficient. You nead at least svn_wc_is_adm_dir,
> which is more relevant for hiding stuff.
Brane, you suggest this because svn_wc_is_adm_dir() checks not only the
current admin dir, but also the default. I agree; can someone else put
together a patch along the lines of r16854?
svn_boolean_t
svn_wc_is_adm_dir (const char *name, apr_pool_t *pool)
{
(void)pool; /* Silence compiler warnings about unused parameter. */
return (0 == strcmp (name, adm_dir_name)
|| 0 == strcmp (name, default_adm_dir_name));
}
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Rall wrote:
>On Wed, 19 Oct 2005, Marc Sherman wrote:
>
>
>
>>Daniel Rall wrote:
>>
>>
>>>Marc, what's the use case for pushing those APIs out to the language
>>>bindings? In the JavaHL case, we generally don't tend to offer quite that
>>>low-level an API.
>>>
>>>
>>Subclipse does a bunch of things with the admin dirs, such as hiding
>>them from display in the project browsers and not indexing code in the
>>textbase dirs within them. It currently does this with a hardcoded
>>constant string defined as ".svn", which I had to hack to "_svn" in a
>>local build similar to the change in the svn C code. I'd assumed that
>>Subclipse would want to call the subversion APIs to replace comparisons
>>with the constant, but if Mark's happy replicating the logic of those
>>APIs in Subclipse code instead, using the env var directly, then I guess
>>it's not needed.
>>
>>
>
>So exposing svn_wc_get_adm_dir() would be sufficient?
>
>
No, it wouldn't be sufficient. You nead at least svn_wc_is_adm_dir,
which is more relevant for hiding stuff.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Daniel Rall <dl...@finemaltcoding.com> wrote on 10/19/2005 07:52:00 PM:
> So exposing svn_wc_get_adm_dir() would be sufficient?
It wouldn't hurt to have these API's exposed in JavaHL, but it does not
need to hold up 1.3. Like I said, I have already written the code for
this in Subclipse to use the environment variables. Because of the way
Subclipse works, I am not sure it could use this method anyway. I would
have to take a look. I seem to remember that the code point that
retrieved the directory name did not know which of our "adapters" to call,
so it had to be a generic solution.
The "get" API is probably the only one we would need.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Wed, 19 Oct 2005, Marc Sherman wrote:
> Daniel Rall wrote:
> >
> >Marc, what's the use case for pushing those APIs out to the language
> >bindings? In the JavaHL case, we generally don't tend to offer quite that
> >low-level an API.
>
> Subclipse does a bunch of things with the admin dirs, such as hiding
> them from display in the project browsers and not indexing code in the
> textbase dirs within them. It currently does this with a hardcoded
> constant string defined as ".svn", which I had to hack to "_svn" in a
> local build similar to the change in the svn C code. I'd assumed that
> Subclipse would want to call the subversion APIs to replace comparisons
> with the constant, but if Mark's happy replicating the logic of those
> APIs in Subclipse code instead, using the env var directly, then I guess
> it's not needed.
So exposing svn_wc_get_adm_dir() would be sufficient?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Marc Sherman <ms...@projectile.ca>.
Daniel Rall wrote:
>
> Marc, what's the use case for pushing those APIs out to the language
> bindings? In the JavaHL case, we generally don't tend to offer quite that
> low-level an API.
Subclipse does a bunch of things with the admin dirs, such as hiding
them from display in the project browsers and not indexing code in the
textbase dirs within them. It currently does this with a hardcoded
constant string defined as ".svn", which I had to hack to "_svn" in a
local build similar to the change in the svn C code. I'd assumed that
Subclipse would want to call the subversion APIs to replace comparisons
with the constant, but if Mark's happy replicating the logic of those
APIs in Subclipse code instead, using the env var directly, then I guess
it's not needed.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Daniel Rall <dl...@finemaltcoding.com>.
On Wed, 19 Oct 2005, Mark Phippard wrote:
> Marc Sherman <ms...@projectile.ca> wrote on 10/19/2005 01:29:07 PM:
>
> > Philip Martin wrote:
> > >
> > > I don't do Java at all. However JNIUtil::JNIInit(JNIEnv *env) appears
> > > to be the only place that calls apr_initialize, so here's a completely
> > > untested patch (I haven't even compiled it):
> >
> > That's not the only thing that needs to be done -- the new
> > svn_wc_get_adm_dir and svn_wc_is_adm_dir apis need to be pushed out to
> > the JNI interface, so that java clients can call them.
>
> FWIW, we do not need these in Subclipse. It is just as easy to check the
> environment variable.
Marc, what's the use case for pushing those APIs out to the language
bindings? In the JavaHL case, we generally don't tend to offer quite that
low-level an API.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Marc Sherman <ms...@projectile.ca> wrote on 10/19/2005 01:29:07 PM:
> Philip Martin wrote:
> >
> > I don't do Java at all. However JNIUtil::JNIInit(JNIEnv *env) appears
> > to be the only place that calls apr_initialize, so here's a completely
> > untested patch (I haven't even compiled it):
>
> That's not the only thing that needs to be done -- the new
> svn_wc_get_adm_dir and svn_wc_is_adm_dir apis need to be pushed out to
> the JNI interface, so that java clients can call them.
FWIW, we do not need these in Subclipse. It is just as easy to check the
environment variable.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Marc Sherman <ms...@projectile.ca>.
Philip Martin wrote:
>
> I don't do Java at all. However JNIUtil::JNIInit(JNIEnv *env) appears
> to be the only place that calls apr_initialize, so here's a completely
> untested patch (I haven't even compiled it):
That's not the only thing that needs to be done -- the new
svn_wc_get_adm_dir and svn_wc_is_adm_dir apis need to be pushed out to
the JNI interface, so that java clients can call them.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Philip Martin <ph...@codematters.co.uk> wrote on 10/19/2005 01:25:18 PM:
> Mark Phippard <ma...@softlanding.com> writes:
>
> > David Anderson <da...@calixo.net> wrote on 10/19/2005
12:15:43
> > PM:
> >
> >> The one which remains now, is the support of the ASP_DOT_NET_HACK in
the
> >> JavaHL bindings. It seems that I can't find a JavaHL developer to do
> >> this so that we can go ahead and cut the RC.
> >>
> > Other than that the code is written in C++ I do not think there is
> > anything overly difficult about maintaining the JavaHL bindings. I
> > imagine that most Subversion developers could handle making small
changes.
> > I do not even really know C and I have been able to make small
changes.
> > In this case, the function has to be called at initialization and
looking
> > at the code it is not completely obvious to me where you would do
this. So
> > I did not attempt it.
>
> I don't do Java at all. However JNIUtil::JNIInit(JNIEnv *env) appears
> to be the only place that calls apr_initialize, so here's a completely
> untested patch (I haven't even compiled it):
>
That is what I was looking for. Thanks. Your code looks about like what
I was going to hack together. I do not know if JavaHL does anything
special to handle errors, but otherwise, I bet that code is all that is
needed for this.
Maybe Daniel Rall can test it?
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
Philip Martin <ph...@codematters.co.uk> wrote on 10/19/2005 01:25:18 PM:
> Index: java/javahl/native/JNIUtil.cpp
> ===================================================================
> --- java/javahl/native/JNIUtil.cpp (revision 16820)
> +++ java/javahl/native/JNIUtil.cpp (working copy)
> @@ -28,6 +28,7 @@
>
> #include "svn_pools.h"
> #include "svn_config.h"
> +#include "svn_wc.h"
> #include "svn_path.h"
> #include <apr_file_info.h>
> #include "svn_private_config.h"
> @@ -177,6 +178,20 @@
> unsigned int inwords, outbytes, outlength;
>
> apr_pool_create (&pool, 0);
> + if (getenv ("SVN_ASP_DOT_NET_HACK"))
> + {
> + svn_error_t *err = svn_wc_set_adm_dir ("_svn", pool);
> + if (err)
> + {
> + svn_error_clear(err);
> + if (stderr)
> + fprintf(stderr,
> + "%s: error: SVN_ASP_DOT_NET_HACK failed\n",
> + "svnjavahl");
> + return FALSE;
> + }
> + }
> +
> /* get dll name - our locale info will be in '../share/locale'
*/
> inwords = sizeof (ucs2_path) / sizeof(ucs2_path[0]);
> HINSTANCE moduleHandle = GetModuleHandle("libsvnjavahl-1");
One more thing. Isn't this supposed to be conditioned on WIN32 and CYGWIN
only?
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Philip Martin <ph...@codematters.co.uk>.
Mark Phippard <ma...@softlanding.com> writes:
> David Anderson <da...@calixo.net> wrote on 10/19/2005 12:15:43
> PM:
>
>> The one which remains now, is the support of the ASP_DOT_NET_HACK in the
>> JavaHL bindings. It seems that I can't find a JavaHL developer to do
>> this so that we can go ahead and cut the RC.
>>
> Other than that the code is written in C++ I do not think there is
> anything overly difficult about maintaining the JavaHL bindings. I
> imagine that most Subversion developers could handle making small changes.
> I do not even really know C and I have been able to make small changes.
> In this case, the function has to be called at initialization and looking
> at the code it is not completely obvious to me where you would do this. So
> I did not attempt it.
I don't do Java at all. However JNIUtil::JNIInit(JNIEnv *env) appears
to be the only place that calls apr_initialize, so here's a completely
untested patch (I haven't even compiled it):
Index: java/javahl/native/JNIUtil.cpp
===================================================================
--- java/javahl/native/JNIUtil.cpp (revision 16820)
+++ java/javahl/native/JNIUtil.cpp (working copy)
@@ -28,6 +28,7 @@
#include "svn_pools.h"
#include "svn_config.h"
+#include "svn_wc.h"
#include "svn_path.h"
#include <apr_file_info.h>
#include "svn_private_config.h"
@@ -177,6 +178,20 @@
unsigned int inwords, outbytes, outlength;
apr_pool_create (&pool, 0);
+ if (getenv ("SVN_ASP_DOT_NET_HACK"))
+ {
+ svn_error_t *err = svn_wc_set_adm_dir ("_svn", pool);
+ if (err)
+ {
+ svn_error_clear(err);
+ if (stderr)
+ fprintf(stderr,
+ "%s: error: SVN_ASP_DOT_NET_HACK failed\n",
+ "svnjavahl");
+ return FALSE;
+ }
+ }
+
/* get dll name - our locale info will be in '../share/locale' */
inwords = sizeof (ucs2_path) / sizeof(ucs2_path[0]);
HINSTANCE moduleHandle = GetModuleHandle("libsvnjavahl-1");
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Seeking JavaHL developers for RC
Posted by Mark Phippard <ma...@softlanding.com>.
David Anderson <da...@calixo.net> wrote on 10/19/2005 12:15:43
PM:
> So, blockers that prevent rolling 1.3.0 RC1 are quickly disappearing.
> The one which remains now, is the support of the ASP_DOT_NET_HACK in the
> JavaHL bindings. It seems that I can't find a JavaHL developer to do
> this so that we can go ahead and cut the RC.
>
> Which brings about a worrying question: are the JavaHL bindings still
> being maintained? If so, this needs to be addressed fast, or at least
> someone needs to give feedback on the list. Right now I have complete
> radio silence about JavaHL, which to me indicates that a release will
> have to be cut without the mods to JavaHL, which sucks.
Unfortunately I am a Java developer so I cannot help on this. Given that
I develop Subclipse I obviously follow JavaHL very closely. I would say
that is still being actively maintained but there have always only been a
handful of people that work on it. The primary committer has typically
been Patrick Mayweg and I have not seen him around much in the last 6
months. He did shoot me an email soon after Brane originally checked in
this feature that said he planned on adding this to JavaHL "in a week".
Obviously, that never happened.
Daniel Rall has been doing some work on JavaHL. I had expected him to
reply to these emails and ideally add this feature. Perhaps he has been
busy, perhaps he has missed these messages, perhaps it is in an area of
code he doesn't quite understand?
Other than that the code is written in C++ I do not think there is
anything overly difficult about maintaining the JavaHL bindings. I
imagine that most Subversion developers could handle making small changes.
I do not even really know C and I have been able to make small changes.
In this case, the function has to be called at initialization and looking
at the code it is not completely obvious to me where you would do this. So
I did not attempt it.
I believe that David James has contributed to these bindings in the past
as well, but it may have been more in the build system.
Anyway, this hasn't been much help, I just wanted to let you know that the
bindings are very much needed, and I do not think they are dead or
anything.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org