Karl Fogel wrote:
>Garrett Rooney <rooneg@electricjellyfish.net> writes:
>
>
>>i'd say that we always dump the UUID when dumping revision zero of a
>>repository, and provide an svnadmin command to allow setting it. that
>>way we minimize the foot-shooting potential. people won't
>>accidentally screw up their working copies by accidentally changing
>>their repository's UUID, and for those (rare as far as i can see)
>>situations where one wants to change it you have the ability to.
>>
>>
>
>If the UUID is implemented as a revprop, then we must dump and load it
>like any other property. When the dump/load process starts
>special-casing certain kinds of repository data, we're doomed :-).
>
>If the administrator wants to tweak that revprop before or after the
>dump/load, that's her business.
>
>
>
This whole discussion merely confirms my suspicion that we've put way
too little thought into a) what repository UUIDs are good for, and b)
how to implement them.
Givent that, -1 on this change until we have a clear design, including
documenting and solving these corner-case side effects, outlining an
upgrade path, etc. ad nauseam. If that means we don't get UUIDs in the
repository for another month or two or six, so be it.
As I said elsewhere, we can't continue with this hack-and-test approach
to core repository/filesystem features. If we want to see a 1.0 in the
next three months, we have to stabilize things now. I'd be much happier
without repository UUIDs in 1.0 that with a design/implementation that
doesn't address even the first-order side effects satisfactorily.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 16 04:50:28 2002