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

Re: Why does MERGE automatically checkin resources related to act ivities?

From: Greg Stein <gstein@lyra.org>
Date: Thu, 4 Oct 2001 03:35:06 -0700
To: "Clemm, Geoff" <gclemm@rational.com>
Cc: ietf-dav-versioning@w3.org
Message-ID: <20011004033506.I24906@lyra.org>
On Wed, Oct 03, 2001 at 09:32:59AM -0400, Clemm, Geoff wrote:
>    From: Greg Stein [mailto:gstein@lyra.org]
> The main problem with that marshalling is how can you tell the
> difference between:
> - someone who wants to create a bunch of new resources, i.e. create a
>   set of new VHRs whose initial versions happen to be initialized by
>   the content of an existing tree of VCRs.
> - someone that wants to create new versions for a set of existing VHRs

Don't need to tell the difference :-)  We only support the former.

> In particular, DeltaV defines the semantics of the COPY into a
> working directory to be the former, i.e. create a set of new VHR's
> when the working collection is checked in.

Well, that is just dandy for our case :-)

> OK, I misunderstood.  I thought by "cheap copy", you meant creating a
> new tree of VCRs that share the VHRs of an existing tree of VCRs.
> Instead, you meant creating a tree of (non-version-controlled) resources
> within a working collection.

Correct. And those new resources become version-controlled upon checkin.

> So you are not going to support "revision branching" (i.e. where the
> revision history itself branches)?  That does sound vaguely familiar,
> so probably you did tell me that a while ago.

Purely sequential, global revision numbers. Each revision is effectively a
baseline for the whole repository. No branching; just work on stuff in a
different "subdirectory" within the virtual filesystem.

>    The basic issue here is that the model used by Subversion (and I suspect a
>    goodly number of other systems) does not provide for checking in a new
>    "head" revision and hiding it until somebody cares to make it visible.
> I thought it was a fairly central CVS feature to create a new "branch"
> of the repository, to do a whole series of checkins on a branch, and
> then only merge that repository branch on demand (although I agree
> that it doesn't to the merge part very well)?  That's what separating
> CHECKIN and MERGE is all about.

Because CVS sucks so hard at the merge process, nobody ever uses branches
for temporary hiding of checkins. They are normally just used for longer
term branches.

[ yes, some people *do* create branches for every change. they're masochists ]

And creating a branch on *every* commit, just to support the two-phase
CHECKIN / MERGE? Bah. I don't care for persistent data artifacts that result
from a faulty design spec.


Greg Stein, http://www.lyra.org/
Received on Thursday, 4 October 2001 06:31:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:47 UTC