Greg Stein writes:
> I'm confused. How the heck does putting a UUID into svn_fs_t result in such
> a fallout? New files!? This sounds brittle and poor encapsulation. It
> seemed like an easy problem. Why is it rippling into such a large issue?
I think it has always been a problem if one process
Greg Stein wrote on Sun, Apr 29, 2012 at 03:32:51 -0400:
> On Apr 29, 2012 2:51 AM, "Daniel Shahaf" wrote:
> >
> > Daniel Shahaf wrote on Sat, Apr 28, 2012 at 11:27:37 +0300:
> > > Greg Stein wrote on Fri, Apr 27, 2012 at 23:45:12 -0400:
> > > > Hey Daniel,
> > > >
> > > > I had four svnadmin test
On Apr 29, 2012 2:51 AM, "Daniel Shahaf" wrote:
>
> Daniel Shahaf wrote on Sat, Apr 28, 2012 at 11:27:37 +0300:
> > Greg Stein wrote on Fri, Apr 27, 2012 at 23:45:12 -0400:
> > > Hey Daniel,
> > >
> > > I had four svnadmin tests dump core due to an assertion: 8, 21, 26,
> > > 27. These are all mar
Daniel Shahaf wrote on Sat, Apr 28, 2012 at 11:27:37 +0300:
> Greg Stein wrote on Fri, Apr 27, 2012 at 23:45:12 -0400:
> > Hey Daniel,
> >
> > I had four svnadmin tests dump core due to an assertion: 8, 21, 26,
> > 27. These are all marked XFail(), so my test run "passed".
>
> AFAIK all of those
AFAIK all of those are due to the same issue: dst_fs->uuid not being
initialized. Philip noted that there are probably worse problems here,
since fs_fs_shared_data_t (ffd->ffsd) holds various locks and caches tat
are indexed by UUID only.
This is at the top of my 'svn' todo list. (but that list
5 matches
Mail list logo