Re: [PATCH] add 'svn version' as 'svnversion' v1

Dear Branko,

>> Yes, if we are going to do this, we should *definitely* take the
>> opportunity to choose a better name.

> Before going on with this patch, I'd like to see some real discussion about
> why we want this in svn proper at all. What's wrong with leaving the
> functionality in svnversion? I've not seen a single good reason.

I'm still waiting for a good reason to have it a separate command.
*ALL* other user accesses are managed with "svn" and its subcommands.

I asked about it:

http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=95428

Basically the reason for the separate command is historical, and ISTM that
it is not used by the build process as described in svnversion/main.c:

  /*
   * Why is this not an svn subcommand? I have this vague idea that it could
   * be run as part of the build process, with the output embedded in the svn
   * program. Obviously we don't want to have to run svn when building svn.
   * We could always put this into libsvn_client and share it between
   * svnversion and svn.
   */

Even if it is available as a separate command, there is no reason why
it should not be available within "svn".

As a user, I use the functionnality to check for the heterogeneity of a wc
pretty often, and every time I'm wondering why I have to use a separate
user command.

Also, as I think that the functionnality is useful, so that it make sense
to put it in one of the library, so that other client applications can
take advantage of it.

> And besides, this functionality properly belongs in libsvn_wc, not
> libsvn_client.

Well, it is pretty close to "status" and there is a "status.c" file both
in libsvn_client and libsvn_wc. I agree that it is closely related to the
working copy stuff.

-- 
Fabien.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org