Max Bowsher wrote:
> TBrowder wrote:
>> The idea is to use SVNROOT (where defined) as it is used in CVS as
>> we commonly use it, to wit:
>>
>> 'cvs co module' (equates to 'svn co URL_to_repos/module')
>>
>> 'cvs import module [...and other args] (equates to 'svn import
>> URL_to_repos/module' without a local directory)
>>
>> To the best of my knowledge, svn and cvs default behaviors for
>> other commands are similar and don't need a reference to SVNROOT
>> because they both know the default repository location when the
>> user is in a directory with a working copy (WC).
Kind of, but not exactly so. Every working copy knows the repository
location for the path they are in - the working copies do not know the
repository root they are inside. Eg. a normal checkout of subversion
knows only that it is "http://svn.collab.net/repos/svn/trunk/" but
does not know that "http://svn.collab.net/repos/svn/" is the root of
the repository.
Also, many of the commands in Subversion behave *differently* when
invoked on URLs than when invoked on working copy paths. There is
quite often a need to invoke a command for the URL that corresponds to
the current working copy. And in many cases it is necessary to refer
to the root of the repository the working copy is in.
So, just changing checkout and import not only makes them inconsistent
with all other commands taking URLs, but also does not really solve
the problem since the URLs are used all the time in other operations.
>> My idea for the implementation of SVNROOT in svn is to intercept
>> the command line targets at the point just before they are checked
>> for errors and execution (in the files
>> './subversion/clients/cmdline/checkout-cmd.c' and
>> './subversion/clients/cmdline/import-cmd.c' ), check to see if
>> SVNROOT is defined, and make the appropriate substitutions in
>> targets (if they are not already in URL format), and pass the
>> arguments on as usual.
Actual implementation should be more or less trivial once design is
clear.
>> I believe the mod is innocuous, helpful to those who want such a
>> feature, and can be ignored by those who don't.
Granted, it does not change any of the ways Subversion can be used
today - but the new features make the interface inconsitent with the
other commands.
>> So ends my proposal for SVNROOT.
I will try to gather here invidual points, which I think a suggestion
should try to fulfill.
* SVNROOT functionality should be usable with all commands with URLs.
There are quite a few daily uses where one would need the
functionality, and being able to use it in one command, but not
another is wasteful.
* Usage of SVNROOT should be explicitly visible in the arguments.
Many commands in Subversion can take either URLs or WC paths as
arguments - for example "svn cp" which takes two arguments,
either which can be an URL or a WC path. To keep the interface
consistent, it should be possible to determine directly from an
argument whether it is an URL or not.
* Usage must be easier than just using environment variables.
Right now it is very easy to just say "export
S=http://svn.collab.net/repos/svn" and then use it in operations,
such as "svn co $S/trunk" or "svn cp $S/trunk $S/tags/1.0.0". Any
SVNROOT proposal should be significantly easier than this to be
worthwhile.
As an advanced point, I think there are two different functionalities
required. First of all the ability to refer to a global repository
root anywhere, regardless of current working copy - this would be the
SVNROOT functionality. And secondly to be able to refer to the
repository path that is in the current working copy - this would be
new functionality more or less specific to Subversion.
A note on filenames:
Currently, Subversion separates paths from URLs by looking for
"(schema)://", where schema can be anything which does not contain a
colon (:) or a slash (/). Any added modifications which should be
interpreted as URLs should hopefully be such, that nobody is likely to
have anything named like that in their repositories or working copies.
-- Naked
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 17 17:51:13 2004