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

RE: [Subclipse-dev] Synchronization remaining problems

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2005-06-17 16:27:59 CEST

"Martin Letenay" <mle@whitestein.com> wrote on 06/17/2005 10:22:28 AM:

> Well,
> At the moment we're calling svn info only on those resources we cannot
find
> out their nodeKind.
> Calling it on every (incoming) resource, hmmm.... wouldn't it be a too
slow
> ?
> I don't know.
> If the info command could be passed several URLs in one call ...
> But it seems it does not. The command line can, but the javahl binding
does
> not seem to support it ...
>
> But I don't mind, the question is just whether we are willing to pay
some
> performance for those revision numbers ...

I would say we could hold off on that. If you didn't already, perhaps you
could put the code in so that when you do call svn info it updates the
revision info for that item?

I hadn't realized that you "optimized" this so that you only used svn info
when you had to. That does seem like the better approach. I think what
we really ought to do is nail down all of the things that JavaHL is not
currently doing that we would like it to, and post it to Subversion. I
seem to recall that the Node Kind info is a general problem but requires a
"2.0" API change. Still, we ought to have an open issue with them to get
everything we need.

It seems mainly like we need the node kind and the head revision for each
item that is returned from svn status.

Panagiotis, do you have any comments on this?

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sat Jun 18 00:27:59 2005

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.