Re: DAV:precursor-set (was: Re: collection version resources)

   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).

   >...
   > Then a DAV:predecessor-set would refer to versions in the same version
   > history, while DAV:precursor-set would refer to versions in other version
   > histories.  The MERGE and BASELINE operations would be based on versions
   > connected by the DAV:predecessor-set property, but you could have
   > version tree displays that showed the cross-version-history links.

   Bing!

   > With the DAV:precursor-set property, you can use COPY (hey, that's
   > what you suggested doing in the first place :-).

   Yup, and yup (although misguided originally :-)

   > 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".

   I'm figuring that if the destination of the COPY is automatically placed
   under version control, that everything works fine. Specifically, if we say
   the COPY adds the DAV:precursor-set property, *then* whatever happens,
   happens (e.g. after the copy/set, then it is placed under version control).
   Given that semantic, we're probably quite fine.

Great!

   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.

Cheers,
Geoff

Received on Sunday, 7 January 2001 09:30:41 UTC