[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] Enhancement needed in svn status -u

From: Paul Burba <PaulB_at_softlanding.com>
Date: 2005-08-17 22:26:53 CEST

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

> On Thu, 11 Aug 2005, Paul Burba wrote:
> > "Peter N. Lundblad" <peter@famlundblad.se> wrote on 08/11/2005
> > AM:
> >
> > > I don't think you need to rev the client API. You can add fields to
> > > end of svn_wc_status2_t (that's even documented!).
> > >
> > > This chage seems pretty straight forward to me. Just add the fields
> > > need, and catch the entryprops in change_file_prop and
> > 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.
> > > added paths, there must be a nearest ancestor in the WC with an URL
> > > 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
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.
> > at r13791 (Rev the svn_wc_status_t structure to svn_wc_status2_t, so
> > 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_status2, etc...but r13805 added the comment you alluded to
> >
> > * @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
> 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
> 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,
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
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
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.
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.


Paul B.

Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 17 22:33:42 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.