You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@lyra.org> on 2001/03/28 04:34:14 UTC
Re: CVS update: subversion/subversion/tests/libsvn_ra_local Makefile.am
I don't see a problem.
Further, I disagree with the notion of disabling it in CVS so that *nobody*
can run the test, when it would appear to be a problem local to one system.
There's been a lot of "just disable it from the build" recently, it seems.
If you don't want it to build on your machine, then feel free to disable it.
But disabling it in CVS is something to really think about it.
Cheers,
-g
p.s. yes, I know ra-local-test doesn't actually run any tests right now, but
that is not the point
On Tue, Mar 27, 2001 at 11:55:14PM -0000, sussman@tigris.org wrote:
> User: sussman
> Date: 01/03/27 15:55:14
>
> Modified: subversion/tests/libsvn_ra_local Makefile.am
> Log:
> Suddenly tests/libsvn_ra_local/ won't build:
>
> /usr/libexec/elf/ld: cannot find -lneon
>
> Gstein, can you investigate? I'm temporarily disabling this dir's
> build.
>
> Revision Changes Path
> 1.5 +4 -4 subversion/subversion/tests/libsvn_ra_local/Makefile.am
>
> Index: Makefile.am
> ===================================================================
> RCS file: /cvs/subversion/subversion/tests/libsvn_ra_local/Makefile.am,v
> retrieving revision 1.4
> retrieving revision 1.5
> diff -u -r1.4 -r1.5
> --- Makefile.am 2001/03/09 17:53:43 1.4
> +++ Makefile.am 2001/03/27 23:55:13 1.5
> @@ -1,7 +1,7 @@
> ## Makefile.in is generated from this by automake.
>
> -noinst_PROGRAMS = ra-local-test
> -ra_local_test_SOURCES = ra-local-test.c
> +#noinst_PROGRAMS = ra-local-test
> +#ra_local_test_SOURCES = ra-local-test.c
>
> COMMON_LIBS = @SVN_TESTS_MAIN_LIBS@ \
> @SVN_TESTS_EDITOR_LIBS@ \
> @@ -13,7 +13,7 @@
> @SVN_APR_LIBS@ @SVN_EXPAT_LIBS@ -ldb
> ## Shouldn't -ldb be added automatically by the autoconf script?
>
> -ra_local_test_LDADD = ${COMMON_LIBS}
> +#ra_local_test_LDADD = ${COMMON_LIBS}
>
> ## Flags needed when compiling:
> INCLUDES = -I$(srcdir)/.. @SVN_INCLUDES@ @SVN_APR_INCLUDES@
> @@ -25,7 +25,7 @@
> ## Automatic tests run by `make check` -----------------------------
>
> ## A list of test-programs to run. (Each program contains sub-tests.)
> -SVN_TESTS = ra-local-test
> +#SVN_TESTS = ra-local-test
>
> ## We're overriding automake's own `check' rule, because it's extremely
> ## inflexible; we want better control over automated-test output.
>
>
>
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/tests/libsvn_ra_local Makefile.am
Posted by Karl Fogel <kf...@collab.net>.
Joost Baaij <jo...@spacebabies.nl> writes:
> > It's important that the build and test suite be in a happy state in
> > the repository most of the time, to facilitate parallel development.
> > If I've checked in code that breaks "make check", then it's going to
> > be harder for others to test their own changes, even though their own
> > changes might not be related to what I'm doing.
>
> Should anyone be allowed to check in code that breaks any tests?
> Personally I think someone should only commit code when all the tests
> pass on his/her local machine.
The loose rule is "Please don't breake the build or 'make check'."
The best thing is to just make sure the test suite still passes, yeah.
It's okay to break things when avoiding the breakage would cause big
inconvenience for the committer, though. Just make sure to announce
that you broke the build, so others can use previous snapshots (i.e.,
"cvs update -D ...") while the breakage is in effect.
It's also okay to comment out a test. For example, if you need to
commit up so a co-developer can reproduce a problem, but your current
changes break a test, then just disable that test. You'll continue to
work and re-enable it when its ready; in the meantime, the automated
nightly builds & tests won't raise an unnecessary red flag, and other
developers will not be needlessly worried by having their "make
check"s fail.
(Eventually I'll put the above in the HACKING file; just waiting for a
consensus, or at least a lack of objection, from other developers
first.)
Best,
-K
Re: [OT] commit methodology
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Mar 30, 2001 at 01:52:22AM +0000, Tripp Lilley wrote:
> On Thu, 29 Mar 2001, Greg Stein wrote:
> > Trust is a big thing for me. If developers don't trust each other to do the
> > right thing, then the whole project loses productivity. I can go on about
> > this forever, but the main point here is that I feel that installing rules
> > and procedures is a blatant slap in the face, saying that "you must follow
> > these rules because we don't trust you."
>
> On the other hand, there are cases in which rules allow developers immense
> freedom to run wild in their own space, without worrying about adverse
> affects on other developers. This freedom is what motivates me to use the
> branching methodology I use in my own Perforce depot,
Interesting thought, but I feel a bit separate. I've been drinking for
several hours now :-), so I think I'll skip the reparte and get back to the
coding that I need to be doing :-) Suffice it to say, that I feel your
comment about how you work is still separate from the trust issue that I'm
referring to.
>...
> Actually, to satisfy my curiousity, could someone tell me if any of the
> "core team" has significant experience with Perforce? I'm asking because
> the general philosophy and "mental model" of Perforce is sufficiently
> different from that of RCS, CVS, SourceSafe, MKS, and other "children of
> RCS" that it seems a good idea to study it and mine it.
Actually, I've always felt SourceSafe to be quite different from RCS/CVS. It
has a model much more similar to SVN. "copy to branch"
> Yes, I realize I wasn't around six months ago when people were actually
> -designing- all this stuff :) And, no, I'm not asking anyone to revisit
> the design. I'm just wondering if anyone -is- acquainted with the Perforce
> view of the world?
Somewhat. I was talking at length with a Perforce guy a few weeks ago, and
essentially told him that we were going to take away a good portion of his
customers and depress the price that they could charge for their product.
hehe... :-)
>...
> course, it -does- have warts and things I would sorely love to change, but
Please tell us about the warts, so that we don't run into them with SVN. I'm
somewhat familar with the P4 model, but anything that you can describe would
be a help.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [OT] commit methodology
Posted by Tripp Lilley <tl...@perspex.com>.
On 29 Mar 2001, Ben Collins-Sussman wrote:
> Tripp Lilley <tl...@perspex.com> writes:
>
> > Actually, to satisfy my curiousity, could someone tell me if any of the
> > "core team" has significant experience with Perforce? I'm asking because
> > the general philosophy and "mental model" of Perforce is sufficiently
> > different from that of RCS, CVS, SourceSafe, MKS, and other "children of
> > RCS" that it seems a good idea to study it and mine it.
>
> None of us have used Perforce really, and SVN is attempting to
> (mostly) emulate CVS's model, at least in the user interface.
> However, because of the way our repository stores trees, a
> Perforce-using acquaintance of ours has told us that our
> "branches-are-just-subdirs" model is very similar to Perforce.
That's good to hear. I mean "branches-are-just-subdirs", not "emulate
CVS's model" :) When I have cycles (hah!), I'll peer more closely at svn
and see if it might not be possible to build a system that offers
Perforce's worldview. I suspect it -won't- be "compatible" with svn (as in
one can use the same repo in either "cvs-similar" mode or
"perforce-similar" mode), but that it could at least be built upon the
same core code (the svn filesystem, the WebDAV stuff, etc.)
Ah, another research project. Thanks, folks! ;)
--
Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
"Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>
Re: [OT] commit methodology
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Tripp Lilley <tl...@perspex.com> writes:
> Actually, to satisfy my curiousity, could someone tell me if any of the
> "core team" has significant experience with Perforce? I'm asking because
> the general philosophy and "mental model" of Perforce is sufficiently
> different from that of RCS, CVS, SourceSafe, MKS, and other "children of
> RCS" that it seems a good idea to study it and mine it.
None of us have used Perforce really, and SVN is attempting to
(mostly) emulate CVS's model, at least in the user interface.
However, because of the way our repository stores trees, a
Perforce-using acquaintance of ours has told us that our
"branches-are-just-subdirs" model is very similar to Perforce.
Re: [OT] commit methodology
Posted by Tripp Lilley <tl...@perspex.com>.
On Thu, 29 Mar 2001, Greg Stein wrote:
> Trust is a big thing for me. If developers don't trust each other to do the
> right thing, then the whole project loses productivity. I can go on about
> this forever, but the main point here is that I feel that installing rules
> and procedures is a blatant slap in the face, saying that "you must follow
> these rules because we don't trust you."
On the other hand, there are cases in which rules allow developers immense
freedom to run wild in their own space, without worrying about adverse
affects on other developers. This freedom is what motivates me to use the
branching methodology I use in my own Perforce depot, even though I'm the
-only- developer with access to the code! I trust myself, but the rules I
impose on how I use the depot allow me to work without thinking about
-how- I'm working, but rather about -what- I'm working on.
Of course, that entire paragraph makes a bit more sense in the context of
an explanation of the branching methodology I use which is similar, but an
improvement upon, the life-cycle described in Perforce's "Software Life-
Cycle Modelling" paper at <http://www.perforce.com/perforce/life.html> . I
need to document that methodology shortly, anyway, for a colleague, and
will post a link here when I've done so.
In brief, though, every developer has a "development branch" in which they
are free to commit as frequently or infrequently as they like, and in
which they can explore, code, change, as radically as they like, without
fear of corrupting the mainline. When their development branch reaches a
point of stability (where "stability" is up to the developer and the team
to judge based on their own needs), the developer "catches up" with the
mainline (ie: integrates any changes from the mainline into the
developer's branch), then reintegrates the development branch changes into
the mainline for subsequent testing / sharing / release.
This way, there is no question of "breaking the nightly build" or
"stepping on other developers' toes". However, the SCM system's branching
mechanism has to be Supah-Fly to make this bearable. As I mentioned in a
previous post, I'm singularly unqualified to comment on svn's score in
this area :)
Actually, to satisfy my curiousity, could someone tell me if any of the
"core team" has significant experience with Perforce? I'm asking because
the general philosophy and "mental model" of Perforce is sufficiently
different from that of RCS, CVS, SourceSafe, MKS, and other "children of
RCS" that it seems a good idea to study it and mine it.
Yes, I realize I wasn't around six months ago when people were actually
-designing- all this stuff :) And, no, I'm not asking anyone to revisit
the design. I'm just wondering if anyone -is- acquainted with the Perforce
view of the world?
By way of adding to my earlier introduction, I happened upon Perforce
about four years ago when I was just about to give up on all of the SCM
systems I had used up to that point. Nothing "made sense" to me, and I had
a laundry list of features and conceptual gripes that was about to
motivate me to roll my own. I discovered Perforce and literally checked
item after item off my laundry list. It was, for me, a perfect fit, and
grows more so the more I reflect and consider how to best use it. Of
course, it -does- have warts and things I would sorely love to change, but
it lacks that crucial component: source. Which, of course, is what has
lead me to subversion, more or less (though there is an open source clone
of Perforce underway, I wasn't sufficiently moved by what I saw).
Whew. I didn't mean to ramble on this long. Please accept my apologies.
Thanks!
--
Joy-Loving * Tripp Lilley * http://stargate.eheart.sg505.net/~tlilley/
------------------------------------------------------------------------------
"Fiber makes you poop." -- From <http://www.pvponline.com/bts_studio.php3>
Re: [OT] commit methodology
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Mar 29, 2001 at 05:23:37PM -0600, Karl Fogel wrote:
> +1
>
> (When I said "please don't break 'make check'" in my previous mail, I
> meant that how you do that is up to you. Whether you run the test
> suite before every commit is your business -- a matter of personal
> policy. Only when the rest of us start being affected do we get the
> right to nose in. :-) )
Right! :-)
>...
> Greg Stein <gs...@lyra.org> writes:
> > This is a bit off-topic for this list, but what the heck. IMO, yes, people
> > can/should be able to check in stuff according to whatever guidelines they
> > care to impose upon themselves.
Oh, and a bit of backfill here. The above comment assumes that the developer
is capable and responsible :-). Personally, I tend to always trust anybody
with commit access (which sets a bar right there), and let them do their
work as they see fit.
Trust is a big thing for me. If developers don't trust each other to do the
right thing, then the whole project loses productivity. I can go on about
this forever, but the main point here is that I feel that installing rules
and procedures is a blatant slap in the face, saying that "you must follow
these rules because we don't trust you."
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [OT] commit methodology (was: Re: CVS update: ...)
Posted by Karl Fogel <kf...@collab.net>.
+1
(When I said "please don't break 'make check'" in my previous mail, I
meant that how you do that is up to you. Whether you run the test
suite before every commit is your business -- a matter of personal
policy. Only when the rest of us start being affected do we get the
right to nose in. :-) )
-K
Greg Stein <gs...@lyra.org> writes:
> This is a bit off-topic for this list, but what the heck. IMO, yes, people
> can/should be able to check in stuff according to whatever guidelines they
> care to impose upon themselves.
>
> For example, I make changes all the time and never run the test suite. In
> some cases, it is simply to fix a compilation issue caused by an API change
> elsewhere. I know that isn't going to affect the test suite. In other cases,
> the code that I'm working on is not covered by the test suite, so there
> isn't a need to run it.
>
> And your next words will be, "but that code should have a test suite, then!"
> Well, there is a large gap between "should" and "does" :-) When somebody
> wants to build a test suite that can adequately test mod_dav_svn and
> libsvn_ra_dav, then I'd be happy to use it. Until then, they remain well out
> of the reach of automated testing.
>
> [ some of the new cmdline testing stuff should help, but it is still awfully
> difficult because of the number of pieces that need to be set up,
> configured, and run; then there is the test configuration to map to that
> setup; then the number of external dependencies that can impact it; etc.
> Library testing is cake compared to testing client/server pieces. ]
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
Re: [OT] commit methodology (was: Re: CVS update: ...)
Posted by Brian Behlendorf <br...@collab.net>.
On Thu, 29 Mar 2001, Greg Stein wrote:
> > Should anyone be allowed to check in code that breaks any tests? Personally I
> > think someone should only commit code when all the tests pass on his/her local
> > machine.
>
> This is a bit off-topic for this list, but what the heck. IMO, yes, people
> can/should be able to check in stuff according to whatever guidelines they
> care to impose upon themselves.
I generally agree, based on the assumption that there'll be a "stable"
branch at some point where the rules for committing will be a lot more
strict, and may include mandatory test runs for any commit, in preparation
for making a release. What would be nice would be to build a list of
functions and use cases that need tests written, so that those on the
fringe of development have something useful they can contribute - not only
is writing tests a good way for beginners to get more comfortable with the
code, having someone different than the original coder for a function
write the test for it is an important form of peer review.
Brian
[OT] commit methodology (was: Re: CVS update: ...)
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Mar 29, 2001 at 09:42:05AM +0200, Joost Baaij wrote:
> Let me introduce myself ..
Welcome!
> I currently work as manager Q&A. My job is to review documents and code,
> produce documentation, and make sure everyone's talking to everyone and using
> the right tools (such as CVS).
>
> I've joined subversion-dev because I'm not happy with CVS and I believe this
> could replace it. I can probably help you guys with the documentation.
Great!
> Karl Fogel wrote:
> > It's important that the build and test suite be in a happy state in
> > the repository most of the time, to facilitate parallel development.
> > If I've checked in code that breaks "make check", then it's going to
> > be harder for others to test their own changes, even though their own
> > changes might not be related to what I'm doing.
>
> Should anyone be allowed to check in code that breaks any tests? Personally I
> think someone should only commit code when all the tests pass on his/her local
> machine.
This is a bit off-topic for this list, but what the heck. IMO, yes, people
can/should be able to check in stuff according to whatever guidelines they
care to impose upon themselves.
For example, I make changes all the time and never run the test suite. In
some cases, it is simply to fix a compilation issue caused by an API change
elsewhere. I know that isn't going to affect the test suite. In other cases,
the code that I'm working on is not covered by the test suite, so there
isn't a need to run it.
And your next words will be, "but that code should have a test suite, then!"
Well, there is a large gap between "should" and "does" :-) When somebody
wants to build a test suite that can adequately test mod_dav_svn and
libsvn_ra_dav, then I'd be happy to use it. Until then, they remain well out
of the reach of automated testing.
[ some of the new cmdline testing stuff should help, but it is still awfully
difficult because of the number of pieces that need to be set up,
configured, and run; then there is the test configuration to map to that
setup; then the number of external dependencies that can impact it; etc.
Library testing is cake compared to testing client/server pieces. ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/tests/libsvn_ra_local Makefile.am
Posted by Joost Baaij <jo...@spacebabies.nl>.
Let me introduce myself ..
I currently work as manager Q&A. My job is to review documents and code,
produce documentation, and make sure everyone's talking to everyone and using
the right tools (such as CVS).
I've joined subversion-dev because I'm not happy with CVS and I believe this
could replace it. I can probably help you guys with the documentation.
Karl Fogel wrote:
> It's important that the build and test suite be in a happy state in
> the repository most of the time, to facilitate parallel development.
> If I've checked in code that breaks "make check", then it's going to
> be harder for others to test their own changes, even though their own
> changes might not be related to what I'm doing.
Should anyone be allowed to check in code that breaks any tests? Personally I
think someone should only commit code when all the tests pass on his/her local
machine.
Joost.
Re: CVS update: subversion/subversion/tests/libsvn_ra_local Makefile.am
Posted by Karl Fogel <kf...@collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I don't see a problem.
>
> Further, I disagree with the notion of disabling it in CVS so that *nobody*
> can run the test, when it would appear to be a problem local to one system.
>
> There's been a lot of "just disable it from the build" recently, it seems.
>
> If you don't want it to build on your machine, then feel free to disable it.
> But disabling it in CVS is something to really think about it.
It's important that the build and test suite be in a happy state in
the repository most of the time, to facilitate parallel development.
If I've checked in code that breaks "make check", then it's going to
be harder for others to test their own changes, even though their own
changes might not be related to what I'm doing.
So disabling a test is often okay, under certain (common)
circumstances:
Most Subversion developers know one or two parts of the code really
well, and are just kind of tourists in the other parts. When you
discover that either the build is broken, or make check is broken, due
to a problem in an area not familiar to you, you generally have two
choices:
1. Debug it, unless you a) are in the middle of something else
right now, or b) believe that the domain expert for that area
of code can fix it in ten seconds, where as it would take you
two hours.
2. Temporarily disable the code that's causing the problem, so
building and "make check" still work; and check it in, so they
work for others too. (Of course, disabling isn't always an
option, it's only doable if there are no significant
dependencies on the code containing the bug.)
I agree that when it appears to be problem local to your system, then
you shouldn't disable it in CVS. But you can't always tell whether
it's local to your own system.
For example, I'm experiencing some bugs in fs-test.c:dir_deltas right
now that looks exactly like bugs other people have easily reproduced
on their systems in the past; so last night (after two hours of
attempting to track it down, using reliable reproduction recipes on my
own machine), I commented the test out and committed that. That way,
at least the test suite was in a passing state.
As it happens, other people are not able to reproduce the dir_deltas
bug, it's only me. But it would have been somewhat inconvenient to
find that out at 10pm last night, whereas commenting out the test is
an almost non-existent inconvenience for the people (Mike Pilato)
working on fs-test.c:dir_deltas -- I mean, it's what, six keystrokes
and a compile to get it back? :-)
I think the guidelines here are:
* If the build and/or "make check" are broken, and you don't have
any reason to suspect they're only broken for you, then do
whatever you think appropriate to make them work again.
* If what you did to make them work was only a temporary solution,
make sure that either you're going to come back and do the Right
Thing later, or that a domain expert knows what's happened so
they can do the Right Thing.
-K
> p.s. yes, I know ra-local-test doesn't actually run any tests right now, but
> that is not the point
>
> On Tue, Mar 27, 2001 at 11:55:14PM -0000, sussman@tigris.org wrote:
> > User: sussman
> > Date: 01/03/27 15:55:14
> >
> > Modified: subversion/tests/libsvn_ra_local Makefile.am
> > Log:
> > Suddenly tests/libsvn_ra_local/ won't build:
> >
> > /usr/libexec/elf/ld: cannot find -lneon
> >
> > Gstein, can you investigate? I'm temporarily disabling this dir's
> > build.
> >
> > Revision Changes Path
> > 1.5 +4 -4 subversion/subversion/tests/libsvn_ra_local/Makefile.am
> >
> > Index: Makefile.am
> > ===================================================================
> > RCS file: /cvs/subversion/subversion/tests/libsvn_ra_local/Makefile.am,v
> > retrieving revision 1.4
> > retrieving revision 1.5
> > diff -u -r1.4 -r1.5
> > --- Makefile.am 2001/03/09 17:53:43 1.4
> > +++ Makefile.am 2001/03/27 23:55:13 1.5
> > @@ -1,7 +1,7 @@
> > ## Makefile.in is generated from this by automake.
> >
> > -noinst_PROGRAMS = ra-local-test
> > -ra_local_test_SOURCES = ra-local-test.c
> > +#noinst_PROGRAMS = ra-local-test
> > +#ra_local_test_SOURCES = ra-local-test.c
> >
> > COMMON_LIBS = @SVN_TESTS_MAIN_LIBS@ \
> > @SVN_TESTS_EDITOR_LIBS@ \
> > @@ -13,7 +13,7 @@
> > @SVN_APR_LIBS@ @SVN_EXPAT_LIBS@ -ldb
> > ## Shouldn't -ldb be added automatically by the autoconf script?
> >
> > -ra_local_test_LDADD = ${COMMON_LIBS}
> > +#ra_local_test_LDADD = ${COMMON_LIBS}
> >
> > ## Flags needed when compiling:
> > INCLUDES = -I$(srcdir)/.. @SVN_INCLUDES@ @SVN_APR_INCLUDES@
> > @@ -25,7 +25,7 @@
> > ## Automatic tests run by `make check` -----------------------------
> >
> > ## A list of test-programs to run. (Each program contains sub-tests.)
> > -SVN_TESTS = ra-local-test
> > +#SVN_TESTS = ra-local-test
> >
> > ## We're overriding automake's own `check' rule, because it's extremely
> > ## inflexible; we want better control over automated-test output.
> >
> >
> >
>
> --
> Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/tests/libsvn_ra_local Makefile.am
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Mar 27, 2001 at 11:18:27PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> > p.s. yes, I know ra-local-test doesn't actually run any tests right now, but
> > that is not the point
>
> Actually, it *is* a real set of tests, even using the latest C testing
> framework. It tests things like ra_local's ability to find a
> repository within a URL path, etc. So we do want to fix this problem
> and get it building again.
All the tests are stubbed out right now. So whether it is in or out, the net
effect is the same.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: CVS update: subversion/subversion/tests/libsvn_ra_local Makefile.am
Posted by Ben Collins-Sussman <su...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I don't see a problem.
>
> Further, I disagree with the notion of disabling it in CVS so that *nobody*
> can run the test, when it would appear to be a problem local to one system.
>
> There's been a lot of "just disable it from the build" recently, it seems.
Sorry, I don't mean to be so hair-trigger. I *assumed* that it was a
global build problem, not just my box. I promise to investigate more
carefully next time. :)
> p.s. yes, I know ra-local-test doesn't actually run any tests right now, but
> that is not the point
Actually, it *is* a real set of tests, even using the latest C testing
framework. It tests things like ra_local's ability to find a
repository within a URL path, etc. So we do want to fix this problem
and get it building again.