On Tue, Mar 18, 2003 at 01:24:51PM -0600, cmpilato@collab.net wrote:
>...
> > Greg Stein wrote:
> > >* is there a future scenario where revisions do not need to be time-ordered,
> > > so maybe this points to a flow in the current implementation?
> >
> > <whimsical-mode>Points to a flow...hmmm...and flows to a point,
> > too...<whimsical-mode>
"flaw flaw flaw flaw..." That was a flawed "flaw" .... :-)
> > As far as I know, there is exactly one reason why our commits must be
> > time-ordered: So that get_revision_by_date can do a binary search on
> > revision numbers. If we added an extra date->revision index, this
> > ordering wouldn't be necessary any more and we wouldn't need
> > svn:original-date.
Right. And I'm alright with that. I don't know how to get that done, yet I
*do* know how to add a property :-)
> > I'd rather introduce this index and lift the restriction on svn:date
> > than add another date property.
Totally cool with me.
> +1, almost. Would rather do DATE->TXN_ID (that way we can get both
> committed and uncommitted transactions).
As long as you have a way to go from TXN_ID to revnum(?).
> We can do so in a backwards-compatible fashion, too.
> svn_fs_create_berkeley will create and populate this table.
> svn_fs_open_berkeley will not.
So a dump/load would get the thing populated. Thus, it might be nice to do
this before the schema changes which require a dump/load? Thus, anybody who
upgrades will get the table?
> Then, we make a new public FS call,
>
> svn_error_t *svn_fs_dated_revision (svn_revnum_t *rev,
> svn_fs_t *fs,
> apr_time_t tm,
> int direction,
> apr_pool_t *pool);
>
> (where direction is used to determine which way to search for a
> revision when TM falls between two of them.)
I'm all for doing this, rather than the logic in repos. That's a bit
"expensive" to do it at that layer.
> This function can use cursors to find the closest transaction in the
> transaction table that is of type "committed".
Sure. Also need to define behavior for Brane's "multiple txn's at the same
date" issue. Maybe the direction is an enum:
enum {
svn_fs_rev_older, /* pick the revision older than the date */
svn_fs_rev_younger, /* pick the revision younger than the date */
svn_fs_rev_exact, /* only if a single revision matches; otherwise, bail */
svn_fs_rev_older_choose, /* choose one arbitrarily if multiple match */
svn_fs_rev_younger_choose, /* choose one arbitrarily if multiple match */
svn_fs_rev_choose /* choose one arbitrarily if multiple match */
}
(or a tri-state mode with a "choose" flag to 'or' into the mode)
>...
> Later, if we need
> svn_fs_dated_transaction, it does the same thing, but looks for
> "transaction"-typed transaction instead.
Sure.
> The function also returns
> SVN_ERR_UNSUPPORTED_FEATURE if the new table doesn't exist.
>
> svn_repos_dated_revision() can try svn_fs_dated_revision, and then
> fall back to its current brute-force method if
> SVN_ERR_UNSUPPORTED_FEATURE is returned.
Nah. Put the fallback into the FS code *until* we have a forced dump/load
cycle. After the dump/load the table will be there, so the compat code can
be removed. By shifting the code from repos to FS, then we can localize the
workaround code within the FS.
> NOTE: If, however, we don't think we'll ever need the perfect sorting
> of all transactions (including committed ones), ignore some of this
> and just do DATE->REVNUM -- that'd be more efficient.
I don't see a need to *find* a transaction by date. I can see wanting to
sort the transactions, but I think it would be fine to get the list of txns
and then sort the results.
If DATE->REVNUM is more efficient, then +1 on that, and -0 on DATE->TXN_ID.
So I'll make you a trade. I'll remove the prop if you add the table :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 18 23:26:44 2003