You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/10/02 07:18:21 UTC
local vs url style (was: Re: poor Brane)
On Tue, Oct 02, 2001 at 02:13:37AM +0200, Branko �ibej wrote:
>...
> libsvn_wc/adm_crawler.c:report_revisions() recursively crawls the
> working copy. It keeps splicing the path and entry names together in
> svn_path_local_style, as it must, if it wants to read entries and stuff
>
> Then, if it finds an interesting file, it calls reporter->set_path
> (libsvn_ra_dav/fetch.c:reporter_set_path()), which writes that path
> straight into the REPORT body -- without changing it to URL style first.
> Oops.
>
> Now, the "obvious" solution is to convert the local paths to URLs in the
> ra_dav reporter callbacks. But I have no opinion about whether it's the
> correct solution.
I believe the correct solution is to specify that the paths that cross the
editor and reporter vtables should be in the URL style.
"Why?" you ask? Who says that the files are in the local filesystem? So why
should they be in the the local_style?
Thus, the WC should be assembling paths in the URL style for passing thru
the vtable. Given that it must assemble the paths in a relative fashion
anyhow (we certainly aren't passing abs paths thru), then it can simply
assemble them using the URL style.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: local vs url style (was: Re: poor Brane)
Posted by kf...@collab.net.
cmpilato@collab.net writes:
> Only problem I foresee is that we accept paths directly from the
> user. They type "svn ci dir/dir/dir/foo.c" or "svn ci
> dir\dir\dir\foo.c" based on the preferences for their OS. As long as
> we can internally convert those to '/'-separated paths, I don't see
> any problems. It is unacceptable to ask Windows users to use forward
> slashes, though, methinks (although I personally wouldn't mind because
> I spent 90% of my life in Unix-land).
Oh, I agree. Canonicalizing a path once at input time is okay.
(Hopefully Windows users won't mind having paths reported in error
messages and the like be in forward-slash style, though.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java svn client?
Posted by Alexander Mueller <al...@littleblue.de>.
> On Fri, Oct 05, 2001 at 02:35:00PM +0200, Alexander Mueller wrote:
> >...
> > I wanted to avoid a remake of all of the svn implementation and decided to
> > build a java layer that rests upon a native library (using JNI).
> >
> > Thought it would be faster to have such an interface up. Of course this attempt
> > lacks beauty of design (platform independence as major issue). Also it would
> > be pretty hard to have local repository access without DAV, because then
> > you had to implement really all of the details of svn.
>
> Implementing an SVN library using JNI is the only reasonable way to go.
> There is simply too much code to reimplement, if you want that Java client
> to use the same WC as the cmdline client.
>
> You could also produce a custom WC model and just use DAV to talk to the SVN
> server. That would eliminate the need for library access. But that is still
> going to be a lot of code.
I definitely do agree to all of this...
>
>
> <rant>
>
> The whole "non-portable" mindset of Java is its biggest detriment. If people
> would get away from that silly notion, then Java might actually make huge
> strides. As it is, because of the refusal to use JNI, it means that Java can
> only talk to Java, that you can't use native libraries, and because of that
> you end up rewriting every single damned program in the universe to fit
> inside the closed Java universe. It is really sad. MSFT's C# knows that
> interop is necessary, and that is going to cause some real pain to the Java
> world -- C# developers are going to see the "Java lockin" -- they'll be able
> to actually *use* existing code and get stuff done with stopping to rewrite
> everything.
In my eyes, the JNI way is a way to get things done. Of course you still
have to take care of every os you want to support with a native class.
> ....
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java svn client?
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Oct 05, 2001 at 02:35:00PM +0200, Alexander Mueller wrote:
>...
> I wanted to avoid a remake of all of the svn implementation and decided to
> build a java layer that rests upon a native library (using JNI).
>
> Thought it would be faster to have such an interface up. Of course this attempt
> lacks beauty of design (platform independence as major issue). Also it would
> be pretty hard to have local repository access without DAV, because then
> you had to implement really all of the details of svn.
Implementing an SVN library using JNI is the only reasonable way to go.
There is simply too much code to reimplement, if you want that Java client
to use the same WC as the cmdline client.
You could also produce a custom WC model and just use DAV to talk to the SVN
server. That would eliminate the need for library access. But that is still
going to be a lot of code.
<rant>
The whole "non-portable" mindset of Java is its biggest detriment. If people
would get away from that silly notion, then Java might actually make huge
strides. As it is, because of the refusal to use JNI, it means that Java can
only talk to Java, that you can't use native libraries, and because of that
you end up rewriting every single damned program in the universe to fit
inside the closed Java universe. It is really sad. MSFT's C# knows that
interop is necessary, and that is going to cause some real pain to the Java
world -- C# developers are going to see the "Java lockin" -- they'll be able
to actually *use* existing code and get stuff done with stopping to rewrite
everything.
</rant>
Note that we also have the start of some SWIG stuff in the repository. SWIG
is supposed to be able to generate Java bindings. That could be a huge
bootstrap to the problem. Normally, I would recommend using SWIG to do some
bare-bones wrapping of the libraryes, then implement some "convenience" or
"pretty-it-up" classes/functions on top of the bare stuff.
The nice thing about the SWIG basis is that it can automatically keep up and
track changes to the SVN APIs without needing to go and change all of the
custom-written bindings.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java svn client?
Posted by Alexander Mueller <al...@littleblue.de>.
Hi,
beginning about two months ago I started to work on a java svn library with the
intention to have a java svn GUI up and running soon....
Development got pretty slow on my side over the last weeks due lack of spare time...
I wanted to avoid a remake of all of the svn implementation and decided to
build a java layer that rests upon a native library (using JNI).
Thought it would be faster to have such an interface up. Of course this attempt
lacks beauty of design (platform independence as major issue). Also it would
be pretty hard to have local repository access without DAV, because then
you had to implement really all of the details of svn.
But of course I am very interested to hear about every idea other people have
about how to do this...
--
Sincerely
Alexander Mueller
=========================================================
ingenieurbuero Alexander Mueller & Egon Maurer
leibnizstrasse 20
88250 weingarten
telefon: 0751/55 777 65
telefax: 0751/55 777 67
email: alexander.mueller@littleblue.de
web: www.littleblue.de
Murray Altheim schrieb:
> Daniel Stenberg wrote:
> >
> > On Fri, 5 Oct 2001, Murray Altheim wrote:
> >
> > > I'd be most grateful if someone could point me to some existing Java
> > > source that had some basic client-server add/modify/delete functionality.
> >
> > Searching the mailing list archive is a very good start:
> > http://subversion.tigris.org/servlets/SearchList?listName=dev
> >
> > This made me find Jacob Smullyan's posted intentions to write a Java client
> > library back in July:
> > http://subversion.tigris.org/servlets/ReadMsg?msgId=31151&listName=dev
>
> Ah, yes -- I'd actually seen that same message when I did a Web search,
> which unfortunately on "subversion java client" revealed no mention of
> any other projects, hence my message into this list. The one thing that
> does show up is SkunkDAV* (coincidentally or not also by Jacob Smullyan),
> which I'm currently investigating. Not quite so simple as a Java client
> for svn, but nevertheless very interesting in its own right.
>
> Thanks much,
>
> Murray
>
> * http://skunkdav.sourceforge.net/
> ...........................................................................
> Murray Altheim <mailto:murray.altheim@sun.com>
> XML Technology Center
> Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
>
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut. -- Minamoto no Tsunenobu
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java svn client?
Posted by Murray Altheim <mu...@sun.com>.
Daniel Stenberg wrote:
>
> On Fri, 5 Oct 2001, Murray Altheim wrote:
>
> > I'd be most grateful if someone could point me to some existing Java
> > source that had some basic client-server add/modify/delete functionality.
>
> Searching the mailing list archive is a very good start:
> http://subversion.tigris.org/servlets/SearchList?listName=dev
>
> This made me find Jacob Smullyan's posted intentions to write a Java client
> library back in July:
> http://subversion.tigris.org/servlets/ReadMsg?msgId=31151&listName=dev
Ah, yes -- I'd actually seen that same message when I did a Web search,
which unfortunately on "subversion java client" revealed no mention of
any other projects, hence my message into this list. The one thing that
does show up is SkunkDAV* (coincidentally or not also by Jacob Smullyan),
which I'm currently investigating. Not quite so simple as a Java client
for svn, but nevertheless very interesting in its own right.
Thanks much,
Murray
* http://skunkdav.sourceforge.net/
...........................................................................
Murray Altheim <mailto:murray.altheim@sun.com>
XML Technology Center
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java svn client?
Posted by Daniel Stenberg <da...@haxx.se>.
On Fri, 5 Oct 2001, Murray Altheim wrote:
> I'd be most grateful if someone could point me to some existing Java
> source that had some basic client-server add/modify/delete functionality.
Searching the mailing list archive is a very good start:
http://subversion.tigris.org/servlets/SearchList?listName=dev
This made me find Jacob Smullyan's posted intentions to write a Java client
library back in July:
http://subversion.tigris.org/servlets/ReadMsg?msgId=31151&listName=dev
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Java svn client?
Posted by Murray Altheim <mu...@sun.com>.
[perhaps an appropriate subject heading this time... needed coffee.]
Pardon a question from a recent list subscriber:
I just downloaded and installed subversion and have been unable to
locate the basis of a Java client. Having some familiarity with
dbXML I'm trying to replicate some of its functionality (ie., the
ability to write XML nodes or documents) using subversion. I'd
be most grateful if someone could point me to some existing Java
source that had some basic client-server add/modify/delete
functionality.
Thanks very much!
Murray
...........................................................................
Murray Altheim <mailto:murray.altheim@sun.com>
XML Technology Center
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: local vs url style (was: Re: poor Brane)
Posted by Murray Altheim <mu...@sun.com>.
Pardon a question from a recent list subscriber:
I just downloaded and installed subversion and have been unable to
locate the basis of a Java client. Having some familiarity with
dbXML I'm trying to replicate some of its functionality (ie., the
ability to write XML nodes or documents) using subversion. I'd
be most grateful if someone could point me to some existing Java
source that had some basic client-server add/modify/delete
functionality.
Thanks very much!
Murray
...........................................................................
Murray Altheim <mailto:murray.altheim@sun.com>
XML Technology Center
Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: local vs url style (was: Re: poor Brane)
Posted by cm...@collab.net.
kfogel@collab.net writes:
> (Something tells me we've talked about this before, though; was there
> an objections to just using / everywhere?)
Only problem I foresee is that we accept paths directly from the
user. They type "svn ci dir/dir/dir/foo.c" or "svn ci
dir\dir\dir\foo.c" based on the preferences for their OS. As long as
we can internally convert those to '/'-separated paths, I don't see
any problems. It is unacceptable to ask Windows users to use forward
slashes, though, methinks (although I personally wouldn't mind because
I spent 90% of my life in Unix-land).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: local vs url style (was: Re: poor Brane)
Posted by kf...@collab.net.
Branko =?ISO-8859-2?Q?=C8ibej?= <br...@xbc.nu> writes:
> >I'm sort of wondering about the whole path styles thing, actually.
> >APR says "/" works on any system, as long as one uses the APR library
> >calls (which we always do). The URL style is also "/". Therefore,
> >maybe we should just use "/" and get rid of all the style params?
> >
> Unfortunately, that doesn't always work, although you might argue that
> this is APR's problem. Perhaps we should invest some time into fixing
> this in APR. Im thinking the whole (local-style) path munging module
> should be in APR, since it's a portability tool.
That makes sense; if you'd like to take this on, that would be
groovy. But there are other important things to work on too, and it's
not so hard to just fix the occasional path bug that comes up.
So in summary, let me just say that I have nothing to add.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: local vs url style (was: Re: poor Brane)
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>Greg Stein <gs...@lyra.org> writes:
>
>>I believe the correct solution is to specify that the paths that cross the
>>editor and reporter vtables should be in the URL style.
>>
>>"Why?" you ask? Who says that the files are in the local filesystem? So why
>>should they be in the the local_style?
>>
Totally agree here.
>>Thus, the WC should be assembling paths in the URL style for passing thru
>>the vtable. Given that it must assemble the paths in a relative fashion
>>anyhow (we certainly aren't passing abs paths thru), then it can simply
>>assemble them using the URL style.
>>
>
>I'm sort of wondering about the whole path styles thing, actually.
>APR says "/" works on any system, as long as one uses the APR library
>calls (which we always do). The URL style is also "/". Therefore,
>maybe we should just use "/" and get rid of all the style params?
>
Unfortunately, that doesn't always work, although you might argue that
this is APR's problem. Perhaps we should invest some time into fixing
this in APR. Im thinking the whole (local-style) path munging module
should be in APR, since it's a portability tool.
--
Brane �ibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: local vs url style (was: Re: poor Brane)
Posted by kf...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> I believe the correct solution is to specify that the paths that cross the
> editor and reporter vtables should be in the URL style.
>
> "Why?" you ask? Who says that the files are in the local filesystem? So why
> should they be in the the local_style?
>
> Thus, the WC should be assembling paths in the URL style for passing thru
> the vtable. Given that it must assemble the paths in a relative fashion
> anyhow (we certainly aren't passing abs paths thru), then it can simply
> assemble them using the URL style.
I'm sort of wondering about the whole path styles thing, actually.
APR says "/" works on any system, as long as one uses the APR library
calls (which we always do). The URL style is also "/". Therefore,
maybe we should just use "/" and get rid of all the style params?
(Something tells me we've talked about this before, though; was there
an objections to just using / everywhere?)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org