[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Copy node vs copy property (was Re: CVS update ...)

From: Yoshiki Hayashi <yoshiki_at_xemacs.org>
Date: 2001-03-05 07:15:09 CET

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

This is an archived mail posted to the Subversion Dev mailing list.