> About the way revision numbers apply to the whole repository:
> - don't they increase incredibly quickly?
> - isn't it confusing when a file's revision changes even though it itself
> has not?
The version applied to the whole repository has some very nice
properties for our implementation; it's not clear that it's as nice
for the user. If it becomes a sticking point, it should be possible
to design user interfaces which present higher-level concepts than
commit numbers.
> - what support can Subversion offer for distributed working? We have
> offices all over the place, and the network connections are not
> always as fast or as reliable as we could wish.
You can use a standard web cache to improve access time to the
repository for read-only tasks. I remain unsure whether Subversion's
design will lend itself to more sophisticated distributed work models
like bitkeeper does; the whole repository version kind of assumes
there is exactly one repository with everything init.
> - the main problem area of CVS that Subversion does not (yet) appear
> to improve upon is modules.
We have cheap directory copies, but as far as I know we do not yet
have anything like CVS modules (i.e. you can cheaply copy "foo" to
"bar/foo", but you can't make it so that changes to foo are reflected
under bar/foo). I don't recall any discussion of plans for this kind
of support; it should be easier than support for distributed
repositories (since the concept of a single repository version still
applies), but requires some back-end magic we haven't talked about
yet as far as I know.
(Well, maybe that's not quite true. Long ago, we talked about hard
link support, and if you could hard link to a directory that would
give you what you want. But we never followed up on that concept.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006