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

Re: Java Question

From: Daniel Rall <dlr_at_collab.net>
Date: 2006-08-05 00:00:09 CEST

On Wed, 02 Aug 2006, Philip Martin wrote:

> Mark Phippard <markp@softlanding.com> writes:
> > svn mkdir url://tags/subclipse/X.Y.Z
> > svn copy url://trunk/subclipse url://tags/subclipse/X.Y.Z/subclipse
> > svn copy url://trunk/svnclientadapter
> > url://tags/subclipse/X.Y.Z/svnclientadapter
> >
> > I usually just do it in the WC and then commit, but it would be nice
> > to be able to build a UI that could do it against the repository.

Doing this over ra_local (e.g. with file:// URLs) would probably
satisfy Dan P.'s needs, too!

> I wrote a simple C client that uses the RA layer to do that sort of
> thing:
> http://svn.collab.net/repos/svn/trunk/contrib/client-side/mucc.c

That's really cool, Philip, thanks for pointing it out.

> Building a transaction is slightly more complicated than just doing
> a series of mkdir/copy/copy because you have obey the rules of the
> delta editor, in essence you have to make a single pass over the
> directory structure.

Philip, does this boils down to more than re-ordering/mixing-in some
of the editor commands which correspond to caller operations?

Dan P., do you really need a true transaction, or would multiple URL
operations be sufficient?

Mark also wrote:

> > I think it would be cool to have some of this added, but I also
> > think the current approach to JavaHL makes the most sense. I really
> > wonder how well a Java class with all of these JNI calls would
> > perform. For a lot of operations, it would not matter but I sure
> > wouldn't want to do working copy status checks this way.

It wouldn't really be necessary to introduce more dives into JNI-land.

A multi-command JavaHL client could store a series of operations in a
Java context object, then pass that object into a commit() API
implemented through JNI, which acted just like Philip's mucc.c. This
API would retrieve the series of operations from the Java object (via
"reverse JNI"), and then drive a delta editor to apply the changes to
the repos.

The interface for the client could either look like a subset of the
existing SVNClientInterface, with a method for assocating a set of
operations with a single editor drive ("transaction"), or be a
completely separate interface more similar to what Dan P. proposed.

This sounds like a pretty useful thing to expose through the

  • application/pgp-signature attachment: stored
Received on Sat Aug 5 00:00:35 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.