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. >Larry ----------------------------------------------+---------------------------- David Durand dgd@cs.bu.edu | david@dynamicDiagrams.com Boston University Computer Science | Dynamic Diagrams http://cs-www.bu.edu:80/students/grads/dgd/ | http://dynamicDiagrams.com/