Re: Patches

(Question 1) I agree that moves and deletions make the
DAV:baseline-comparison REPORT more expressive than a sparse
configuration concept would be. But I'm concerned whether
this lends itself to efficient implementation for release
management purposes. For large products, baselines are big,
and patch deltas between them might often be small. Would
time and space efficiency suffer because the only way to
name the (small) patch is to compare two (big) baselines?

Of course, a release management system could cache the
results of the DAV:baseline-comparison REPORT, but this
would not be a namable WebDAV resource in the URL namespace.


(Question 2) Suppose an author wanted to define a patch as
the set of merge target versions from a patch activity into
the mainline activity, where the reference baseline was the
baseline defining the initial release. How could the patched
baseline be computed?

Roy

"Clemm, Geoff" wrote:
> 
> You can create a new baseline in the collection,
> and then use the DAV:compare-baseline report
> to describe the differences.
> 
> Creating a collection that just contains the
> "changed files" doesn't really capture the change,
> since it can only capture additions, and not
> moves or deletions.
> 
> Cheers,
> Geoff
> 
> -----Original Message-----
> From: Eric Sedlar [mailto:Eric.Sedlar@oracle.com]
> Sent: Wednesday, January 31, 2001 2:43 PM
> To: DeltaV (E-mail)
> Subject: Patches
> 
> What's the best way to model a patch set in deltaV?  (Let's say I want to
> create a
> configuration including only the files in a collection, recursively, that
> have changed since
> a particular baseline.)
> 
> --Eric

Received on Thursday, 1 February 2001 17:48:20 UTC