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

Re: 'svn status -u -v', behavior and APIs

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-10-04 22:27:03 CEST

On Tue, 4 Oct 2005, Mark Phippard wrote:

> "Peter N. Lundblad" <peter@famlundblad.se> wrote on 10/04/2005 04:02:56
> PM:
> > I don't understand. Does this mean the the URL fo the entry and the URL
> > "in the repository" are different? Doesn't make sense to me. Else, why
> not
> > just use the URL from the entry, and if there is no entry because it is
> an
> > added file, use the URL of some grandparent plus the path (as I suspect
> > the current code does today?).
> >
> > You may need to clarify a bit...
> Consider the case of something like JavaHL which is simply a "consumer" of
> this API. Suppose you have a scenario where all you have is a single new
> file in the repository and no local modifications. The information that
> the API returned prior to this most recent change was just not enough to
> possibly construct a URL for that item. As a client asking for all of the
> status changes in a project (svn st -u), how would I know the grandparent
> of this item? All I get back from the API is the one item.
I understand that problem, so I don't object to svn_wc_status2->url when
you don't have an entry. I just wanted it to be set all the time. An item
can have one and just one URL, regardless whether it exists only in the
WC, only in the repository or both.

I and dlr discussed this on irc, and the conclusion seems to be that we
will have sv_wc_entry2->url set, either from the svn_wc_entry_t if that
exists, or calculated by the status code if the file only exists in the
repository. dlr will produce a patch to this effect, he said.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Oct 4 22:29:51 2005

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.