Hi Max,
Max Bowsher wrote:
> Dirk Hoffmann wrote:
>
>>> Hi,
>>>
>>> this posting is in reply to "Can you set properties on a file without
>>> having it checked out?".
>>>
>>> I opened a new thread as it adresses a broader range of problems.
>>>
>>> In the system we are developing svn is accessed through automated
>>> processes programmed in java. To make this possible svn's interfaces
>>> needed to be extended. Here comes a collection of patches others may
>>> find useful.
>>>
>>> The patches are against version 1.1.0-rc2.
>>>
>>> They are intended to give others some hints on how they can create
>>> their
>>> own extensions not to be used directly.
>>>
>>> Note that I'm not an expert on svn internals.
>>>
>>> I've attached a tgz (hope it will make it to the list) containing a
>>> directory structure with the two branches mod and new. new contains new
>>> files and mod diffs to files that already existed in the original
>>> sources (I don't like recursive diff). Both directories resemble the
>>> directory structure of svn's sources.
>>>
>>> The way the changes are applied to svn's sources aims at minimizing
>>> modifications to the original source files to make patching new svn
>>> versions as easy as possible.
>>>
>>> (That's because I think some of those will never find their way into
>>> subversion)
>>>
>>> Of course I would be happy if the subversion developers reviewed this
>>> stuff and maybe add parts of it to subversion.
>>
>
> A comment in general.... *Please* don't use the "svn_" prefix for
> symbol names for anything that you publicize, but do not intend to
> become part of Subversion officially - it opens a door to extreme
> confusion.
Ok
>
>>> Features:
>>> ---------
>>>
>>> [libsvn_client]
>>>
>>> New functions:
>>>
>>> * svn_client_rename()
>>>
>>> This function does the same as svn_client_move with the following
>>> exception:
>>> If dst_path exists and is a directory this function raises an error
>>> wheras snv_client_move would append the basename of src_path to
>>> dst_path and take this as the destination path.
>>>
>>> Added new argument to wc_to_wc_copy that controls if copying into
>>> directories is allowed
>>
>
> I believe we have an issue concerning this in our tracker.
>
>>> * svn_client_head_revision()
>>>
>>> Return the numerical value of the head revision of the repository
>>> containing the give resource
>>
>
> Isn't this pretty easy to do directly with libsvn_ra ?
Of course you could do so. I just wanted to keep the layers of
abstraction straight.
Another reason is that a lot of work on this I did by copy&modify
because I'm not quite familiar with the subversion internals.
>
>>> * svn_client_repos_root()
>>>
>>> Return the url of the repository containing the given resource
>>
>
> Ditto.
>
>>> * svn_client_put()
>>>
>>> Copy local file into the repository without needing a local working
>>> copy
>>
>
> See tools/examples/svnput.c for why we worry about shoot-self-in-foot
> possibilities of this.
Yes, I know about this issue.
>
>>> * svn_client_kind()
>>>
>>> Get the node kind of specified files or URLs.
>>
>
> Doesn't this end up as little more than a trivial wrapper of other APIs?
Yes, but the important thing was to get the functionality to the
surface, i.e. the command line client and javahl.
I know these are only small pieces of code but nevertheless were quite
hard to write as I'm not familier with svn's internals.
I never understood why subversion doesn't offer the functionality to
retrieve the head revision or the repositories root url via the command
line client or javahl.
I would be very happy if these simple things (get head revision, root
url, kind of resource, rename) went into subversion after beeing
reviewed and fitted into its source code. From the mailing list I know
that I'm not the only one needing such functionality.
>
>>> * svn_client_prop_set()
>>>
>>> Set a property without needing a local working copy
>>
>
> At some point we need to have a discussion about whether the
> shoot-self-in-foot possibilities mentioned above apply to properties
> too or not.
>
> Max.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 24 17:23:04 2005