You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Yoshiki Hayashi <yo...@xemacs.org> on 2001/03/05 06:15:09 UTC
Copy node vs copy property (was Re: CVS update ...)
Jim Blandy <ji...@zwingli.cygnus.com> writes:
> Greg Hudson <gh...@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
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Yoshiki Hayashi <yo...@xemacs.org> writes:
> Jim Blandy <ji...@zwingli.cygnus.com> writes:
>
> > Yoshiki Hayashi <yo...@xemacs.org> writes:
> > > 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.
> >
> > Yes, that would certainly work. It's kind of ugly, though, for the
> > filesystem to be wonking on node properties. It would be really nice
> > if we could come up with an entirely client-side approach.
>
> I'm a bit confused. What do you mean by entirey client-side
> approach? Somehow the information where copy node has been
> copied from must be stored in filesystem?
What I meant is that the client can accomplish the task using only the
existing svn_fs.h interface. The filesystem can remain simple and
ignorant of copy tracking, while the client takes care of annotating
things appropriately.
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, Mar 09, 2001 at 04:06:42PM -0600, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > > I believe Jim means that
> > >
> > > $ svn copy foo.c bar.c
> > >
> > > adds a copy property to bar.c, so that when bar.c is committed, it
> > > simply _has_ the requisite property without the fs doing any extra
> > > work. I.e., for the fs, the copy properties would be read-only data.
> > > The source would always be the client.
> >
> > If it is a property that was (effectively) placed on node ID 11.2, then how
> > do you know that 11.3 isn't a copy, but a derivative of 11.2? Without
> > assistance from the server (to clear copy props), we couldn't get that prop
> > cleared on the successor.
>
> Why couldn't the client clear it... ooooh, icky. Hmmm.
>
> [Karl, in the third person, decides to punt on this for a while, being
> occupied with other things. Agrees we need to solve it. Is content
> to let it sit and rot for now, though.]
>
I thought we had decided that the copy property could include
information about when it was copied. Thus the property wouldn't need
to be deleted, it could live indefinitely. (I.e.), Property says
something like revision 11.2 of this node is a copy of revision 12.3.
Then the property itself distinguishes which revision the copy occurred
in.
Am I missing something?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
Karl Fogel <kf...@galois.ch.collab.net> writes:
> Greg Stein <gs...@lyra.org> writes:
> > > I believe Jim means that
> > >
> > > $ svn copy foo.c bar.c
> > >
> > > adds a copy property to bar.c, so that when bar.c is committed, it
> > > simply _has_ the requisite property without the fs doing any extra
> > > work. I.e., for the fs, the copy properties would be read-only data.
> > > The source would always be the client.
> >
> > If it is a property that was (effectively) placed on node ID 11.2, then how
> > do you know that 11.3 isn't a copy, but a derivative of 11.2? Without
> > assistance from the server (to clear copy props), we couldn't get that prop
> > cleared on the successor.
>
> Why couldn't the client clear it... ooooh, icky. Hmmm.
Rather than rephrasing Jim's idean in my not very good English, I
just refer to his message.
<np...@zwingli.cygnus.com>
http://subversion.tigris.org/subversion-dev/current/msg01862.html
In short, you also add fs revision number to property which
indicates when it is copied.
--
Yoshiki Hayashi
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> > I believe Jim means that
> >
> > $ svn copy foo.c bar.c
> >
> > adds a copy property to bar.c, so that when bar.c is committed, it
> > simply _has_ the requisite property without the fs doing any extra
> > work. I.e., for the fs, the copy properties would be read-only data.
> > The source would always be the client.
>
> If it is a property that was (effectively) placed on node ID 11.2, then how
> do you know that 11.3 isn't a copy, but a derivative of 11.2? Without
> assistance from the server (to clear copy props), we couldn't get that prop
> cleared on the successor.
Why couldn't the client clear it... ooooh, icky. Hmmm.
[Karl, in the third person, decides to punt on this for a while, being
occupied with other things. Agrees we need to solve it. Is content
to let it sit and rot for now, though.]
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Greg Stein <gs...@lyra.org> writes:
> On Fri, Mar 09, 2001 at 08:39:55AM -0600, Karl Fogel wrote:
> > Yoshiki Hayashi <yo...@xemacs.org> writes:
> > > I'm a bit confused. What do you mean by entirey client-side
> > > approach? Somehow the information where copy node has been
> > > copied from must be stored in filesystem?
> >
> > I believe Jim means that
> >
> > $ svn copy foo.c bar.c
> >
> > adds a copy property to bar.c, so that when bar.c is committed, it
> > simply _has_ the requisite property without the fs doing any extra
> > work. I.e., for the fs, the copy properties would be read-only data.
> > The source would always be the client.
>
> If it is a property that was (effectively) placed on node ID 11.2, then how
> do you know that 11.3 isn't a copy, but a derivative of 11.2? Without
> assistance from the server (to clear copy props), we couldn't get that prop
> cleared on the successor.
As I said before, if the property's value can somehow be marked with
the revision in which the copy was made, there's no ambiguity. The
property can persist, but we always know when the event happened.
The problem is that the property is set as part of a transaction, but
a client of the svn_fs.h interface has no idea what the revision
number will be until the transaction has been committed. So there's a
small chicken-and-egg problem. But it doesn't seem fundamental, so
I've been hoping someone would come up with a clever way around it.
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 09, 2001 at 08:39:55AM -0600, Karl Fogel wrote:
> Yoshiki Hayashi <yo...@xemacs.org> writes:
> > I'm a bit confused. What do you mean by entirey client-side
> > approach? Somehow the information where copy node has been
> > copied from must be stored in filesystem?
>
> I believe Jim means that
>
> $ svn copy foo.c bar.c
>
> adds a copy property to bar.c, so that when bar.c is committed, it
> simply _has_ the requisite property without the fs doing any extra
> work. I.e., for the fs, the copy properties would be read-only data.
> The source would always be the client.
If it is a property that was (effectively) placed on node ID 11.2, then how
do you know that 11.3 isn't a copy, but a derivative of 11.2? Without
assistance from the server (to clear copy props), we couldn't get that prop
cleared on the successor.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Karl Fogel <kf...@galois.collab.net>.
Yoshiki Hayashi <yo...@xemacs.org> writes:
> I'm a bit confused. What do you mean by entirey client-side
> approach? Somehow the information where copy node has been
> copied from must be stored in filesystem?
I believe Jim means that
$ svn copy foo.c bar.c
adds a copy property to bar.c, so that when bar.c is committed, it
simply _has_ the requisite property without the fs doing any extra
work. I.e., for the fs, the copy properties would be read-only data.
The source would always be the client.
-K
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Yoshiki Hayashi <yo...@xemacs.org>.
Jim Blandy <ji...@zwingli.cygnus.com> writes:
> Yoshiki Hayashi <yo...@xemacs.org> writes:
> > 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.
>
> Yes, that would certainly work. It's kind of ugly, though, for the
> filesystem to be wonking on node properties. It would be really nice
> if we could come up with an entirely client-side approach.
I'm a bit confused. What do you mean by entirey client-side
approach? Somehow the information where copy node has been
copied from must be stored in filesystem?
Can we decide which one to use, copy node or copy property?
Copy handling is another big thing left unimplemented in the
filesystem.
As I've said, I'm +1 for node property. But I'd like to
propose using flag field, instead of property field. Flag
field is internal to filesystem and it's unlikely to be as
crowded as property field will be.
--
Yoshiki Hayashi
Re: Copy node vs copy property (was Re: CVS update ...)
Posted by Jim Blandy <ji...@zwingli.cygnus.com>.
Yoshiki Hayashi <yo...@xemacs.org> writes:
> 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.
Yes, that would certainly work. It's kind of ugly, though, for the
filesystem to be wonking on node properties. It would be really nice
if we could come up with an entirely client-side approach.