[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() unversioned semantics for non-wc files

From: Jay Freeman \(saurik\) <saurik_at_saurik.com>
Date: 2002-02-11 20:52:45 CET


I'd say we are saying promises that aren't useful :). The same thing is
returned for new files that have never been seen before in working
copies as is for paths that aren't even in working copies. There
doesn't seem to be an obvious way to differentiate /etc/passwd from

Jay Freeman (saurik)

-----Original Message-----
From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
Sent: Monday, February 11, 2002 12:03 PM
To: Jay Freeman (saurik)
Cc: dev@subversion.tigris.org
Subject: Re: svn_wc_status() unversioned semantics for non-wc files

"Jay Freeman \(saurik\)" <saurik@saurik.com> writes:
> Is there a way to figure out if a file just has absolutely nothing to
> with a working copy? I could have sworn those files used to return
> (with no error condition) from svn_wc_status(), but now they are
> spitting out a status object where everything is set to unversioned.

Doc string for svn_wc_status() says this:

      svn_wc_status_none : PATH is not versioned, and is either not
                           present on disk, or is ignored by the
                           svn:ignore property setting for PATH's
                           parent directory.

      svn_wc_status_absent : PATH is versioned, but is missing from
                             the working copy.

      svn_wc_status_unversioned : PATH is not versioned, but is
                                  present on disk and not being
                                  ignored (see above).

Are we seeing behavior that breaks these promises, or are we seeing
callers that aren't checking for these values correctly?


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:37:06 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.