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