W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1998

RE: Version merging questions

From: Chris Kaler <ckaler@microsoft.com>
Date: Mon, 30 Nov 1998 11:22:08 -0800
Message-ID: <4FD6422BE942D111908D00805F3158DF0A757931@RED-MSG-52>
To: "'Geoffrey M. Clemm'" <gclemm@tantalum.atria.com>, muniz@inf.puc-rio.br
Cc: w3c-dist-auth@w3.org
What I believe we have specified to date is that there are "conceptually"
two graphs.  There is a graph that the server maintains and asserts is
correct and there is a graph that is specified by the client that may be
incorrect.  The former is created by checkin/out operations and the later
using the "Merged-From" header/property.  My assumption is that in your
example, you would checkout B and merge the changes from A to created B'
which you call C.  (or vice-versa).  The client would specify that B' is
derived from A and B.  The server would track this as a new revision of B.

Chris

		-----Original Message-----
		From:	Geoffrey M. Clemm [mailto:gclemm@tantalum.atria.com]
		Sent:	Wednesday, November 11, 1998 9:39 AM
		To:	muniz@inf.puc-rio.br
		Cc:	w3c-dist-auth@w3.org
		Subject:	Re: Version merging questions

		   From: "Bruno C. Muniz" <muniz@inf.puc-rio.br>

		   Suppose I have two unrelated resources A and B, version
graphs VA and
		   VB, where A belongs to VA and B belongs to VB. Now, if I
derive a
		   version C from A and B, what happens ? C is inserted in
both VA and VB
		   and a new version graph VC containing C is created ?
Since a resource
		   can be in multiple version graphs, does exist a kind of a
default
		   version graph for a given resource ?

		Good question.  Although allowing a revision to be in
multiple
		versioned resources is an explicit "nongoal" in the current
WebDAV
		"Versioning Goals" document (nongoal #1, in fact), this
doesn't fully
		address your question.  We should add a statement that "the
		predecessors and sucessors of any revision of a versioned
resource
		must also be revisions of that versioned resource".  This is
implicit
		in the current draft of the proposed protocol (where the
predecessors
		and successors are specified in terms of revision-id's
instead of URI's),
		but it would be clearer if it were explicit in the "goals"
document.

		Cheers,
		Geoff
Received on Monday, 30 November 1998 14:22:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:48 GMT