[snip - discussion of storing properties for altered files.]
[snip - discussion noting that for newly created files you don't want to
edit the prop-list of all of them, you want something like a copy]
On Friday, August 9, 2002, at 06:21 PM, Bill Tutt wrote:
>>> 2) We fold this wrinkle into our lazy mode of operation.
>>> Specifically: Initial edits of copies that originate as the result
> of a
>>> merge need the merge-specific ancestor set information added to
> their
>>> ancestor set.
Okie - I'm trying to figure this out.
I'm looking in: subversion/libsvn_fs/structure. It looks like you
should just be able to modify the copies table...
From subversion/libsvn_fs/structure:
> The Berkeley DB `copies' table records all filesystem copies. Every
> key in this table is copy ID, and every value is a skel of the form:
>
> ("copy" SRC-PATH SRC-TXN DST-NODE-ID)
Replace "copy" with "merge" for copies that occur as the result of a
merge. This change should be backwards compatible. Would this even
require a dump/load? This modification seems to store all the data you
need.*
Having said that, making this change depends upon how both issues 838
and 842 get resolved.
Issue 838 relevance: To get "merge" in the copies table instead of
"copy", you need something heading over the wire specifying the
difference. As the way the copy information itself gets to the fs is
still being worked on, it is hard to make changes :).
Issue 842 relevance: What happens when you edit a "merge" copied file?
It may get a new copy table entry. In that case, that entry needs to be
a "merge" too, I think. I'm don't yet have enough info on how 842 is
being solved to figure this case out.
Anyway, I'm in a holding pattern looking at how those issues resolve.
later,
\x/ill :-}
* While this stores all the data you need, it is not necessarily in an
easily accessible form. I'm now going to talk about that access... all
of this should probably be post-1.0.
The result of making this post-1.0 is that the svn:merged properties
will require some patching to be complete (they can be patched up when
the stuff below is implemented). The svn:merged properties will only
contain the information about when already existent files were merged -
they will not have any information about merge-copies.
I am assuming that from the point of view of everything above the fs
layer, everything is stored in svn:merged properties (or an equivalent
list of merges). In that case, when a file is checked out, you'd need
to check if any of the parent dirs were merge-copies. If they were,
then you append the correct merge line to the end of the svn:merged
property as you check out - make a pseudo-property. No theoretical
problem there.
Things get interesting if you merge-copy a directory, and then re-copy
that copy. All the files beneath the final copy still need the
pseudo-property added. In that case you have to detect that you have a
different copy-id from your parent, follow its copies table entry, and
note that you STILL have a different copy-id. So, you look up the
copies table entry again and see that the entry was a merge, and add the
pseudo-property.
The access code must keep chaining back through the copies table until
it gets to the last time the file changed. In that case you assume that
when the file was modified the pseudo-properties were turned into real
properties.
This seems potentially expensive. In particular, every time you access
a node beneath a copied tree, you need to follow the copies tables back
until that node was last modified to collect any pseudo-properties.
This needs to happen even for non-merged files as you cannot tell them
from the merged ones. It is a time/space trade-off: either you keep the
properties up to date (my original proposal), or you need to calculate
them. (Actually, I guess this proposal is already somewhere between the
extremes: I'm suggesting denormalizing the merge info when a file is
modified. You don't have to do that.) If svn:merged properties were
accessed separately from the other properties then at least you would
only need to pay this cost when looking for merge information.
It may also be possible to cache some of this info in the copies table,
but that's definitely a post-1.0 issue. It would require some details
to be worked out and a dump/load. There is no need to think about this
now.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 11 08:11:17 2002