On 25 Jul 2001 14:59:13 +0100, peter.westlake@arm.com wrote:
> My name is Peter Westlake, and I work in the Development Systems part of
> ARM, looking after builds and source control. I am looking into possible
> replacements for CVS, and Subversion seems like a natural candidate. It has
> the usual advantages of free software, and it will be familiar to our CVS
> users. It also uses one of my favourite algorithms, "shadow paging" (the
> "bubble-up" method of updating the repository atomically), and it all seems
> very well thought out.
>
> I have some questions. Starting with the easy ones:
>
> About the way revision numbers apply to the whole repository:
> - don't they increase incredibly quickly?
>From experience with other project-based versioning systems, they don't
increase all that quickly - but what's more important is that you look
at version numbers a *lot* less. In a project-based system, you're
always looking at *consistent project versions*, and you don't worry
much about the version number. You pretty much use either the current
version, or some particular past version that was marked with a label.
> - isn't it confusing when a file's revision changes even though it itself
> has not?
It doesn't. There's a mindset change when you start using
project-oriented
versioning. You don't think in terms of "file revisions" - it's *project
versions*. And just because the project version changed doesn't mean
that
you're necessarily dealing with a different file version. It's *not* the
case that every time you create a new project version, it automatically
creates a new revision of every file. File revisions continue to happen
in essentially the same what that they would in a file-based system; but
you *never* look at file revision numbers.
> Then the hard ones:
>
> - 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.
Subversion is building WebDAV support, which will allow remote access
with a much more rational protocol than CVS. I suspect that the WebDAV
remote access will be much more robust in the face of slow or unreliable
network connections that CVS ever was.
> - the main problem area of CVS that Subversion does not (yet) appear to
> improve upon is modules. CVS modules are badly broken, in that you have to
> hack around in the internal files of the repository to set them up, and the
> module structure is not versioned. So if I make a module include another,
> and check out the parent module from a date before I did that, I get the
> included module. What scope is there for putting a fully versioned module
> mechanism into Subversion? I get the impression that it ought not to be
> that difficult if approached in the right way. Such an implementation would
> have to support recursive operations, e.g. branching a module and all its
> sub-modules. Of course, this isn't always what you want, so there would
> have to be two ways to define a sub-module: one where the sub-module would
> be thought of as "part of" the parent module, and branched with it, and one
> where it would be thought of as "referenced by" or "linked to" the parent,
> so it would not be branched. Instead, both branches of the parent module
> would point to the same sub-module. There is also the orthogonal
> distinction of static vs dynamic sub-modules, which corresponds roughly to
> using a tag or a branch. If a module contains a static link to another,
> then any checkout of the parent module will get the same revision of the
> sub-module. With a dynamic link, it gets the tip. If the parent module is
> checked out from some time in the past, it would get the revision of the
> dynamic module current at that time.
I don't know what subversion is doing here. I'm working on a different
system which I hope to open-source this fall, and which does handle
subprojects (what you're calling "modules") correctly. We've spent a lot
of time thinking about how to get this kind of thing correct with
respect
to the tradeoffs between strong consistency guarantees and flexibility.
It turns out to not be that hard to do. Once our system becomes open,
then the subversion team will be more than welcome to browse our system,
see what we did, and then implement it for Subversion. There's
absolutely nothing
about Subversion that seems to be incompatible with the subproject
notion, so I don't think that it should be any problem for them to do.
-Mark Chu-Carroll
---------------------------------------------------------------------
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