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

Re: svn commit: r16130 - in branches/fs-atomic-renames/subversion/libsvn_fs_base: .

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2005-09-15 18:30:57 CEST

kfogel@collab.net writes:

> > +/*** Directory Entry ***/
> > +typedef struct
> > +{
> > + /* entry node revision id */
> > + const svn_fs_id_t *id;
> > +
> > + /* (optional) move id */
> > + const char *move_id;
> > +
> > +} directory_entry_t;
>
> It might be useful to have a doc string explaining why this structure
> is necessary, i.e., why it is not the same as svn_fs_dirent_t. Would
> you approve this language?:
>
> /*** Directory Entry ***/
> /* This serves a different purpose from the public svn_fs_dirent_t.
> Whereas svn_fs_dirent_t is designed to convey externally
> interesting information to the outside world, this structure is
> designed to carry around private information (e.g., the move_id)
> inside the filesystem. The 'svn_fs_id_t *id' field tells you
> when they represent the same directory entry, of course. */
> typedef struct
> {
> ...
> } directory_entry_t;

If you look at fs.h as a whole, you'll see that every structure in
that file exists to represent our (private) BDB storage schema. To
call out directory_entry_t like this is useful, I suppose, but
inconsistent with the rest of the file. If we do that, we should also
point out why a change_t isn't the same as an svn_fs_path_change_t,
why a lock_node_t isn't the same as an svn_lock_t, why a transaction_t
isn't the same as an svn_fs_txn_t, etc.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 15 18:32:11 2005

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