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

Hi,

DAV:auto-activity-checkin would help.

But, why only apply the auto-checkin to sources related to an activity?
If we are going to add DAV:auto-activity-checkin.  Why not call it
DAV:auto-checkin and also apply this logic to collections and other
DAV:source elements?  I think this flag would be useful, eg to auto
checkin ANY extracted merge source. 

One of the reasons that I raised the initial question was that
the behaviour was inconsistent, eg checked-out resources were
being treated differently by MERGE just because they were related
to an activity.

Regards,
--
Peter Raymond - MERANT
Principal Architect (PVCS)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com



-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: 02 October 2001 14:47
To: ietf-dav-versioning@w3.org
Subject: RE: Why does MERGE automatically checkin resources related to
act ivities?


As indicated, a single objection to a change at this late
state in the process is sufficient to keep the
feature (auto-activity-checkin on MERGE) in the protocol.

I do believe Roy made a good case for making this behavior
be under client control, so I'd like to modify the marshalling
of the MERGE request so that there is a DAV:auto-activity-checkin
flag to MERGE that indicates whether or not the client wants this
auto-activity-checkin behavior.  Does anyone object to this change?
(I'd like to make the default to not do the checkin, since this
is more consistent with the non-activity semantics of MERGE, which
does not merge checked-out resources.

I will make some comments on Greg's message below, since I
am interested in how subversion will be using the DeltaV protocol,
but this is not an attempt to keep this issue open (i.e.
I believe the DAV:auto-activity-checkin flag addresses the issue).


   From: Greg Stein [mailto:gstein@lyra.org]

   On Mon, Oct 01, 2001 at 09:50:50AM -0400, Clemm, Geoff wrote:
   > Greg: If you split your "commit" into an activity "CHECKIN"
   > followed by a baseline "MERGE", I believe you would have the
   > right framework for doing branching (in particular,

   We use cheap copies, not branching.

A "cheap copy" is probably a better name for what I had in mind
anyway, so I'll use that term here instead of "branching".

In particular, I noticed in the subversion "mapping to WebDAV" design
notes, that you were moving towards using something other than "COPY"
to marshal the creation of a "cheap copy".  I believe that
BASELINE-CONTROL is the appropriate way to marshal this.  The
DAV:baseline-collection property of a baseline exposes that "cheap
copy" in an interoperable way.

   > a branch is just a CHECKIN that is not followed by a MERGE).
   > This would have CHECKIN of an activity create a new
   > subversion revision (aka a DeltaV baseline), but this revision
   > wouldn't become the "current" one until you did the MERGE.

   Not supported.

Isn't this just what a "cheap copy" is (i.e. a new revision that does
not replace the current one)?  And don't you provide a way to "merge"
one "cheap copy" into another (i.e. a MERGE)?

I assume the reason you don't want to always use a CHECKIN/MERGE sequence
is that your revisions, although cheap, are expensive enough
you don't want to create them more often than is necessary
(i.e. only do the CHECKIN if the MERGE will succeed)?

   > If so, I believe this would then remove your need for
   > having CHECKIN be a side effect of MERGE.  But this of course
   > works only if subversion allows a new revision to be created that 
   > does not immediately become the current revision.  But don't
   > you have to do that to support branching?

   Effectively, we do:

   $ svn cp /trunk /branches/gstein-work

Could that be marshalled as:

<create baseline for /trunk>
BASELINE-CONTROL /branches/gstein-work 
 <D:version> <the-trunk-baseline> </D:version>

   Hmm. I just realized that the original question made it seem like
   some weird side effect. But in the case under discussion, you're
   doing a MERGE on an *activity*. Thus, it makes perfect sense to
   take all resources contained in that activity as the merge source.

Yes, if the activity is "done".  Roy's examples were for cases
where the activity has an interesting state you want to merge
into your workspace, even though the activity is not yet done.

Cheers,
Geoff