On Tue, Feb 14, 2012 at 12:43:30AM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Mon, Feb 13, 2012 at 23:39:30 +0100:
> > We rely on UUIDs being unique in other cases, too, don't we?
> >
>
> Such as?
grep -r UUID shows "svn relocate" as one example.
> The design of wc-ng assumes that, but I don't know offhand how much we
> actually _rely_ on that in today's wc.db-per-working-copy era.
>
> > There is a real actual problem here where at least one user cannot check
> > out old revisions with 1.7, which they can check out with 1.6.
> > I would tend to give fixing this regression higher priority than people
> > running into problems because they have set up their UUIDs the wrong way.
>
> Sure, people who misuuid just invite trouble. But I still wonder if
> this is the sort of change that merits a release notes entry.
Of course, there are valid reasons for repository UUIDs to match.
E.g. when a write-through proxy setup is used. So this is a bit
muddled and depends on what the UUID identifies -- a particular
repository, or a repository with particular content.
Essentially, the user decides which one of these possibilities applies.
But if this change breaks anything because of UUID problems, it hits
people who have a broken setup. After all, file externals must come from
the "same" repository, and the UUID exists to tell whether any given URLs
point to the "same" repository. I don't think we need to take special
precautions at our end for this.
I'd rather be concerned about other side effects in behaviour.
This is about file externals, after all, so who knows what might break :)
For this reason I've asked the original reporter to test the patch, too.
Our regression tests are happy with this change, FWIW.
Received on 2012-02-14 00:11:24 CET