Re: long... Re: Working collections

On Wed, Nov 22, 2000 at 04:36:29PM -0500, Geoffrey M. Clemm wrote:
>    From: Greg Stein <gstein@lyra.org>
>
>... version histories, overwrites ...
>...

>    But we still have the various problems of setting the targets of the
>    selectors in the members. SVN never really deals with targets, it wants to
>    work mostly with version resources. Why? Because it copies all the resources
>    to the local disk and you edit them there.
> 
> If it is going to copy all of the resources to the local disk, it has
> to (at least indirectly) tell the server what versions of each resource
> it is interested in.  If it just tells the server this via a "SET-TARGET",
> then the server knows everything it needs to set up the workspace for that
> client.

It is preferable to just talk to the version resource directly, rather than
point another resource (a v-selector) at the v-resource and work thru that.

And when we copy files to the client, we don't leave any information on the
server. That information will only arrive at change/commit time.

>    When you go to do a commit, it
>    needs to work against what it copied (rather than the current target). Thus,
>    it refers to the specific version resource that was copied to the client. It
>    checks that thing out, makes the changes, and checks it in.
> 
> Yes!  Which is one way a workspace is useful, since it keeps track of
> what versions the client has downloaded, as opposed to what is currently
> in the shared "team" area.

As I mentioned... we don't track what was downloaded. There could easily be
thousands of people that have downloaded copies.

[ consider that SVN is intended to replace CVS, and then consider the scale
  of people working against a particular repository (and that most of them
  are simply readers getting copies) ]

>...
>       But
>       why can't my PUT create a working resource? (which implies an eventual
>       creation of a version, a version history, and a version selector as a
>       member of the collection version's extent version selectors)
> 
> That would be a significant change to the current definition of PUT and

It seems that a PUT can create anything on the server. Where does it say
that it cannot create a working resource?

> the definition of a working resource (a working resource just checks out
> a version which must be in a version history).

As mentioned later... the point about a working resource without an actual
version resource does seem a bit whacky, so I'll relent on the "PUT creates
a working resource" model :-)

>...
>    > When you first create a version history, it is given an initial version.
>    > When you put an existing (non-versioned) resource under version control,
>    > the initial version is a copy of the state of the non-versioned resource.
> 
>    That doesn't fully answer the question. The second sentence assumes that I
>    have a non-versioned resource. That step isn't possible. I must be able to
>    go from the null state to a versioned resource.
> 
> If non-version-controlled members of working collections are put under
> version control when the working collection is checked in, I believe
> that you get what you need (and don't have to go from the null state
> to a versioned resource).

Agreed.

>    I believe the answer is that a working resource might not have a
>    DAV:checked-out property.
> 
> That significantly complicates the semantics of a working resource, which
> I'd like to avoid.

Agreed.

>    How were other people thinking of modelling the creation of a versioned
>    resource? Are people assuming that this is a non-atomic creation? (check out
>    the parent, put a resource, version-control it, check in the parent; and
>    deal with the race between the PUT and the VERSION-CONTROL when the resource
>    may not be version-controlled?)
> 
> You can just lock the resource to make sure nobody messes with it between
> the PUT and the VERSION-CONTROL.

There is also a read-consistency race in that situation. I'm thinking that
will apply to anybody using the checked-out version selector model.

[ which, thankfully, means I don't have to deal with it :-) ]

> One reason not to allow you to version
> control a "null resource" is that servers will often have a very different
> way of versioning things like collections from things like files, and
> won't let you change from one to the other, and with a null resource,
> a server can't guess which one it's going to be.

Good point.

>    ...
>    This is a great model based on the discussion above. But the target issue
>    that you raised still creates problems. The whole reason that I checked out
>    a collection version in the first place was to avoid target selectors that
>    might not be targeted the way that I need them to be :-)
> 
> Remember that a collection version says nothing about the targets
> of its members (it just tells you the names and version history of
> each member).  So if a target selector is not targeted the way you
> want, you just modify the target selector ... checking out and
> checking in the collection or any of its members
> is independent of what target is selected by a target selector.

Agreed. But the point was that I can't go and modify the version selector
because it is the "visible" resource. I would need a workspace to keep the
repointing private. And we've discussed that already :-)

Cheers,
-g

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

Received on Sunday, 3 December 2000 02:44:55 UTC