W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Patches

From: Roy Seto <Roy.Seto@oracle.com>
Date: Fri, 02 Feb 2001 19:34:59 +0000
Message-ID: <3A7B0BE2.3DDFC452@oracle.com>
To: ietf-dav-versioning@w3.org
"Geoffrey M. Clemm" wrote:
> 
> The DeltaV baseline mechanism was carefully designed to allow
> for efficient implementation of large baselines.  In particular,
> a baseline is a version, so unless it is the (empty) root baseline,
> it will have at least one predecessor baseline, and therefore
> can be implemented as a delta from that predecessor.  This means
> that the cost of a baseline can be proportional to the changes
> from its predecessor, rather than to the number of versions in it.

Thanks. I understand now.

>    (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?
> 
> Not quite sure what you mean here.  By "merge target version",
> I assume you mean the DAV:checked-in or DAV:checked-out version
> of the merge target?  (The merge target is a version-controlled
> resource, not a version).  I'm not sure what you mean by
> "from a patch activity into the mainline activity" (you merge
> into a collection or a version-controlled resource, not into
> another activity).  Also, what do you mean by the "reference
> baseline"?  And what is the "patched baseline"?

Sorry, my question was not well formed because I did not
consistently use the DeltaV terminology. Here's the scenario
I'm trying to understand:

An author uses what many existing versioning systems call a
subbranch to develop a logical change. Then that author
merges the subbranch into what many versioning systems would
call its parent branch (perhaps by using a workspace defined
in terms of the parent branch as the merge target). The
author would like to identify the versions on the parent
branch created by the merge process (marked as "O" in the
diagram below).

     ----------------------O---- parent branch
       \                  /
        \                /
         ---------------- subbranch

    <--- ancestors   descendants ---> 

Thanks,
Roy
Received on Friday, 2 February 2001 14:34:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:40 GMT