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

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

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Sat, 23 Dec 2000 11:48:26 -0500 (EST)
Message-Id: <200012231648.LAA10221@tantalum.atria.com>
To: ietf-dav-versioning@w3.org

Ooops.  Looks like I should have read ahead ... Greg just made many of the
points in this response that I made in mine.

   From: Greg Stein <gstein@lyra.org>

   On Fri, Dec 22, 2000 at 10:18:21PM -0800, Greg Stein wrote:
   >     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)

   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.


   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.

Yes, "baselines" or "deep versions" are there for when you want to bubble
up (which is why I keep beating the "baseline drum" for subversion :-).

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

I don't think you'll need sub-baselines until you do
cross-repository linking, but regular baselines should
get you what you want.

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

The informal criteria for "design team acknowledgement" was technical 
mailing list participation and attendance at at least 2 design meetings.
I'd say that a flood (:-) of mail messages and responsibility for at least
two of the features in the protocol (working collections, auto-checkin
for MERGE) calls for a change to the informal criteria ...
so, what "organization" (if any) would you like to have appear
next to your name?

   Happy holidays everyone!

Same from me!  And a special thankyou to Greg for all his work.

Received on Saturday, 23 December 2000 11:49:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC