[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Repository UUID Implementation

From: <cmpilato_at_collab.net>
Date: 2003-01-09 07:50:48 CET

Greg Stein <gstein@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
Received on Thu Jan 9 07:52:15 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.