[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: Mark Phippard <markp_at_softlanding.com>
Date: 2005-10-04 22:18:33 CEST

"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.

As the patch that has been committed demonstrates, it was not hard to
return the URL of the item in the repository. The only remaining issue is
if there is someway to do this that does not involve duplication when the
item is "out-of-date" and also exists in the WC. There are some obvious
solutions but they all involve some ugliness. Which is why the patch as
committed may be the best way to do this.

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________

---------------------------------------------------------------------
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:19:50 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.