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/16 15:09:26 UTC

Java Libraries: Dumbo Question about svn_client.h

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 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