- From: Greg Stein <gstein@lyra.org>
- Date: Sun, 7 Jan 2001 02:33:31 -0800
- To: ietf-dav-versioning@w3.org
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