Re: immutable DAV:merge-predecessors
James J. Hunt (jjh@ira.uka.de)
Fri, 3 Dec 1999 14:49:39 +0100
From: "James J. Hunt" <jjh@ira.uka.de>
To: ietf-dav-versioning@w3.org
In-reply-to: <9912031231.AA11824@tantalum> (geoffrey.clemm@rational.com)
Date: Fri, 3 Dec 1999 14:49:39 +0100
Message-ID: <"i41fs1.ira.834:03.12.99.13.50.10"@ira.uka.de>
Subject: Re: immutable DAV:merge-predecessors
Currently, DAV:merge-predecessors is defined to be a mutable property
of a revision. This means that a client is allowed to change this property
value without checking out the revision.
In the past Jim Amsden has argued that this should be an immutable property,
since it represents a key part of the history of a revision. I believe I
have been the only one arguing that it is useful to be able to change this
aspect of the history to support certain merging scenarios.
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.
Anyone disagree?
Cheers,
Geoff
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? How strictly is immutable defined in terms of check-in time.
Do all immutable revision properties need to specified with the
corresponding check-in request? I would agree that one should not
change DAV:merge-predecessors once it is set, but it may be convenient
to set it later. 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.
James