> From: cmpilato@collab.net [mailto:cmpilato@collab.net]
>
> Greg Stein <gstein@lyra.org> writes:
>
> > > 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.
>
> Yeah, I just independently arrived at the same conclusion. :-( I
> certainly don't want multiple table rows per path.
Why not? Remember long lived non-committed transactions are likely to
come to pass eventually. (aka bk pull, bk push replication like
semantics)
> Perhaps the answer
> is to map
>
> revision-id => (path, node-revision-id)
>
> and populate the `changes' table rows for a given revision during the
> deltification walk post-commit.
>
Ick. See my previous comment why I don't like this idea.
Bill
---------------------------------------------------------------------
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:35:02 2002