Our starting point was that there's nothing wrong with the CVS model
(in which directories are indeed first-class objects in the
repository, although not versioned enough unfortunately). So our goal
is "Make it like CVS, but with all the bugs fixed."
CVS is -- well, wants to be -- a system for versioning directory
trees. This may be less general than versioning arbitrary namespaces,
but who's to say we'd make the right "cuts" if we tried to cover many
models instead of one model... Versioning directory trees is a very
useful thing, even if not the only thing.
We did consider a scheme exactly like the one you describe, where the
directory hierarchy is implicit in the names, and much pattern
matching happens. We decided against it for efficiency reasons.
-K
"Jonathan S. Shapiro" <shap@eros-os.org> writes:
> 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