Re: Re2: what's doable in Web version control

David G. Durand (
Wed, 12 Jun 1996 14:30:18 -0400

At 6:13 PM 6/11/96, Larry Masinter wrote:
>> 1) you want to send in updates for different resources (e.g. a file AND its
>> ancillary images, all modified in the meantime), and want a single commit
>> for all of them -- and this is, I understand, *evil*.
>Yes. Is Good. Is Excellent, Even. Not Evil. Not Bad.

This functionality (multi-document transactions) is necessary, even,
although it could be implemented by separate VC operations that groups
specific updates together into transactions. I think that it's a
configuration and not pure versioning issue, though.

Note, that in the long run, we may need explicit operations to do
multi-document commit because commit might cross server boundaries. For
instance the documentation and coding groups in a complany might have
separate VCS, that need simple coordination. Or we can assume that
multi-server systems will implement any such stuff within their backends
via application-dependent inter-server protocols, and leave this out.

I think that the multipart can be extended a bit, as we might want several
data types in a single modification request: eg. VTML for document updates,
something new like "versioned-gif-update" for graphics, and maybe
"text/config" or some other explicit VC operations.

>> 2) you want to send in several updates for the same resource: e.g. I check
>> out a file for the weekend on my laptop, create locally several versions --
>> friday night, saturday afternoon just before the party, and sunday evening
>> because I'm bored -- and check them back in first thing monday morning as a
>> single connection, with the different parts representing the different
>> versions that were created locally. -- This was considered an interesting
>> option for VTML, and one of the main reasons for external deltas.
>This is nice, too. I'm not sure about the locking semantics, though.
VTML can be lock-free, in which case you're not guaranteed what version
you'll get on check-in.

  David Durand         |
  Boston University Computer Science          | Dynamic Diagrams |