[OT] SVN copy issue (was: Re: DAV:precursor-set)

On Sun, Jan 07, 2001 at 09:29:51AM -0500, Geoffrey M. Clemm wrote:
>    From: Greg Stein <gstein@lyra.org>
> 
>    > ....  Perhaps, a "DAV:precursor-set"
>    > property that is automatically set on the destination when you
>    > perform a COPY?
> 
>    Sounds fine.
> 
>    Strictly speaking, SVN can't do this right now, but that's okay... it has
>    actually exposed a problem in SVN's copy-by-ref model. IOW, by applying
>    DeltaV's model to SVN, I've discovered a potential flaw in SVN :-)
>    [ working this out now on the SVN list ]
> 
> Cool! (It's a shame about SVN's model had a problem, but it's
> good that the protocol had this positive effect :-).  I'm guessing
> that the problem was in the ambiguity in determining the merge
> target during a merge?  (No need to answer here ... I'll go look up
> the thread on the SVN mailing list).

Basic answer: SVN has a true copy-by-ref, yet has no marker that the copy
occurred. Effectively, you have two directories with the same file appearing
in both (hard-link). You cannot tell which is the original and which is the
copy. If you examine the directory versions, you can see that one appeared
after the other, so you can infer a copy was made (there is a gotcha in this
case, however). If you make a third copy, then you cannot tell which of the
first two it was made from. IMO, that loses information.

And since we can't determine that a copy was truly made, and where the copy
source was, it means that we cannot determine the value for
DAV:precursor-set.

[ recall that SVN is not *storing* DAV:precursor-set, nor does it store
  histories or version resources or whatever; it *synthesizes* all of those
  at runtime from existing information in the repository; if it doesn't have
  copy information, then it cannot synthesize DAV:precursor-set. ]

Even if the resolution is to *not* store the copy information, then SVN is
sort of okay, in a less-than-interoperable way. We'll end up with two VCRs
referring to the same version history (and the baselines will have two refs,
too). The MERGE will still work fine (we aren't really merging based on
matching version histories; that is just a model that happens to have the
same end result), but "theoretically" the MERGE should have broken.

>...
>    > So, anybody object to the DAV:precursor property that is set whenever
>    > you do a COPY from either a version or a checked in version controlled
>    > resource?
> 
>    Sounds fine to me. Is there a gotcha in that DAV:precursor-set is a
>    protected live property set by the COPY operation, yet the copied result
>    (sitting in the working collection) is a non-versioned resource?
> 
> Actually, that's intended to be a feature ... even if a resource is
> not under version control, it might be nice to know its "ancestry".

Agreed.

[ my thought was whether the target could deal with having the property;
  your idea below says "yah, no problem." ]

>...
>    Question is what happens when you COPY into a non-controlled namespace. Will
>    the property be set? Or does it only get set for "special" namespaces (such
>    as working collections or VCR parents or auto-controlled spaces).
> 
> Currently, the protocol requires that it be set on *any* copy
> destination that will return "version-control" in the DAV header from
> an OPTIONS request.  So if the copy destination could
> be put under version control with a VERSION-CONTROL request, that
> resource MUST maintain the DAV:precursor-set property.  I think this
> is what we would want.

Great idea! I'm quite fine with that.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Sunday, 7 January 2001 14:24:56 UTC