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

I never confirmed this...

On Tue, Jan 02, 2001 at 02:06:01PM -0500, Geoffrey M. Clemm wrote:
>...
>    A slightly different way to look at the problem is: if we have two version
>    histories H1 and H2, then can we define a way to state that H2 is based on
>    H1? That H2's initial version is a specific version from H1?
> 
>    If we can do this, then I think we might be okay. Rather than try to share
>    version histories (and the resulting problems), I can create a new history
>    based on what I'm trying to "copy".
> 
> Sure, that would be reasonable.  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 ]

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

>    If the related-history thing sounds acceptable, then we can move forward on
>    a way to create H2 (as part of the change set represented by an activity)
>    and bind it as a member of WC.
> 
> 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?

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.

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

Cheers,
-g

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

Received on Sunday, 7 January 2001 05:34:45 UTC