[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 4087] bogus repos_id in wc.db for file externals

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Tue, 14 Feb 2012 00:43:30 +0200

Stefan Sperling wrote on Mon, Feb 13, 2012 at 23:39:30 +0100:
> On Tue, Feb 14, 2012 at 12:27:21AM +0200, Daniel Shahaf wrote:
> > stsp_at_tigris.org wrote on Mon, Feb 13, 2012 at 13:10:47 -0800:
> > > http://subversion.tigris.org/issues/show_bug.cgi?id=4087
> > >
> > >
> > >
> > >
> > >
> > >
> > > ------- Additional comments from stsp_at_tigris.org Mon Feb 13 13:10:47 -0800 2012 -------
> > > r1243694 attemps to work around the reported problem that prompted me to file
> > > this issue. It ensures that all file externals use the same repository root URL
> > > as used by other files. I.e. whatever the svn:externals propery says, we'll use
> > > the URL to the repository that the working copy (or checkout) is using, provided
> > > the repository has the same UUID.
> >
> > How likely is this to break things?
> >
> > I know that UUID's are supposed to be unique. But in practice, if
> > people _do_ have different repositories with the same UUID, this will
> > break in odd ways. How likely is that if()'s condition to occur?
>
> We rely on UUIDs being unique in other cases, too, don't we?
>

Such as?

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.
Received on 2012-02-13 23:44:14 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.