> From: Branko Cibej [mailto:brane@xbc.nu]
> Ben Collins-Sussman wrote:
>
> >Karl Fogel <kfogel@newton.ch.collab.net> writes:
> >
> >
> >
> >>"Bill Tutt" <rassilon@lyra.org> writes:
> >>
> >>
> >>>That makes sense. However, I think I'd rather just have
> the rev-prop
> >>>modification code (above the level that svnadmin would use
> to change
> >>>it) disallow the changing the property be hardcoded.
> >>>
> >>>
> >>Yah, +1, people replace/rewrite hooks all the time.
> >>
> >>
> >
> >[Beating a dead horse]
> >
> >I still much prefer the idea of a GUID living in a normal
> file, next to
> >'format'. In my mind, the GUID is a property of the
> *repository*, not
> >the filesystem. From a design standpoint, I think of the
> filesystem as
> >just a mindless data store, whereas the repository is the more
> >interesting wrapper with a unique identity (GUID) and unique
> policies
> >(hooks).
> >
> >I can't remember... did someone have a good technical argument for
> >storting the GUID as a revprop?
> >
> >
>
> 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.
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.
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. ;)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 8 00:16:48 2003