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.
Actually, why again did we decide to store it as a revprop on 0?
One objection is theoretical: this is a property of the repository,
not the filesystem, and it's conceptually cleaner to store it in the
repository outside the fs db (maybe as a file next to `format' or
something).
But there are practical concerns mirroring theoretical objection:
Suppose you do an 'svnadmin dump' of *all* revisions from repository
A, then you load that into repository B starting at HEAD of B. Are we
going to remember to special case this one revprop? Yuck. But it
would be kind of weird for B to have this prop with different values
on both rev 0 and some random future rev.
I can't think of any other examples than that right now, but somehow
it just feels wrong to be putting repository policy into the fs. I
realize that it would give us GUID querying "for free", via the svn
client and existing protocols, but I'm not sure that's worth the
conceptual messiness.
I'd rather we just had a file `GUID', next to `format' in the top
level of the repository, and a new RA interface to query it...
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 7 23:52:56 2003