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