> From: Branko Cibej [mailto:brane@xbc.nu]
> Sent: Friday, June 06, 2003 3:55 AM
> kfogel@tigris.org wrote:
>
> >+ [Note from kfogel: Is there some reason we can't store successor
> >+ nodes at commit time? That is if N is a director successor of M,
> >+ then when we create N, we add it to M's "successors list". Then we
> >+ could track forward as well as backward... Nothing against having
> >+ an SQL backend someday, of course, just pointing out that this
> >+ particular problem can be solved simply in Berkeley DB.]
> >
> >
> No, there is no reason why we couldn't do that, and I think that
> (long-term) we should. Also, note that a SQL back-end won't help one bit
> here; this is a high-level schema issue; our schema simply doesn't
> contain successor pointers, and a SQL back-end won't be able to add them
> unless the FS DAG layer does the work.
Say we have a certain NodeRev, identified by (ReposID,NodeID,CopyID,TxnID).
We can get the successors by doing a query for all matching NodeRevs which
have the same (ReposID,NodeID,CopyID), we match the accompagnying TxnIDs
to revision numbers, restricting the results to revs higher than the one
associated with the NodeRev we are searching successors for. Note that this
will only find successors on the same branch. And yes, we could have
successor pointers for this case. I think that those are not needed
for the SQL backend.
The other case, finding all successors of a NodeRev on all branches is
impossible to do with successor pointers unless you want to add a list of
successor pointers. For the SQL backend it will not be very difficult to
query. Say we have a certain NodeRev, identified by
(ReposID,NodeID,CopyID,TxnID). We can get the successors by doing a query
for all matching NodeRevs which have the same (ReposID,NodeID) where the
accompagnying CopyID is higher and were the TxnIDs map to higher revnums
as associated with the NodeRev we are searching successors for. Note that
this will not find unmodified lazy copies of a given NodeRev, which from
a user perspective could be viewed as successors.
Sander
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 6 09:48:26 2003