Re: Minutes Delta-V breakout meeting 14-Dec-00

Greg,
Glad to see we're hitting some our your issues.


A third model: the client does a CHECKOUT to get a working resource, then
does a bunch of PUT/PROPPATCH to that working resource. When the client is
done, it does a CHECKIN.
<jra>This was the model Tim was referring to, he just left out the 
checkout. The checkout can be done either when the client gets the 
resource to indicate an intent to change and/or reserve the resource, or 
when ready to do the updates on the server. The protocol can support 
either policy.</jra>

>...
> Suggested that there be no branching in core, no labels in core, but 
that
> there should be a version history available in core.

Um. Why? At the moment, I'm not seeing a need for these in Subversion. I'd
like to understand the need for these in the core.
<jra>The purpose of the version history resource is just to provide a 
place to get information about the versioned resource, and to provide a 
resource the server can iterate over in a report/list. This is in case 
there are no version-controlled resources on a version and it becomes 
"lost".</jra>


Couldn't you do this with a property report, fetching the DAV:activity-set
for each version resource identified by DAV:version-set of the version
history resource?
<jra>We could, but this is likely to be a common operation, especially 
just before merging an activity into a a workspace.</jra>