Brad Appleton wrote:
>> I used to think I liked the idea of revision labels. I don't anymore.
>> What I just realized is this: revision labels really aren't enough. A
>> revision number only specifies the y-coordinate. It wouldn't be
>> useful (for me at least, my repository root isn't my trunk). Besides,
>> as I use svn more and more, I have url-related frustration less and
>> less. It's just not that bad (but I never used CVS).
>
>
> One common "3-D" view of version repository is the "elements x
> revisions x variants" model (which I first recall reading about in the
> I-SCM2 proceedings by Lars Bendix, Vincenzo Ambriola: "Object-Oriented
> Configuration Control")
>
> Basically they break it down into three dimensions:
> * elements: the set of things being versioned (files, or objects or
> logical record)
This is what we call a "node" in Subversion...
> * variant: a particular long-lived variation or "flavor" (e.g., for as
> platform, or a market-line)
This is (almost) equivalent to a branch...
> * revision: what most of us think of when we see the term revision
And this is a node revision.
> This defined a 3D space. If I chose revision X.Y of ALL elements for
> ALL variants, I got one set of things. Usually I need to specify
> something concrete for all three (file-set, variant-name, revno) to
> get a "consistent configuration"
>
> What I beleive is being mentioned above is that SVN revision numbers
> assume the applicable "collection" is the entire repository, when in
> fact many want to have some rev-numbers apply only to some subset
> (usually rooted at some directory somewhere on the directory-tree)
Subversion lets you easily index a "plane" in that 3D space defined by
the revision and the variant, and where the variant selection is
constrained by our folding of branches and directories into a single
namespace.
> For SVN, a branch-name could "naturally" correspond to a variant, a
> directory could correspond to a "collection", and the revnum could
> correspond to the directory (or course that wouldnt allow me to
> include versions of files from different branches in the same "named
> configuration" but then again I may not need that for SVN).
Well, you can create pretty much any kind of named configuration (by
carefully preparing a mixed-revision/switched working copy then doing an
"svn cp WC->URL"), but that's forcing SVN to do something it wasn't
designed for. The fact that SVN doesn't treat configurations as
first-class objects pretty much forces you to use CM patterns that only
rely on that subset of configuration space that can be represented as
branches.
> I suspect folks would still want the "mnemonic" to correspond to the
> revision-number (at least by default). If there were a way to either
> restrict it to a subtree of the repo, or else qualify it by a specific
> directory (which I think a URL would be a natural fit for) then I
> think that would do the trick.
I think "restrict to a subtree" and "qualify by specific directory" are
one and the same thing in Subversion. And once your mapping is
label -> (revision, URL)
the label is exactly equivalent to an immutable branch -- a tag. The
repository-root part of the URL can't be part of the mapping, so
(revision, URL) is really (revision, path-in-repo). I doubt that
encoding the repository path in the label is worth the added complexity,
as long as historical revisions are immutable. Which they are, if we
ignore nasty things one can do with a dump/filter/load cycle.
> So given that, I think the mnemonic revname is still useful, and I can
> qualify/restrict by giving a directory.
The mnemonic revision name is useful, since it allows you to merge or
split repositories without having to worry about changing revision
numbers. Here's a longish thread about a proposal I made about a year ago:
http://svn.haxx.se/dev/archive-2004-04/0973.shtml
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 7 05:15:45 2005