NOTE: this document is not at all incomplete. In fact, it only captured a couple questions that I had, way back in Oct 2000. It hasn't been touched until today (Feb 2002).
> 2) Activities, Changes Sets, Branches, Workspaces, Baselines, Merging, and > Collections are a significant number of concepts. Is there any specific > documentation that describes (preferably in UML static diagrams with example > instance diagrams) the definitions and relationships to each other for these > concepts. Not yet, see above :-) > If not, can you briefly describe the relationships among these > concepts? Activities and Change Sets are basically the same. You could also view an Activity as a lightweight branch -- work is performed within the activity, then checked in / merged to the main trunk. No branching, per se, is performing. Branches are not explicitly discussed, but can be created simply by having a couple versions of a resource point to the same predecessor (and vice-versa, a version would have multiple successors). In other words, branches are entirely based upon the graph of predecessors/successors. Workspaces are a way to view a group of resources. Rather than going "elsewhere" when a working resource is created (by a CHECKOUT), the working resource is "in place" in a workspace. This allows the workspace to mirror the "live" URL namespace, and for editing to take place within that view. [ contrary: a working resource (when you aren't operating within a workspace) can be placed anywhere and groups of working resources may not mirror the live URL namespace (i.e they could be flat) ] Baselines is a way to establish a resource which represents a cross-section of the URL namespace version space. I'm not entirely clear on its use, purpose, and/or rationale, but it seems to map very closely to a "configuration" (in the Configuration Mgmt sense). Merging is simply the process of merging resource's versions together (within the various forms of operational models). e.g. merge an Activity into the URL namespace, or merge changes in a Workspace into the namespace. Collections are the same as in WebDAV.
I did a lot of thinking this week about URLs in DAV responses, w.r.t
international and charset issues.
The & is appropriate. Placing %26 into the URL would alter its meaning.
For example, assume we had these two URLs:
http://host.name/path/foo&bar
http://host.name/path/foo%26bar
These two URLs have very different meanings. The former has a "query"
portion, the latter does not (the "&" is part of the path). If we escaped
the "&" in the URL using %26, then the client could not know which form is
intended.
To be fully clear, there are multiple transformations that occur when a DAV
server needs to return a URL corresponding to a resource:
1) Encode the "original characters" which identify the server resource. This
could be a transformation from the server's Unicode charset into UTF-8.
This transform produces an octet form of the URL.
2) Encode the URL octets using standard URL escaping (the %xx stuff). This
is the "normalized form" for a URL, which all clients and servers use.
3) Encode the result for inclusion into the character set of the response
body. mod_dav always uses UTF-8, but it is conceivable the request body
could be in a different character set. For example, we could encode the
response in UCS-2 which would effectively pair NUL bytes with each
character in the URL. The UTF-8 encoding for a URL is an identity
transformation.
4) XML-escape the result for inclusion into an XML document. This translates
"&", "<", and ">" characters into & < and > respectively.
Specifically, mod_dav assumes steps (1) and (3) are identity
transformations. Step 2 and 4 are straight-forward code.