[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-22 21:56:23 CEST

Daniel Rall <dlr@finemaltcoding.com> wrote on 06/22/2005 03:44:50 PM:

> On Fri, 2005-06-17 at 10:27 -0400, Mark Phippard wrote:
> ...
> >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.
>
> +1 on creating a running "what's missing" list for JavaHL. I recommend
> a plain text file stored in our SVN repo from which we occasionally
> create corresponding issues in the SVN tracker, and record their issue
> numbers in the list. For instance:
>
> JavaHL change list
> ==================
> [not yet filed] JavaHL should support multiple SVNUrl args
> ...
>
> I am open to reviewing all JavaHL patches driven by Subclipse/SvnAnt
> usage, and might even be able to eek out a little time to knock out some
> of the issues myself.

Good idea. Feel free to start it. You can probably just stick it in
trunk since it applies to all projects.

On the issue you cited, I think that ideally we would not need to call svn
info at all. I think the issue is that when we call svn status -u, it
does not return all of the info we need. For example, we need to know if
the node is a dir or a file, and ideally we would know the head revision
of each item.

I seem to recall this is a Subversion API limitation. For example,
ideally with the CLI svn log --xml would also indicate the node kind. I
think there is an open issue for this but it requires a 2.0 type change. I
could be wrong though.

In this case, perhaps JavaHL could provide an alternate API we could use
that would do svn status and then run svn info on the results. Giving it
to us in one command. Then JavaHL could use the better API when it was
available?

Mark

_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Thu Jun 23 05:56:23 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.