[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 3032 - trunk/subversion/include trunk/subversion/libsvn_wc trunk/subversion/libsvn_client trunk/subversion/tests/clients/cmdline

From: Karl Fogel <kfogel_at_newton.ch.collab.net>
Date: 2002-08-23 04:06:11 CEST

Greg Stein <gstein@lyra.org> writes:
> > Fix some screwy `svn status' stuff. Tandem code-churnin' and
> > bug-bustin' with Karl.
> This log message doesn't say what was "screwy" and how you fixed it. The log
> message simply goes through "added this param. removed this." It totally
> misses the important question of "why?" There is a lot of what changed, but
> no motivation, or how the end result now fixes the original problem.

Yeah, concur (was just thinking this myself).

I'll update the log message; here's the new summary:

   Fix some screwy `svn status' stuff. Tandem code-churnin' and
   bug-bustin' with Karl.

   The problem was that 'svn status' had regressed: it longer printed
   `!' for missing objects and `~' for objects whose kind has changed
   (file to dir, or dir to file). The reproduction recipes are given
   in the two regression tests mentioned in stat_tests.py below.

> > +++ trunk/subversion/include/svn_wc.h Thu Aug 22 20:05:41 2002
> >...
> > + * If GET_ALL is unset, then only locally-modified entries will be
> > + * returned. If set, then all entries will be returned.
> >...
> > + * If DESCEND is unset, statushash will contain statuses for PATH and
> > + * its entries. Else if DESCEND is set, statushash will contain
> > + * statuses for PATH and everything below it, including
> > + * subdirectories. In other words, a full recursion. */
> -1 on this change.
> This is C code, not Perl. A variable is *always* set. Booleans are
> true/false or non-zero/zero. But never ever "unset".

Fine on changing it; I agree that the true/false language is better.
But note that we've been documenting booleans this way throughout the
code for a long time. Not always, but there are certainly other
instances. I don't have the heart to search for them right now :-).

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 23 04:24:55 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.