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

Re: svn_wc_status suggestion

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-10-18 16:12:47 CEST

Yoshiki Hayashi <yoshiki@xemacs.org> writes:
> 1. If a file is not under version control, text_status
> field contains 0 which is not defined in enum
> svn_wc_status_kind.
> I think it's cleaner to add new member to enum with proper
> name or just use svn_wc_status_none now that
> svn_wc_status_normal is added.

What do you mean by "file not under version control"?
Do you mean
  * running svn_wc_status() on a file that is not mentioned in any
    entries file?

  * running svn_wc_status() on a file that is only scheduled for

Looking at the code for svn_wc_status(), it appears that in the first
case the function (indeed) returns an error.

> 2. If a directory is not under version control,
> svn_wc_status returns SVN_WC_OBSTRUCTED_UPDATE.
> I'd like to have svn_status_t with NULL entry instead of
> error because that's what I get with non version controlled
> file. Even if returning error is preferred, I think
> different error should be used because
> SVN_WC_OBSTRUCTED_UPDATE is returned by svn_wc_entry and
> it does not describe what's happened.

True, it's a bad error value to return. I suppose that we could make
svn_wc_status return NULL (instead of an error) if the path is not
under version control. Then the caller could create an error if it
wishes. (I know the command-line client would want to do that.)

I'm confused, because it sounds like you're planning to make your GUI
client run svn_wc_status() on every single file it can find.
Shouldn't you be running svn_wc_statuses() on a single path (with the
verbose flag) and get back a list of all things under version control?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:45 2006

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.