You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by mark benedetto king <mb...@earthquake.boredom.org> on 2003/01/09 00:59:55 UTC
Repository UUID Implementation
1.) They're UUIDs, not GUIDs.
APR calls them UUIDs.
I prefer "UUID" to "GUID".
We don't want to imply any terra-centric bias for svn. Xenophobia is
an insidious form of bigotry that must be stamped out at the root. :-)
2.) They should be accessed via a New RA Method.
They don't fit perfectly into any of the existing methods (for
example, exposing them as distinguished rev-props complicates the
rev-prop code-path).
We'll probably eventually want to add repository metadata accessor
methods to the RA vtable; we might as well do it now, before 1.0.
3.) They should be stored in a New FS Table
They have to be stored somewhere. Storing them anywhere but somewhere
new almost certainly means complicating the code that already uses
the old location. "Somewhere new" means, basically, one of
a.) a normal file, like the "format" file
b.) an FS table
For storing a single, rarely changing value, a normal file would
probably be fine. Later, when we want to store other pieces of
repository metadata (a text description, perhaps, to support "svn info
URL"), or when we want to associate node-revisions with other
repositories, we'll probably need a tabular persistence mechanism.
We might as well bite that bullet now, rather than later.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Repository UUID Implementation
Posted by Bill Tutt <ra...@lyra.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
>
> On Wed, Jan 08, 2003 at 11:42:22PM -0600, Karl Fogel wrote:
> >...
> > Heh, I think we're being way premature here :-).
>
> *shrug* Doesn't matter much to me. All the stuff is flexible.
>
Indeed, I don't care much either. This merge history stuff I'm going to
be recording is mostly just so that I can write a wrapper script to
figure out what my next argument list to svn merge is going to be, and
so that future repository loads can make use of the information. I don't
need to record GUIDs outside of the properties I'm going to be setting
anyway. It'd be handy if it did, but it's not that big of a deal either
way. Properties are stored via svndiff reverse deltas anyway, and the
properties that I'll be tweaking will always be very short property
values anyway.
Just for the record, what I plan on doing for svn merge history
recording is to tweak the WC layer into recording just the merge command
arguments for each invocation on the WC before the merged in changes
have been submitted for approval. If no merges happen on a
not-modified->modify text->submit cycle then the property that gets
submitted will be automagically emptied so that the recorded merge
parents of this submit are correctly empty. This nicely obviates all of
our disagreements about how best to organize and or cache this
information so it's available in a more optimal fashion.
> >...
> > Just stick it in a file in the top level and be done with it.
>
> Well, the FS can't see it there. I do believe it is part of
> the FS and its API. Even though we may not be using it for
> everything today, I think it is good to put it into the
> right/final resting place.
>
> >...
> > I don't think the "K.I.S.S." principle applies equally
> well in all
> >situations... But it's especially apt in situations like this one,
> >where one doesn't really know what one is going to do next.
>
> Fair enough. I guess it depends on what is considered
> "simple". I figured a small RECNO table with one record was
> pretty simple. But hey :-)
>
That's what I've been thinking for a while, but people keep disagreeing
with me. Now that you're agreeing with me, I think that's a sign that
those other people are probably wrong. ;)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 08, 2003 at 11:42:22PM -0600, Karl Fogel wrote:
>...
> Heh, I think we're being way premature here :-).
*shrug* Doesn't matter much to me. All the stuff is flexible.
>...
> Just stick it in a file in the top level and be done with it.
Well, the FS can't see it there. I do believe it is part of the FS and its
API. Even though we may not be using it for everything today, I think it is
good to put it into the right/final resting place.
>...
> I don't think the "K.I.S.S." principle applies equally well in all
> situations... But it's especially apt in situations like this one,
> where one doesn't really know what one is going to do next.
Fair enough. I guess it depends on what is considered "simple". I figured a
small RECNO table with one record was pretty simple. But hey :-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
> [ and as Tutt noted at some point, storing a UUID a gazillion times across
> the DB gets expensive; thus, I figured that storing indices into a RECNO
> database would be good, with idx==0 being "self" ]
>
> [...]
Heh, I think we're being way premature here :-). We have no idea yet
how we're going to record cross-repository history; even if we do end
up using a new table that maps small numbers to UUIDs, *this*
repository's own UUID is still special, since it is the one handed out
as a source identifier for data coming from this repository. Just
stick it in a file in the top level and be done with it. If we end up
recording ancestries in a table, then this UUID can still be stored in
that table like any other (and we'll be better off for treating it
just like any other UUID, instead of depending on it being record
number 0 or whatever).
I don't think the "K.I.S.S." principle applies equally well in all
situations... But it's especially apt in situations like this one,
where one doesn't really know what one is going to do next.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 09, 2003 at 12:50:48AM -0600, cmpilato@collab.net wrote:
> Greg Stein <gs...@lyra.org> writes:
> > > Hmm...I don't like it. This a *Repository* UUID, connected in no way
> > > to a versioning filesystem with a stated goal of usefulness outside
> > > the context of Subversion.
> >
> > And a stated goal for recording cross-repository copy/merge history. And to
> > do *that* right, it goes into the filesystem.
>
> Admittedly, I'm not sure what the big picture is for cross-repos
> copy/merge history. But technically, I don't think that the
> filesystem has a stated goal of recording that data. Subversion does.
To me, the thought process was pretty simple:
1) Does the filesystem record copy/merge history? Yes
2) In the future, would that include a UUID for a source? I'm 95% sure
Thus, I see the UUID as a feature of the filesystem. You could say that "it
cares" :-)
> But then I realize the obvious answer to the question. We use
> rev-props for commit information because that is metadata on a
> per-revision basis.
Agreed. I'm not sure where that came from :-)
Cheers,
-g
ps. making a distinction between "filesystem" and "Subversion" is a bit
strange, honestly. Just what is the filesystem for? :-) The filesystem is
supposed to work for us first, and be "theoretically pure" somewhere below
that. Having the FS have an identity sits quite fine with me.
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by cm...@collab.net.
Greg Stein <gs...@lyra.org> writes:
> > Hmm...I don't like it. This a *Repository* UUID, connected in no way
> > to a versioning filesystem with a stated goal of usefulness outside
> > the context of Subversion.
>
> And a stated goal for recording cross-repository copy/merge history. And to
> do *that* right, it goes into the filesystem.
Admittedly, I'm not sure what the big picture is for cross-repos
copy/merge history. But technically, I don't think that the
filesystem has a stated goal of recording that data. Subversion does.
> I found Greg Hudson's review and summary to be excellent. Tutt pulled out
> the link earlier, but I'll repeat it here:
>
> http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=215400
>
> Under the "USES" section, I find the bottom three make a good argument for
> putting this stuff at the filesystem level.
I like his review, too. Well-considered, in true Hudson style. I
wasn't convinced by reading it that the UUID belongs in the
filesystem. The one thing that came close to making me consider it
was this:
* We should try to be architecturally consistent. If we don't use
rev-props for the guid because we don't want to complicate the
ends of the properties pipe, then did we make the right choice to
use rev-props for commit information?
But then I realize the obvious answer to the question. We use
rev-props for commit information because that is metadata on a
per-revision basis. The UUID isn't supposed to change over time.
Ever. It's lifetime should be the same as the lifetime of the whole
repository, which makes attaching it as metadata to a single revision
quite arbitrary. Also note that there is no filesystem-internal-use
precedent -- no part of the filesystem knows that a thing called a
"commit message" or a "commit author" exists. That's a repos concept.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jan 09, 2003 at 12:50:56AM -0500, Greg Hudson wrote:
> On Thu, 2003-01-09 at 00:32, Greg Stein wrote:
> > Yup. I was thinking the same thing in the car earlier. A bit different than
> > your idea, tho. I was thinking of a RECNO database, with each record being a
> > UUID. Index 0 would the "self" UUID. The other indexes would represent UUIDs
> > of other repositories which participating in merges/copies into "self". This
> > would support the notion of recording copy/merge history like so:
> >
> > $ svn cp http://svn.apache.org/repos/asf/apr \
> > http://svn.collab.net/repos/svn/apr
>
> So, I don't really feel strongly about where we store UUIDs. But I
> don't want to see us designing a table designed to accomodate
> information about *other* repositories before we know that it's
> necessary and how it will be used.
Sure. In all likelihood, initially, the table will just contain a single row
and that'll be it. mbk's approach defined a "metadata" table; again, with
just a single value in it.
*shrug* Any approach is really going to be about storing a single value,
and we're only guessing about future uses. I just liked my forward vision
more than mbk's ;-)
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by Greg Hudson <gh...@MIT.EDU>.
On Thu, 2003-01-09 at 00:32, Greg Stein wrote:
> Yup. I was thinking the same thing in the car earlier. A bit different than
> your idea, tho. I was thinking of a RECNO database, with each record being a
> UUID. Index 0 would the "self" UUID. The other indexes would represent UUIDs
> of other repositories which participating in merges/copies into "self". This
> would support the notion of recording copy/merge history like so:
>
> $ svn cp http://svn.apache.org/repos/asf/apr \
> http://svn.collab.net/repos/svn/apr
So, I don't really feel strongly about where we store UUIDs. But I
don't want to see us designing a table designed to accomodate
information about *other* repositories before we know that it's
necessary and how it will be used.
(I'm open to being convinced that we do need to store information about
other repositories, but right now it sounds like a bad idea. And, I'm
not saying that we should never support cross-repository copy history;
I'm just not convinced that you need to know anything about the other
repositories in order to do it.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by mark benedetto king <mb...@earthquake.boredom.org>.
On Wed, Jan 08, 2003 at 09:32:53PM -0800, Greg Stein wrote:
> On Wed, Jan 08, 2003 at 07:13:04PM -0600, cmpilato@collab.net wrote:
> > mark benedetto king <mb...@earthquake.boredom.org> writes:
> >...
> > > 3.) They should be stored in a New FS Table
>
> Yup. I was thinking the same thing in the car earlier. A bit different than
> your idea, tho. I was thinking of a RECNO database, with each record being a
> UUID. Index 0 would the "self" UUID. The other indexes would represent UUIDs
> of other repositories which participating in merges/copies into "self". This
> would support the notion of recording copy/merge history like so:
>
If the database is to contain *only* UUIDs, then RECNO would be fine; UUIDs
are fixed-length. Is that all we would want?
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by Greg Stein <gs...@lyra.org>.
On Wed, Jan 08, 2003 at 07:13:04PM -0600, cmpilato@collab.net wrote:
> mark benedetto king <mb...@earthquake.boredom.org> writes:
>...
> > 3.) They should be stored in a New FS Table
Yup. I was thinking the same thing in the car earlier. A bit different than
your idea, tho. I was thinking of a RECNO database, with each record being a
UUID. Index 0 would the "self" UUID. The other indexes would represent UUIDs
of other repositories which participating in merges/copies into "self". This
would support the notion of recording copy/merge history like so:
$ svn cp http://svn.apache.org/repos/asf/apr \
http://svn.collab.net/repos/svn/apr
> Hmm...I don't like it. This a *Repository* UUID, connected in no way
> to a versioning filesystem with a stated goal of usefulness outside
> the context of Subversion.
And a stated goal for recording cross-repository copy/merge history. And to
do *that* right, it goes into the filesystem.
As I said before, there is a question outstanding on whether the UUID is a
repository or a filesystem concept. I believe it belongs in the filesystem
because of cross-repos stuff. Tracking that is for the repos.
[ and as Tutt noted at some point, storing a UUID a gazillion times across
the DB gets expensive; thus, I figured that storing indices into a RECNO
database would be good, with idx==0 being "self" ]
So given that there is a question of where it belongs, I'd recommend
tempering the asterisks back down to a less forceful discussion :-)
I found Greg Hudson's review and summary to be excellent. Tutt pulled out
the link earlier, but I'll repeat it here:
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=215400
Under the "USES" section, I find the bottom three make a good argument for
putting this stuff at the filesystem level.
> I *do* like the idea of the repository having a generic metadata
> storage facility, but I'd almost rather use a separate database
> environment (lightweight DBM or something) than add a table of
> non-filesystem-related stuff to the filesystem.
Out of scope for me, so no comment...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by cm...@collab.net.
mark benedetto king <mb...@earthquake.boredom.org> writes:
> 1.) They're UUIDs, not GUIDs.
Whatever. :-) But consistency with APR is goodness, so +1.
> 2.) They should be accessed via a New RA Method.
Sounds good.
> 3.) They should be stored in a New FS Table
Hmm...I don't like it. This a *Repository* UUID, connected in no way
to a versioning filesystem with a stated goal of usefulness outside
the context of Subversion.
I *do* like the idea of the repository having a generic metadata
storage facility, but I'd almost rather use a separate database
environment (lightweight DBM or something) than add a table of
non-filesystem-related stuff to the filesystem.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Repository UUID Implementation
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Okay, I'm officially bikeshedded now -- put the UUID in a new FS table
if you want, or in a file. Just not as a rev 0 prop, that one really
*is* inappropriate :-).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
RE: Repository UUID Implementation
Posted by Bill Tutt <ra...@lyra.org>.
> From: mark benedetto king [mailto:mbk@earthquake.boredom.org]
>
<....>
> 2.) They should be accessed via a New RA Method.
>
> They don't fit perfectly into any of the existing methods (for
> example, exposing them as distinguished rev-props complicates the
> rev-prop code-path).
>
> We'll probably eventually want to add repository metadata accessor
> methods to the RA vtable; we might as well do it now, before 1.0.
>
Wouldn't it be easier if the data was always made available as a
property of SVN directory collections? This way the data would get
migrated into every WC entries file quite simply. Additionally, this WC
property would help solve the UI application problem of determining
which repository each WC directory belongs to, and thus can inffulence
how the UI groups changes into Subversion transactions.
This could also make traversing intra-repository modules during svn
submit easier to accomplish as well.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org