You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Alexander Mueller <al...@littleblue.de> on 2001/07/12 18:18:08 UTC
Java Library
Hi folks,
right now I am working on a first scratch for the Java library. Didnt understand all of the concepts
yet (for example: Reporter, Baton) but I am working on it.
One can be said already: the java binding is not so simple like I hoped it would be. I want to hide
a lot of the apr stuff from public and give the class user just what he/she needs in a java environment....
What I would appreciate to do is to check all of my work onto a area visible to public so
others can comment my stuff, join in, and so on.
What shall I do? Will you create a login for me for the cvs? What to include in the java
files (Copyright notices and so on)? Where to put them...
Would be great to get things running FAST...
---
Thanks
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by Karl Fogel <kf...@collab.net>.
cmpilato@collab.net writes:
> Alexander Mueller <al...@littleblue.de> writes:
>
> > What I would appreciate to do is to check all of my work onto a area
> > visible to public so others can comment my stuff, join in, and so
> > on.
> >
> > What shall I do? Will you create a login for me for the cvs? What to
> > include in the java files (Copyright notices and so on)? Where to
> > put them...
> >
> > Would be great to get things running FAST...
This is wonderful! Couldn't agree more with your final sentence,
too... :-)
To add to Mike's response:
You might want to update your copy of the HACKING file at the top
level of the tree. I just committed some new text there that explains
the commit access procedure more clearly.
Hope we'll see those patches soon!
-Karl
Mike Pilato <cm...@collab.net> wrote:
> Alexander, I think I speak for all the Subversion developers when I
> say that I look forward to seeing some progress made on the GUI front.
> Thank you so much for stepping forward with excitement on this.
>
> I do think, however, that work like this should still follow the
> general policies existing in this community regarding code submission.
> If you don't already have a CVS login, your work should come in as
> patches sent to this developers list. I realize that this might seem
> like an annoyance, especially if you are planning on a codebase of any
> notable size, but I think you'll find it to be quite the useful
> policy in the long run.
>
> I will commit (hmm...loaded word...dedicate myself?) to reviewing the
> patches you submit as soon as I can -- immediately upon receipt so
> long as some mission-critical Subversion task isn't consuming my
> cycles -- and encourage others on the list to do the same. I'm pretty
> confident that this way we can ensure that Subversion is getting only
> the best code there is to offer.
>
> Looking forward to seeing some mo' Java in the codebase,
>
> Mike
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by cm...@collab.net.
Alexander Mueller <al...@littleblue.de> writes:
> What I would appreciate to do is to check all of my work onto a area
> visible to public so others can comment my stuff, join in, and so
> on.
>
> What shall I do? Will you create a login for me for the cvs? What to
> include in the java files (Copyright notices and so on)? Where to
> put them...
>
> Would be great to get things running FAST...
Alexander, I think I speak for all the Subversion developers when I
say that I look forward to seeing some progress made on the GUI front.
Thank you so much for stepping forward with excitement on this.
I do think, however, that work like this should still follow the
general policies existing in this community regarding code submission.
If you don't already have a CVS login, your work should come in as
patches sent to this developers list. I realize that this might seem
like an annoyance, especially if you are planning on a codebase of any
notable size, but I think you'll find it to be quite the useful
policy in the long run.
I will commit (hmm...loaded word...dedicate myself?) to reviewing the
patches you submit as soon as I can -- immediately upon receipt so
long as some mission-critical Subversion task isn't consuming my
cycles -- and encourage others on the list to do the same. I'm pretty
confident that this way we can ensure that Subversion is getting only
the best code there is to offer.
Looking forward to seeing some mo' Java in the codebase,
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Libraries: Dumbo Question about svn_client.h
Posted by Alexander Müller <Xe...@web.de>.
>
> (Hope you don't mind my keeping this on the public list... others may
> learn from this discussion.)
(Nope thats very fine with me, as long as people keep answering my
nag-questions....)
>
> Alexander Mueller <al...@littleblue.de> writes:
>
> [...]
> >
> > This is all fine with me, but I found code like:
> >
> > file trace-update.c
> > ----> snip
> > static svn_error_t *
> > replace_directory (svn_stringbuf_t *name,
> > void *parent_baton,
> > svn_revnum_t base_revision,
> > void **child_baton)
> > {
> > struct dir_baton *parent_d = parent_baton;
> > struct dir_baton *child_d
> > = apr_pcalloc (parent_d->edit_baton->pool, sizeof (*child_d));
> >
> > child_d->edit_baton = parent_d->edit_baton;
> > child_d->parent_dir_baton = parent_d;
> > child_d->path = svn_stringbuf_dup (parent_d->path, child_d->edit_baton->pool);
> > svn_path_add_component (child_d->path, name, svn_path_local_style);
> >
> > *child_baton = child_d;
> >
> > /* Don't print anything for a directory replace -- this event is
> > implied by printing events beneath it. */
> >
> > return SVN_NO_ERROR;
> > }
> > <---- snap
> >
> > Ok. If all of this action is optional (not necessary for function).
> > Why is it used, then?
>
> This is part of a very specific "after" editor that exists in the
> command-line client code. It is passed to svn_client_update(). This
> way, whenever the command-line client receives a patch to a file, it
> can print a "U" to stdout, and so on.
>
> But does a GUI client want to do this? Probably not. Maybe you want
> little animated bullets to appear next to a tree diagram. Maybe you
> want to append text to an update-window. Either way, you'll want to
> write your own "after" editor to graphically indicate the status of an
> update-in-progress.
Ok. So finally I think I've got it. Will be pretty helpful for the
future
when implementing the model-view-controller layer of the library...
>
> > > The svn_cl__* code is the command-line client. You should definitely
> > > look at it as an example of "how to use svn_client.h"... but you
> > > shouldn't write JNI wrappers around them! Wrap svn_client.h and the
> > > headers it immediately depends on.
> >
> > I am unsure if there is essential code implemented in snv_cl_.
> > You know, can I use the svn_client.h API without duplication logic thats
> > include in the command line code? If there is redundant code maybe I should
> > use the functions that implement this functionality.
>
> There shouldn't be any "essential" code in svn_cl__*. We've tried
> very hard to draw a distinct line between routines that *all* clients
> need and ones that are absolutely specific to a the needs of a
> command-line client.
>
> So if you find any code in subversion/client/cmdline/ that you suspect
> everybody will need, please let us know. It would be a bug in our
> design! :-)
Ok. Fine.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Libraries: Dumbo Question about svn_client.h
Posted by Ben Collins-Sussman <su...@collab.net>.
(Hope you don't mind my keeping this on the public list... others may
learn from this discussion.)
Alexander Mueller <al...@littleblue.de> writes:
[...]
>
> This is all fine with me, but I found code like:
>
> file trace-update.c
> ----> snip
> static svn_error_t *
> replace_directory (svn_stringbuf_t *name,
> void *parent_baton,
> svn_revnum_t base_revision,
> void **child_baton)
> {
> struct dir_baton *parent_d = parent_baton;
> struct dir_baton *child_d
> = apr_pcalloc (parent_d->edit_baton->pool, sizeof (*child_d));
>
> child_d->edit_baton = parent_d->edit_baton;
> child_d->parent_dir_baton = parent_d;
> child_d->path = svn_stringbuf_dup (parent_d->path, child_d->edit_baton->pool);
> svn_path_add_component (child_d->path, name, svn_path_local_style);
>
> *child_baton = child_d;
>
> /* Don't print anything for a directory replace -- this event is
> implied by printing events beneath it. */
>
> return SVN_NO_ERROR;
> }
> <---- snap
>
> Ok. If all of this action is optional (not necessary for function).
> Why is it used, then?
This is part of a very specific "after" editor that exists in the
command-line client code. It is passed to svn_client_update(). This
way, whenever the command-line client receives a patch to a file, it
can print a "U" to stdout, and so on.
But does a GUI client want to do this? Probably not. Maybe you want
little animated bullets to appear next to a tree diagram. Maybe you
want to append text to an update-window. Either way, you'll want to
write your own "after" editor to graphically indicate the status of an
update-in-progress.
> > The svn_cl__* code is the command-line client. You should definitely
> > look at it as an example of "how to use svn_client.h"... but you
> > shouldn't write JNI wrappers around them! Wrap svn_client.h and the
> > headers it immediately depends on.
>
> I am unsure if there is essential code implemented in snv_cl_.
> You know, can I use the svn_client.h API without duplication logic thats
> include in the command line code? If there is redundant code maybe I should
> use the functions that implement this functionality.
There shouldn't be any "essential" code in svn_cl__*. We've tried
very hard to draw a distinct line between routines that *all* clients
need and ones that are absolutely specific to a the needs of a
command-line client.
So if you find any code in subversion/client/cmdline/ that you suspect
everybody will need, please let us know. It would be a bug in our
design! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Libraries: Dumbo Question about svn_client.h
Posted by Ben Collins-Sussman <su...@collab.net>.
Alexander Mueller <al...@littleblue.de> writes:
> Right now I am working on the interface definitions for the Java Lib
> Classes. First I thought implementing classes and methods that
> would fit the "svn_client.h" and the "svn_wc.h" function definitions
> would be enough. It would suffice, if there weren't the "editor"
> parameters in the "svn_commit" and "svn_update" functions.
Do you understand `editors' now, having read svn_delta_edit_fns_t in
svn_delta.h? I don't mean to sound condescending; I'm just trying to
figure out how much you've learned so far.
The `editor' arguments in svn_client_*() are all optional. They're
defined as "before" and "after" editors... which means their routines
will be called before and after editor-events take place. (We should
update the doc strings to say that they're optional!)
For example, look at svn_client_checkout(). If you call it like
svn_client_checkout (NULL, NULL, NULL, NULL,
"file:///home/foo/repo/barproject",
"working_copy_dir",
SVN_INVALID_REVNUM, 0, NULL, pool)
Then you will end up with a working copy in a directory called
"working_copy_dir", which contains the latest version of the
'barproject' directory from the 'file:///home/foo/repo' repository.
(Note that the const char * arguments above actually need to be
created with svn_stringbuf_create()).
Now, suppose you have a GUI client. Every time a new file is added to
your working copy during a checkout, you want little yellow chickens
to dance across the screen. Or maybe you just want a graphical
status-bar indicator. So... just write your own editor, and make its
add_file() routine do these things. Then pass your editor to
svn_client_checkout as an "after" editor. Voila.... extensibility.
> Ok. What to do next? I still have to write the JNI functions. But I
> dont wan't to reimplement functionality that's already there. Can we
> shift something in between "svn_cl__update" and "svn_update"? Or
> shall I use "svn_cl__update" directly from my code?
Why do you need to use any code at all in svn_cl__* ?
The svn_cl__* code is the command-line client. You should definitely
look at it as an example of "how to use svn_client.h"... but you
shouldn't write JNI wrappers around them! Wrap svn_client.h and the
headers it immediately depends on.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Java Libraries: Dumbo Question about svn_client.h
Posted by Alexander Mueller <al...@littleblue.de>.
Hi!
I am still trying to get the picture for the client. Sorry if I ask dumb questions here. Main reason is
because I didnt find the answers I am looking for in the docs or the source tree itself.
Right now I am working on the interface definitions for the Java Lib Classes.
First I thought implementing classes and methods that would fit the "svn_client.h" and the
"svn_wc.h" function definitions would be enough. It would suffice, if there weren't the
"editor" parameters in the "svn_commit" and "svn_update" functions.
First I thought the "editor" hook is more about notifications, for example to output log messages and so on.
To get the picture I took a look at "update-cmd.c" and "trace-update.c".
But I was wrong. There is still some specific stuff going on I would have to implement myself!
Ok. What to do next? I still have to write the JNI functions. But I dont wan't to reimplement functionality that's
already there. Can we shift something in between "svn_cl__update" and "svn_update"? Or shall I use
"svn_cl__update" directly from my code?
What do you guys think?
Have fun...
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by Ben Collins-Sussman <su...@collab.net>.
Alexander Mueller <al...@littleblue.de> writes:
> right now I am working on a first scratch for the Java
> library. Didnt understand all of the concepts yet (for example:
> Reporter, Baton) but I am working on it.
We use the term "baton" in the codebase to refer to a structure full
of invisible data needed by a function. Some systems call these
closures "context" objects, and in X windows I think they're called
"userdata". We called them "batons" because they're being passed
around a lot. :)
If you or anyone else is planning on writing a new SVN client
application, the *main* API to look at is svn_client.h. This API
refers to batons and `editors' too. You can read about `editors' in
the design document, and also by looking at the svn_delta_edit_fns_t
type in svn_delta.h.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by "Mark C. Chu-Carroll" <mc...@watson.ibm.com>.
Sorry, forgot to mention in the previous message: there are Synedra
design documents available online, on our webpage:
http://domino.research.ibm.com/synedra/synedra.nsf/papers?OpenPage
The docs that are up there right now are fairly high level; I hope to
have time in the next few weeks to write up some more detailed info
about things like how we store code, and how we handle deltas (we use a
ClearCase like in-place delta mechanism). Right now, I'm neck deep in
debugging
of our branch merge code, so I haven't had time to get the detailed
design docs into a publically consumable form.
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
<mc...@watson.ibm.com>
*** The Synedra project:
http://domino.research.ibm.com/synedra/synedra.nsf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by "Mark C. Chu-Carroll" <mc...@watson.ibm.com>.
On 24 Jul 2001 10:23:24 +0200, Alexander Mueller wrote:
> Hi Mark
>
> "Mark C. Chu-Carroll" schrieb:
>
> > On 12 Jul 2001 20:18:08 +0200, Alexander Mueller wrote:
> > > Hi folks,
> > >
> > > right now I am working on a first scratch for the Java library. Didnt understand all of the concepts
> > > yet (for example: Reporter, Baton) but I am working on it.
> > >
> > > One can be said already: the java binding is not so simple like I hoped it would be. I want to hide
> > > a lot of the apr stuff from public and give the class user just what he/she needs in a java environment....
> > >
> > > What I would appreciate to do is to check all of my work onto a area visible to public so
> > > others can comment my stuff, join in, and so on.
> > >
> > > What shall I do? Will you create a login for me for the cvs? What to include in the java
> > > files (Copyright notices and so on)? Where to put them...
> > >
> > > Would be great to get things running FAST...
> >
> > I would like to at least talk with you about the design of this. I can't
> > actively contribute at the moment, but that may change shortly.
> >
> > As I mentioned back when I introduced myself to the list, I'm working on
> > a possible competitor to subversion (at the time, we called in Coven;
> > due to a name collision, we renamed in to Synedra), which is written
> > entirely in Java. We've got a lot of functionality - we're slightly
> > ahead of subversion in some places, and quite a bit behind in others
> > (particularly WebDAV/DeltaV).
>
> This sounds pretty interesting! Will Synedra be under an Open Licence like subversion or the GPL?
> Is the Synedra architecture documentation available online?
While there are still some internal politics, it looks quite likely that
we'll be releasing this fall under either the Apache license, or the
IBM Public license. (The IPL is more legalese than Apache, but
according to the lawyers, it's more bulletproof than Apache. The only
semantic difference is that IPL gives authors a little more protection
from patent suits, but it does so at the cost of making the license
unreadable to us lowly technical types. I'm pushing hard for Apache
public license.)
> > I'd like, as much as possible, to create a situation where Synedra (my
> > system) and Subversion can interact nicely with one another. We're
> > looking at clients and UIs right now, so I'm familiar with the top-level
> > issues of how to present a repository with proper branches (like
> > Subversion and Synedra, and unlike CVS) to users.
> >
> > I'm not suggesting cooperating on this just to benefit my project, but
> > because I think we can share a lot of benefit if we have a common
> > interface available. In particular, we're working on integration with
> > a variety of programming tools (one IBM specific, plus xemacs, JEdit,
> > and maybe VIM). If we can work out a common interface through a
> > combination of Java and WebDAV, then subversion can adopt our code
> > when we go open-source (probably around October).
> >
> > If you're willing to work together on this, please drop me a note, and
> > we can talk about the design.
>
> Yep. Thats fine with me. I think the subversion java/gui project has nothing to
> lose with this but a lot to gain...
Great!
> > By the way, Synedra now has a public website... It's not a great one,
> > but at least there are some nice descriptive docs there.
> > http://domino.research.ibm.com/synedra/synedra.nsf.
> >
> > -Mark
>
> Some remarks about the design:
> right now the java/subversion implementation will not be 100% Pure Java.
> Instead, there will be a JNI layer between the public availabe classes and
> interfaces and the subversion API libraries. Its not an ideal situation for me
> but the one with what we will get the fastest results. Maybe later we will be
> able to implement all of the client side in Java (which should not be a problem,
> otherwise the designers of the java/subversion library are to blame).
For subversion, JNI is clearly the right route. I'd like to see as much
as possible to start with interfaces, and make as many calls as possible
through the interface types. (That makes it easier to plug in multiple
backends later, and the performance hit shouldn't be noticable. In any
reasonable JVM, interface calls end up being optimized by the JIT, and
there's already a very singificant performance hit whenever you cross
the boundary between Java and native code with JNI - the interface
cost should be lost in the noise.)
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
<mc...@watson.ibm.com>
*** The Synedra project:
http://domino.research.ibm.com/synedra/synedra.nsf
rroll (mcc@watson.ibm.com)
IBM T.J. Watson Research Center
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by Jacob Smullyan <sm...@smullyan.org>.
On Wed, Jul 25, 2001 at 10:55:10AM -0400, Mark C. Chu-Carroll wrote:
> One of the members of my group spent some time looking at the
> WebDAV support in Slide, and concluded that it was too closely tied to
> the underlying Slide content management system.
I concluded the same, which is one reason why I wrote SkunkDAV, to provide
a more easily embeddable Java DAV library.
I've mentioned to Greg Stein and this list that writing a DeltaV library for
SkunkDAV, with optimized Subversion support, is currently on my plate (with,
alas, too many other things). I understand that at present, the DeltaV layer
may not be adequate to do everything you want, but it should be useful.
SkunkDAV currently offers very complete support for mod_dav's functionality.
SkunkDAV is GPL at the moment, but I will make its client library
module LGPL, if that makes anyone's life easier.
Eventually (that is, within the next quarter) I will be able to focus myself
on DeltaV/Subversion; if someone else has time now and wants to contribute,
I'd be delighted.
Jacob
--
Jacob Smullyan | smulloni@smullyan.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by "Mark C. Chu-Carroll" <mc...@watson.ibm.com>.
On 24 Jul 2001 08:27:18 -0700, Brian Behlendorf wrote:
> On Tue, 24 Jul 2001, Alexander Mueller wrote:
> > Some remarks about the design:
> > right now the java/subversion implementation will not be 100% Pure Java.
> > Instead, there will be a JNI layer between the public availabe classes and
> > interfaces and the subversion API libraries. Its not an ideal situation for me
> > but the one with what we will get the fastest results. Maybe later we will be
> > able to implement all of the client side in Java (which should not be a problem,
> > otherwise the designers of the java/subversion library are to blame).
>
> There's some Java WebDAV code to get you started at
>
> http://jakarta.apache.org/slide/
One of the members of my group spent some time looking at the
WebDAV support in Slide, and concluded that it was too closely tied to
the underlying Slide content management system.
If you need Java DAV server code for Apache, we've got a barebones DAV
servlet (basically a complete DAV/DeltaV version of the standard
HTTPServlet
class) which is a good base for extension. I'm reasonably sure that I
can work out a way to clear that little hunk of code for open-source
pretty quickly.
There's also a decent bare-bones DAV servlet (just DAV, no DeltaV)
under the IPL called dav4j at
http://oss.software.ibm.com/developerworks/opensource/dav4j/. It
claims to be for Websphere, but it works under the Tomcat engine
for Apache.
-Mark
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
<mc...@watson.ibm.com>
*** The Synedra project:
http://domino.research.ibm.com/synedra/synedra.nsf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by Brian Behlendorf <br...@collab.net>.
On Tue, 24 Jul 2001, Alexander Mueller wrote:
> Some remarks about the design:
> right now the java/subversion implementation will not be 100% Pure Java.
> Instead, there will be a JNI layer between the public availabe classes and
> interfaces and the subversion API libraries. Its not an ideal situation for me
> but the one with what we will get the fastest results. Maybe later we will be
> able to implement all of the client side in Java (which should not be a problem,
> otherwise the designers of the java/subversion library are to blame).
There's some Java WebDAV code to get you started at
http://jakarta.apache.org/slide/
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by Alexander Mueller <al...@littleblue.de>.
Hi Mark
"Mark C. Chu-Carroll" schrieb:
> On 12 Jul 2001 20:18:08 +0200, Alexander Mueller wrote:
> > Hi folks,
> >
> > right now I am working on a first scratch for the Java library. Didnt understand all of the concepts
> > yet (for example: Reporter, Baton) but I am working on it.
> >
> > One can be said already: the java binding is not so simple like I hoped it would be. I want to hide
> > a lot of the apr stuff from public and give the class user just what he/she needs in a java environment....
> >
> > What I would appreciate to do is to check all of my work onto a area visible to public so
> > others can comment my stuff, join in, and so on.
> >
> > What shall I do? Will you create a login for me for the cvs? What to include in the java
> > files (Copyright notices and so on)? Where to put them...
> >
> > Would be great to get things running FAST...
>
> I would like to at least talk with you about the design of this. I can't
> actively contribute at the moment, but that may change shortly.
>
> As I mentioned back when I introduced myself to the list, I'm working on
> a possible competitor to subversion (at the time, we called in Coven;
> due to a name collision, we renamed in to Synedra), which is written
> entirely in Java. We've got a lot of functionality - we're slightly
> ahead of subversion in some places, and quite a bit behind in others
> (particularly WebDAV/DeltaV).
This sounds pretty interesting! Will Synedra be under an Open Licence like subversion or the GPL?
Is the Synedra architecture documentation available online?
> I'd like, as much as possible, to create a situation where Synedra (my
> system) and Subversion can interact nicely with one another. We're
> looking at clients and UIs right now, so I'm familiar with the top-level
> issues of how to present a repository with proper branches (like
> Subversion and Synedra, and unlike CVS) to users.
>
> I'm not suggesting cooperating on this just to benefit my project, but
> because I think we can share a lot of benefit if we have a common
> interface available. In particular, we're working on integration with
> a variety of programming tools (one IBM specific, plus xemacs, JEdit,
> and maybe VIM). If we can work out a common interface through a
> combination of Java and WebDAV, then subversion can adopt our code
> when we go open-source (probably around October).
>
> If you're willing to work together on this, please drop me a note, and
> we can talk about the design.
Yep. Thats fine with me. I think the subversion java/gui project has nothing to
lose with this but a lot to gain...
>
>
> By the way, Synedra now has a public website... It's not a great one,
> but at least there are some nice descriptive docs there.
> http://domino.research.ibm.com/synedra/synedra.nsf.
>
> -Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
Some remarks about the design:
right now the java/subversion implementation will not be 100% Pure Java.
Instead, there will be a JNI layer between the public availabe classes and
interfaces and the subversion API libraries. Its not an ideal situation for me
but the one with what we will get the fastest results. Maybe later we will be
able to implement all of the client side in Java (which should not be a problem,
otherwise the designers of the java/subversion library are to blame).
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Java Library
Posted by "Mark C. Chu-Carroll" <mc...@watson.ibm.com>.
On 12 Jul 2001 20:18:08 +0200, Alexander Mueller wrote:
> Hi folks,
>
> right now I am working on a first scratch for the Java library. Didnt understand all of the concepts
> yet (for example: Reporter, Baton) but I am working on it.
>
> One can be said already: the java binding is not so simple like I hoped it would be. I want to hide
> a lot of the apr stuff from public and give the class user just what he/she needs in a java environment....
>
> What I would appreciate to do is to check all of my work onto a area visible to public so
> others can comment my stuff, join in, and so on.
>
> What shall I do? Will you create a login for me for the cvs? What to include in the java
> files (Copyright notices and so on)? Where to put them...
>
> Would be great to get things running FAST...
I would like to at least talk with you about the design of this. I can't
actively contribute at the moment, but that may change shortly.
As I mentioned back when I introduced myself to the list, I'm working on
a possible competitor to subversion (at the time, we called in Coven;
due to a name collision, we renamed in to Synedra), which is written
entirely in Java. We've got a lot of functionality - we're slightly
ahead of subversion in some places, and quite a bit behind in others
(particularly WebDAV/DeltaV).
I'd like, as much as possible, to create a situation where Synedra (my
system) and Subversion can interact nicely with one another. We're
looking at clients and UIs right now, so I'm familiar with the top-level
issues of how to present a repository with proper branches (like
Subversion and Synedra, and unlike CVS) to users.
I'm not suggesting cooperating on this just to benefit my project, but
because I think we can share a lot of benefit if we have a common
interface available. In particular, we're working on integration with
a variety of programming tools (one IBM specific, plus xemacs, JEdit,
and maybe VIM). If we can work out a common interface through a
combination of Java and WebDAV, then subversion can adopt our code
when we go open-source (probably around October).
If you're willing to work together on this, please drop me a note, and
we can talk about the design.
By the way, Synedra now has a public website... It's not a great one,
but at least there are some nice descriptive docs there.
http://domino.research.ibm.com/synedra/synedra.nsf.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org