On Fri, Jun 14, 2002 at 02:57:27PM -0500, cmpilato@collab.net wrote:
> Greg Stein <gstein@lyra.org> writes:
> > On Fri, Jun 14, 2002 at 02:33:45PM -0500, cmpilato@collab.net wrote:
> > >...
> > > CHANGES (a new table, duplicately keyed on Transaction Ids)
> > > - a "changes" header
> > > - the changed node revision id
> > > - the filesystem path of the changed node revision id
> > > - the kind of change: added, deleted, replaced or modified
> >
> > Ah. This scales *way* better (hadn't thought about scaling in my earlier
> > response). You can just add rows rather than keeping a big glom in memory.
> >
> > How do you define replaced vs. modified? AFAIK, we never "modify".
>
> Oh, "replace = delete + add", where modify means "text or prop
> changes". Sorry for the ambiguitiy.
The change are going to come into the FS quite separately. If a delete comes
in, and followed sometime later by an add, then you'll end up with those two
changes recorded. There is no way that you can/should consider scanning the
table for each "add" to see if there was a corresponding "delete" which
should be remapped to a "replace".
Heck. I'm not even sure how you're going to populate this table. If
svn_fs_make_file() is called, then you're going to get an add. Some time
later, somebody is going to change its contents, so you'll get a "modify"
for its text, then another "modify" for its properties.
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 Fri Jun 14 22:15:38 2002