Re: Repository GUIDs again

On Tue, Jan 07, 2003 at 03:16:03PM -0800, Bill Tutt wrote:
>...
> > The only reason to do that is not having to add another RA
> > interface to read the prop, or special-case the existing one
> > to look at the file instead of the FS. Personally, I don't
> > think that's a good technical argument. +1 for putting the
> > GUID into a file.

+1 to keep it out of revprop 0. I'd prefer to see the FS itself know about
the GUID, rather than the "repository". I think the GUID is going to be part
of the copy history, which we record in the FS. Maybe not now, but in the
future. Thus, the FS will know about GUIDs, so we should have the FS handle
the GUID itself (with the appropriate API to fetch it and regenerate it).

> I agree that there isn't a good techincal argument for storing the GUID
> as a rev-prop. Sticking it in a file seems lame by comparison though.
> It's part of the repository, either stick it into a real BDB table and
> load/dump it, or be lazy and use a rev-prop on revision 0.

"part of the repository" can mean in the FS or in REPOS. That is part of the
problem here, so what seems obvious to you isn't as obvious to all :-)

> I honestly don't care either way for 1.0 since there isn't a large
> practical difference between any of these choices, just please give me a
> GUID so I can tweak svn_client_merge. ;)

Right. And the appropriate interfaces to deal with it.

For ra_dav, I think it would be good to make the GUID a live property on one
of the resources somewhere. The VCC comes to mind, as there is only one per
repository. Conceptually, I don't think it makes much sense there, but I
haven't thought thru it too much. But that is just about marshalling. The
larger question right now is "where to store the sucker"

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