Sorry for the delay in getting back to this topic, I've been off *racing*
("trying not to get killed" is a more apt description) mountain bikes the
last few days.
"Peter N. Lundblad" <peter@famlundblad.se> wrote on 08/11/2005 03:48:53
PM:
> On Thu, 11 Aug 2005, Paul Burba wrote:
>
> > "Peter N. Lundblad" <peter@famlundblad.se> wrote on 08/11/2005
02:20:09
> > AM:
> >
> > > I don't think you need to rev the client API. You can add fields to
the
> > > end of svn_wc_status2_t (that's even documented!).
> > >
> > > This chage seems pretty straight forward to me. Just add the fields
you
> > > need, and catch the entryprops in change_file_prop and
change_dir_prop
> > in
> > > libsvn_wc/status.c. The URL field is a little tricky because of
> > switched
> > > entries. For entries that exist in the WC, it is readily available.
For
> > > added paths, there must be a nearest ancestor in the WC with an URL
that
> > > you can extend.
> >
> > In looking at this, I came to more or less the same conclusion, though
> > undoubtedly it took me a *bit* longer to figure it out.
> >
> I certainly could have saved you some time by posting earlier. Sorry for
> that. Hope you learned some things during your tour:-)
Thanks for the guidance Peter. Yes, I learned quite a bit sifting through
the
code, so it was a blessing in disguise. Even if you had pointed me right
to a
solution I suspect I would have had to do this anyway.
> > I'm still unsure about the need to rev svn_wc_status2_t or not.
Looking
> > at r13791 (Rev the svn_wc_status_t structure to svn_wc_status2_t, so
as
> > not to break ABI) as a roadmap for adding to svn_wc_status_t, the
> > implication is that I need to rev svn_wc_status2_t,
svn_wc_dup_status2,
> > svn_wc_status2, etc...but r13805 added the comment you alluded to
above:
> >
> > * @note Fields may be added to the end of this structure in future
> > * versions. Therefore, users shouldn't allocate structures of this
> > * type, to preserve binary compatibility.
> >
> The reason svn_wc_status_t was revved was that there was no such clause
in
> that documentation and there were public APIs consuimg such struct that
> could have been allocated by the caller. If people allocate
> svn_wc_status2_t structs themselves, then I wouldn't mind if someone
sent
> them naked to Antarctica. You can safely add fields to the end of this
> struct.
Ok, here is what I'm thinking:
* modify subversion/include/svn_wc.h
(svn_wc_status2_t): Add new members:
svn_revnum_t ood_last_cmt_rev
apr_time_t *ood_last_cmt_date
svn_node_kind_t ood_kind
const char *ood_url
const char *ood_last_cmt_author
ood = "out of date", but maybe "update" makes more sense as a prefix...
* modify subversion/libsvn_wc/status.c
(dir_baton, file_baton):
...Add new members:
svn_revnum_t ood_last_cmt_rev
apr_time_t *ood_last_cmt_date
svn_node_kind_t ood_kind
const char *ood_url
const char *ood_last_cmt_author
(assemble_status): Initialize new svn_wc_status2_t members.
(change_dir_prop): Temporarily store ood info in the directory_baton.
Set db->ood_kind to svn_node_dir, get db->ood_url using
find_dir_url, and pick up db->ood_last_cmt_author, db->ood_last_cmt_date,
and
db->ood_last_cmt_rev from the relevant properties as each is changed.
(change_file_prop): Essentially the same as change_dir_prop, except
fb->ood_kind is set to svn_node_file and fb->ood_url is obtained by
joining
find_dir_url with uri escaped fb->path.
(close_directory): Copy the new members stored in the dir_baton to the
svn_wc_status2_t *dir_status structure. This accomplishes the real goal
here: making more detailed out of date information available to callers of
svn_client_status2, particularly for new items in the repository. (See
the
start of this thread http://svn.haxx.se/dev/archive-2005-08/0257.shtml).
(close_file): Same as close_directory, except that the svn_wc_status2_t
struct is obtained via fb->dir_baton->statii hash.
I've played around a little with the preceding ideas and so far so good.
But
before I go any further I want to get some opinions on this approach.
So fire away please. If this approach sounds acceptable I will submit a
formal patch.
As always, all comments, questions, criticisms, and/or nit-picks are
greatly appreciated.
Thanks,
Paul B.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Aug 18 06:26:53 2005