Re: "latest" resource

On Thu, Dec 21, 2000 at 12:46:58PM -0500, Geoffrey M. Clemm wrote:
> 
> I think the current (10.11) draft gives Greg what he want here.  In
> particular, I'm proposing that we allow a MERGE request to checkin
> every checkout in an activity (previously the spec was silent on this
> case).
> 
> This means that rather than the "atomic activity CHECKIN" that Greg
> asked for before, he instead has "atomic activity CHECKIN and MERGE"
> which I think is what he really wants.  Greg, can you confirm/deny?

Yes, that's what I want: check in everything that has been checked out
(within the specified activity); do the checkin atomically; update all
corresponding VCRs to point to the now-latest version resources.

Note that I don't need activity checkin any more (with this change). I
believe it still makes great sense, so I'd be a "prefer yes" to see it
remain.

>...
>    From: Greg Stein <gstein@lyra.org>
> 
>    On Thu, Dec 21, 2000 at 12:26:29PM +0000, Tim_Ellison@uk.ibm.com wrote:
>    > > Is there a way to tell a VCR to "float" with the
>    > > latest version automatically?
>    > 
>    > No.
> 
>    Grr. This seems a bit bizarre. Of the version control systems that I've used
>    (RCS, CVS, SourceSafe), they've all had floating VCRs (effectively). That
>    DeltaV lacks the same concept is quite astonishing...
> 
> With the above MERGE behavior, you do have the ability to tell the
> server to move forward to all the new versions you are creating, which
> I believe is the "float" you want here.

Sure looks that way.

I would do something like:

  MERGE /repos/$svn/act/my-activity-name
  Destination: http://www.lyra.org/repos

  <some merge body>

The merge body would specify some props, and I'd get my new version URLs and
version-names back. Quite tidy, actually :-)

[ and what is funny is that I initially considered MERGE as doing this
  check-in (which is why I asked for the prop response in there). then you
  said it didn't check in resources, just updated VCRs, so that goes out and
  in comes the activity-CHECKIN. that doesn't update VCRs, so now we're back
  where I started :-) ]

>...
>    > > Is there a way to do this automatically? If not, then
>    > > what is involved with keeping VCRs pointing at the latest?
>    > > Do I need to issue a bazillion SET-TARGET requests?
>    > 
>    > Yup, you have to issue your bazillion requests.
> 
>    That simply blows.
> 
> I agree.  A bazillion requests is a lot of requests.

Heh.

>    Hmm. I just thought of something. Assume you have two people: Joe checks in
>    a bunch of stuff, creating new version resources. He then follows with a
>    bunch of SET-TARGET methods, so the VCRs get update. Jane fetches the VCRs
>    and sees his changes.
> 
>    Now... what if Joe was replaced by an automatic process? From Jane's
>    standpoint, she doesn't care *how* the VCRs are updated, just that they are.
> 
>    In other words, I might argue that the server can pretend there is somebody
>    out there updating all the VCRs in the repository to point to the "latest"
>    revision. The logs don't show it :-), but it is happening.
> 
>    Does the spec forbid this? :-)
> 
> Nope.  All you lose is interoperability (because your client is unlikely
> to get this behavior on any other server, and another client would be 
> surprised to see this happen on your server).

Agreed.

> BUT, I believe what you want to happen is very reasonable, so if the MERGE
> proposal works for you, we have a nicely interoperable way for you to tell
> your server what to do.

Yes. But I think 10.13 doesn't make it clear that any resources that are
checked-out (into that activity) will be checked in first. I'm just thinking
a bit of prose in the intro of the section. A careful reading of the
precondition and postcondition implies this, but some text would be great.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Received on Friday, 22 December 2000 05:05:51 UTC