Re: immutable DAV:merge-predecessors
Geoffrey M. Clemm (geoffrey.clemm@rational.com)
Fri, 3 Dec 1999 12:13:42 -0500
Date: Fri, 3 Dec 1999 12:13:42 -0500
Message-Id: <9912031713.AA11923@tantalum>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
In-Reply-To: <"i41fs1.ira.834:03.12.99.13.50.10"@ira.uka.de> (jjh@ira.uka.de)
Subject: Re: immutable DAV:merge-predecessors
<gmc/>
I have come to believe that the cost to a server implementation
resulting from requiring the mutablity of DAV:merge-predecessors outweighs
the benefit that results, so I'd like to propose that we follow Jim's
suggestion and make DAV:merge-predecessors be an immutable property.
<jjh/>
Is there a concept of set once properties, i.e. properties that need not
be set a revision creation time but once set they are no longer
changeable?
<gmc/> No, we currently have no such notion.
<jjh/>
How strictly is immutable defined in terms of check-in time.
<gmc/> Very strictly. The idea is that you check something in to make
it immutable (and the server implementation can then take advantage of
that immutability to make workspace caching efficient).
<jjh/>
Do all immutable revision properties need to specified with the
corresponding check-in request?
<gmc/> Yes, in the sense that the current values of those properties of a
working resource become immutable when the working resource is checked
in to create a revision.
<jjh/>
I would agree that one should not
change DAV:merge-predecessors once it is set, but it may be convenient
to set it later.
<gmc/> Why would you set it later? Since the body of the revision
cannot be changed after check-in, there could be no new contributors
(i.e. predecessors) after the check-in.
<jjh/>
Though I do not see a big difference for merging
either way. If merging is done on the server, then this is probably a
none issue.
<gmc/> So just to make sure, I read this as agreement to make
DAV:merge-predecessors immutable?
Cheers,
Geoff