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

Re: svn commit: rev 1621

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-04-03 08:49:16 CEST

cmpilato@tigris.org writes:
> New Revision: 1621
> Log:
> 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.


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?


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

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.