Branko Čibej <brane@xbc.nu> writes:
> 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.
+1 on Brane's -1, for the reasons he gives above :-).
However, I think the dump/load question might be the only corner case
associated with having a UUID in the repository (there will be many
more corner cases when we start *using* them, of course, but we're not
implementing that part yet).
So if we can figure out a good way to handle this case, and satisfy
ourselves that there isn't another nasty question lurking, then we can
implement them before 1.0. But we clearly need to think more about
them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 16 07:57:23 2002