W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2000

Re: COPY and retain history (was: Re: Subversion support)

From: Greg Stein <gstein@lyra.org>
Date: Sat, 23 Dec 2000 02:34:37 -0800
To: ietf-dav-versioning@w3.org
Message-ID: <20001223023437.R22947@lyra.org>
On Fri, Dec 22, 2000 at 10:18:21PM -0800, Greg Stein wrote:
>...
> Well, I need to figure out exactly where I want to go with this. To create a
> true copy-by-ref, I'd want to use VERSION-CONTROL on a null resource to
> point(*) at the appropriate version (and an existing version history). Then
> I'd want to fork a new line of descent from that version.
> 
> The fork would probably happen in some kind of lazy fashion. Hmm... yes, in
> SVN, the two VCRs would point at the same version resource. As soon as you
> go to modify one or the other, a fork is created.
> 
> Ah. Actually, the VERSION-CONTROL would be executed within a working
> collection. When the working collection is checked in, a new pair of version
> resources are created (which internally reference the same content). For
> example:
> 
>     CHECKOUT /repos/$svn/ver/67/somedir
> 
>     VERSION-CONTROL /repos/$svn/wrk/activity-name-here/67/somedir/foo.c
>     (pointing at /repos/$svn/ver/67/otherdir/foo.c)
>     
>     CHECKIN (activity)

Ah, crap.

This doesn't quite work right. We had previously stated that a working
collection would hold version histories or non-versioned resources (where
the latter are put under version control at checkin time).

But using VERSION-CONTROL to create a "copy" within the working collection
will create a version-controlled resource. And that doesn't fit the model.

Grr.

Creating a binding in the working collection to a version history isn't
going to be quite right either, because we want to copy a specific version
resource into the working collection.

One other thing that I just realized while reading the "versioned collection
option" is that the spec says collection versions refer to version histories
to prevent the "bubble up" syndrome. Well, guess what? :-)  SVN refers to
version resources and does the bubble up.

This is needed because DirA could refer to v6 of foo.c and DirB to v7 of
foo.c.

Sigh...

Well, I'm out of town until next Thursday. I'll ponder on the problem some
more. I suspect that the answer may revolve around "what is in a collection
version? option 1 is version histories; option 2 is version resources." SVN
would be option 2, while other servers will prefer option 1 for the reasons
stated in the draft. This can make sense depending on how you want to view
collections... option (2) implies the collection is bindings to *specific*
members, while option (1) is just bindings.

Oh... Collection versions in option (2) are sub-baselines. Now that is
something to think on while I'm away...

And hey... do I ever get an acknowledgement in the draft? :-)

Happy holidays everyone!

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Saturday, 23 December 2000 05:30:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT