cmpilato@tigris.org writes:
> New Revision: 1621
> Log:
> WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING WARNING
>
> Plugging in the new commit system. This change is simply growing too
> large, and quite frankly, I could use some help finding all the fun
> new bugs it introduces! Known problems:
> - client feedback is Not Quite Right(tm), but should suffice in the
> short term for commits of working copies that do not have disjoint
> directories.
> - svn copy WC_PATH REPOS_URL is broken, and has been temporarily disabled.
> - there are surely other problems with a change of this magnitude!
> - there is still present quite alot of old code that will eventually
> be removed.
>
> Though the code seems to generally work over ra_local and ra_dav, this
> change *is* expected to break pretty much all of the commit-using
> Python tests (since they depend almost exclusively on the feedback
> from the client binary, which is, as was mentioned above, Not Quite
> Right). It is, however, *not* expected to break the XML tests.
Wow!
Mike... forgive my somewhat negative line of inquiry here (I know how
long & hard you've been working on this!), but:
Although we've occasionally checked in changes that break "make check"
in the past, it's usually done for a small and known quantity of time
(for example, because a particular change really should be committed
in two stages, or because someone else has a related patch that must
be applied after the change). I'm wary of breaking "make check" for
an indefinite amount of time while we all find bugs -- that's a
process that's not guaranteed to halt. :-)
If the fix required to unbreak the tests now is minor, this commit
could (should?) have included those test adjustments. Else if fixing
the tests is a major undertaking, then they're now broken for an
indeterminate length of time. Either way, it seems imho like this
commit was a bit premature.
What does "this change is simply growing too large" mean, in technical
terms? Was the usual update-from-repos-into-locally-modified-wc
process not working for this change, and if so why not?
Sorry, don't mean to come off like a hard-ass, I'm just not clear on
the reasoning behind committing this before it's (apparently) ready.
Are there special circumstances that make this the least painful
course of action?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 3 08:43:11 2002