Jim Blandy <jimb@zwingli.cygnus.com> writes:
> Greg Hudson <ghudson@MIT.EDU> writes:
> > > I can't tell see what advantage copy nodes have over simply setting
> > > a property on the copy that says where it was copied from.
> >
> > Oh, people thought of that. The only problem is that properties are
> > inherited from one revision to the next, so you'd have to special-case
> > those properties or lose information.
>
> No, you include the revision number in which the copy took place in
> the property. (How you'd get the revision number before you do the
> commit, I don't know, but surely that can be addressed somehow.) Copy
> properties would accumulate, or perhaps we'd erase copy properties
> from previous revisions, since we could always find them.
What happend to this discussion? I didn't see any
conclusion. I'm in favor of ordinary node + copy property
and here's how it can be done.
First, all new copy nodes in a transaction is mutable.
Second, svn_fs__dag_commit_txn walk through mutable nodes
and delete mutable flag.
What svn_fs__dag_commit_txn does are:
- mark mutable nodes immutable and make its contents stable
- create a new fs revision
- delete transaction
Since these are done by one trail (one DB transaction), the
order of above three operation doesn't matter. So you can
first create a new fs revision and then walk through mutable
nodes. When the function finds a mutable node, it checks
whether it is a copy node or not and if it is, it replaces
base fs revision field of copy property.
--
Yoshiki Hayashi
Received on Sat Oct 21 14:36:25 2006