Opened 12 years ago

Closed 9 years ago

#74 closed task (fixed)

Redesign SVN related classes

Reported by: jari Owned by: jari
Priority: minor Milestone: svndigest 0.7
Component: core Version: trunk
Keywords: Cc:

Description


Change History (8)

comment:1 follow-up: Changed 11 years ago by jari

Among things to fix are (in SVNlog):

// The return type should be svn_log_message_receiver_t but I
// cannot get it to compile. The svn API has a typedef like
// typedef svn_error_t*(* svn_log_message_receiver_t)(void *baton,
// apr_hash_t *changed_paths, svn_revnum_t revision, const char
// *author, const char *date,const char *message, apr_pool_t
// *pool) for svn_log_message_receiver_t.
static svn_error_t*
log_message_receiver(void *baton, apr_hash_t *changed_paths,
svn_revnum_t rev, const char *author, const char *date,
const char *msg, apr_pool_t *pool);

and the similar in SVNinfo:

// The return type should be svn_log_message_receiver_t but I
// cannot get it to compile (see comment for log_message_receiver
// in SVNlog.h)
static svn_error_t*
info_receiver(void *baton, const char *path, const svn_info_t *info,
apr_pool_t *pool);

comment:2 Changed 11 years ago by jari

(In [318]) Fixes #167 and addresses #74. Interfaces have changed. SVN::instance usage has changed, read SVN class documentation.

comment:3 Changed 10 years ago by peter

I think we should change the underlying data structure in SVNlog from std::vector<Commitment> to a std::set<Commitment> or possibly std::map<svn_rev_t, Commitment>. This would speed up operator+= significantly since we then can use std::set_merge algos. AFAICU there is no reason to keep the data in vectors as the index has no meaning anyway so the random access is a waste and fast insertion would be more useful.

comment:4 Changed 10 years ago by peter

(In [756]) refs #74 - using stl rather than home brewed in SVNlog::operator+=

comment:5 Changed 10 years ago by peter

(In [759]) Change container in SVNlog to be std::set<Commitment>, in order to avoid copying in SVNlog::operator+=. Previously we had vector, but the index had no meaning, in other words, the random access was not used.

refs #74

comment:6 in reply to: ↑ 1 Changed 9 years ago by peter

Replying to jari:

Among things to fix are (in SVNlog):

> // The return type should be svn_log_message_receiver_t but I
> // cannot get it to compile. The svn API has a typedef like
> // typedef svn_error_t*(* svn_log_message_receiver_t)(void *baton,
> // apr_hash_t *changed_paths, svn_revnum_t revision, const char
> // *author, const char *date,const char *message, apr_pool_t
> // *pool) for svn_log_message_receiver_t.
> static svn_error_t*
> log_message_receiver(void *baton, apr_hash_t *changed_paths,
> svn_revnum_t rev, const char *author, const char *date,
> const char *msg, apr_pool_t *pool);

and the similar in SVNinfo:

> // The return type should be svn_log_message_receiver_t but I
> // cannot get it to compile (see comment for log_message_receiver
> // in SVNlog.h)
> static svn_error_t*
> info_receiver(void *baton, const char *path, const svn_info_t *info,
> apr_pool_t *pool);

I cannot understand what these comments are based on. Why should the return type be svn_log_message_receiver_t? I checked in subversion 1.4.0 (which is the API we work against) and in log-cmd.c they use svn_client_log3 similarly to us with a function

static svn_error_t *
log_message_receiver(void *baton,
                     apr_hash_t *changed_paths,

which obviously has return type svn_error_t*. Either I'm missing something or this ticket is just old and rusty? Can we close this?

The same appears for SVNinfo where subversion uses svn_client_info in http://svn.collab.net/repos/svn/tags/1.4.0/subversion/svn/info-cmd.c

comment:7 Changed 9 years ago by jari

(In [844]) Addresses #74. Removed comments on receivers. Don't remember what I meant. It works, don't fix it.

comment:8 Changed 9 years ago by jari

  • Resolution set to fixed
  • Status changed from new to closed

Partly fixed.

Note: See TracTickets for help on using tickets.