I want to ask a (perhaps naive) question about how the subversion design
handles directories. It's different from the design for DCMS, and I'ld like
to understand the pros and cons of the respective designs.
In subversion, it appears that each directory is a container object, and
that there is an object in the repository representing the directory. In
many respects, this seems quite natural, but it introduces the need to
update multiple objects atomically when performing a check-in, which is what
originally led me away from it.
In DCMS, the only objects that exist in the repository in the usual case are
the "leaf" objects -- i.e. the files. A branch version consists of a set of
(fsName, repositoryName) pairs [plus some other gorp]. The directory
structure is implicit in the fsName, and containing directories are created
as necessary during checkout. The convention about the implicit creation of
directories in the workspace is that this part of the checkout semantics is
purely the responsibility of the user agent.
This reflects the following assumptions:
1. In general, the directory structure of the source tree exists purely to
provide containership; most of the time there is no semantic content to the
permissions or ownership of these directories, and indeed most of the time
we would like these things to be determined by the developer's environment,
not the CM system.
2. In the exceptional case, it may be desirable to have leaf directories. In
such cases we can add entries for them.
3. Files are not the only thing we may wish to handle, and it is undesirable
to build into the name binding mechanism any implicit assumption that the
developer namespace is a file name space as opposed to (e.g.) a class name
space.
A disadvantage to the DCMS approach is that you cannot refer easily to "the
current state of a given directory and it's descendants". My personal
feeling is that this is a problem for which pattern matching is a better
solution, but the "container+descendants" thing is something that many
people seem to feel is important.
So finally my question: is there any reason at all for directories to exist
as independent entities? Aren't they just an accident of the namespace
conventions of the development environment? What advantage is obtained by
representing them explicitly?
shap
Received on Sat Oct 21 14:36:05 2006