On Mon, 2003-04-14 at 01:36, Tom Lord wrote:
> I'm thinking of an FS namespace containing N project trees, and then N
> "lists of changesets" (aka write transaction journals) -- one per
> project tree. Each list is totally ordered -- but without additional
> structure, the set of changesets is not totally ordered.
Ah, right, of course. It's simple either without projects or without
global revision numbers, but complicated with both.
> Indeed. The idea of making a journal of commit records the definitive
> history of the repository and treating everything else as lazy
> caching/memoizing/indexing can speed up/make more space-efficient not
> just native-fs, but other storage managers as well.
You seem to have conceded a different point than I stated. The
app-level changeset journal idea isn't just orthogonal to the choice of
storage manager; it's orthogonal to the idea of project subdirectories.
> >> But on what should we key those caches, indexes, and memos? The
> >> project-tree boundaries, because of the tractable size of the trees
> >> they contain and their relationship to the atomicity of commits, are
> >> ideal.
>
> > Why?
>
> Tractable data set sizes; isolation of (nearly?) all txns.
So, the idea of a well-constructed index is that you can search it or
update it quickly even if the underlying data set grows large.
> For svn-like performance, I was thinking more of roughly a single
> full-text, but with indexed changesets and cached skip-delta
> changesets.
It seems like by the time you're done with this cache, it would look
very much like our current filesystem structure. Certainly, I don't
think it would be any simpler for the introduction of project
directories.
> > Eliminating the revision number by making it effectively part of
> > the path gains elegance in some areas, but loses it in others.
>
> I don't see any losses in what you've described so far.
Right now the filesystem namespace is uniform and owned completely by
the user. (The trunk/branches/tags convention is just a suggestion to
the user; there are no plans to make any Subversion software assume or
enforce the convention.) I consider that elegant. What you're
suggesting makes the top one or two levels of the namespace owned by the
implementation, and introduces the notion of an implicit symlink for the
head revision of a project directory.
On consideration, I don't think you gain any elegance in the UI by
eliminating revision numbers, because you still need to be able to, say,
check out by date, or diff against the previous revision of a file. So
it wouldn't be a simple matter of eliminating the -r option to every
command which currently takes it.
> This distribution thing you keep mentioning:
(I mentioned it twice, once in response to your mentioning it and once
in summary.)
> 1) Gee, you know, actively planning _against_ that seems
> short-sighted.
Not really. I don't see Subversion evolving in that direction. I see
better cross-repository support as a much better direction to look
towards than introducing the concept of partitioning within
repositories. And even if I'm wrong, a central point which does nothing
but assign revision numbers can scale to a really really high level of
throughput; you'd have to have millions of servers before that central
point would become a bottleneck.
> 2) It's a red herring. The same properties that help multi-server
> implementations help get good performance out of single server
> implementations that are simpler and have fewer dependencies on
> 3rd party packages.
I have yet to be convinced that it helps; that's what we've been arguing
about above.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 14 08:46:04 2003