Re (2): compare-baseline report with subbaselines

> Good point.  We did neglect to define the DAV:compare-baseline
> behavior on subbaselines.
It seems I'm the first one to try implementing compare-baseline with subbaselines :-)

> We could:
> - Have subbaselines appear in DAV:added-version, DAV:deleted-version,
> and DAV:changed-version elements.  This is reasonable, since a baseline
> is a special kind of version
I would prefer to have DAV:added-baseline, DAV:deleted-baseline,
and DAV:changed-baseline elements. If not, the baseline aware client has the
unnecessary work to find out whether it's a resource or a configuration version. 
And the non baseline client could be confused. Getting a DAV:<x>-baseline element
would be easier to detect.

> - Have DAV:compare-baseline "recurse" into subbaselines, and report on the
> versions of those subbaselines.
Doesn't make much sense for added and deleted subbaselines.

> I probably prefer the former behavior, since otherwise the behavior of adding a
> subbaseline or deleting a subbaseline gratuitously inflates the size of
> the report.
> A variant of the second approach would be to just report added and deleted
> baselines in added-version and deleted-version elements, but to
> automatically recurse into baselines that appear in DAV:changed-version elements.
That's what I will do at the moment. It's what I think is the logical way.
The danger of inflation isn't that great if you only recurse the changed baselines.

> A variant of this variant would be to have this "recurse" behavior controlled
> by an explicit parameter to DAV:compare-baseline.
Unnecessary complexity.

> But I'd probably still go for the simple version of the second behavior
> (i.e. never  recurse), since a client could always recurse itself, if it wanted to.
That's possible. But I expect a compare-baseline to give me the complete difference
information. And for that I need to recurse changed baselines.

Cheers, Edgar

  



-- 
edgar@edgarschwarz.de                    http://www.edgarschwarz.de
*          DOSenfreie Zone.        Running Active Oberon.         *
Make it as simple as possible, but not simpler.     Albert Einstein

Received on Monday, 28 January 2002 16:07:26 UTC