Local path must be independent of SVNURL and SVN PROJECT

Pushok Software wrote:
Exactly. Sorry if I didn't check the latest code to see if this worked.
I've just purchased a single license and indeed this works just fine
as I need it to. I'll be moving our users over to Subversion real soon
now, and we will definitely be using your plugin!
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748

I am rapidly moving towards the point of dropping CVS for Subversion and I
would like to continue using your plugins within our preferred editor.
However, unless you fix the problem I described above, we will be unable to
do so.

The basic issue is the same as I originally described: the working copy
path cannot be forced to be the same as the path in the repository. Your
CVS plugin does this by default, but it is possible to override it there;
the SVN plugin will not accept the override. Just like with CVS, the
administrative files in the .SVN (or _SVN with the patched Subversion)
contain all of the information required to determine the repository path
(corresponding to the SVNURL and SVN MODULE in the screenshot I posted).
The directory containing the working copy itself has no bearing whatsoever
on the path in the repository, and indeed with multiple projects organized
in the recommend fashion (see my example above), there is no way to
distinguish the working copies without having user-defined names for the
working copy folder.

I'm not asking that you change the default behavior, merely to restore the
ability to manually set the "Local Path" (see the screen capture I sent),
exactly as it operates in your CVS plugin.

Thank you for considering this change

John Peacock

There is no concept of "module" in Subversion (at least not yet),
comparable to the CVS module. Any portion of the repository can be checked
out as the top level directory of a working copy. For that matter, once
checked out, a working copy can be moved around and subdirectories copied
elsewhere to establish new, smaller working copies.

The name of the directory containing a working copy is unimportant, since
the contents of the .svn directory completely determine what the working
copy is referring to (much like the ROOT and REPOSITORY files in the CVS
directory completely define the path to the CVS files). One of the most
common (recommended) repository layouts is like this:

project1
project1/tags
project1/branches
project1/trunk
project2
project2/tags
project2/branches
project2/trunk

so when checking out one of those projects, it is common to checkout the
trunk, but rename the directory containing the working copy so that it is
clear what is being checked out. In commandline terms:

svn co http://server/svn/project1/trunk project1-trunk

would checkout a copy of the path project1/trunk into the local filesystem
as ./project1-trunk.

As far as your questions, MultiEdit hides a lot of the SCC interface from
me (i.e. it won't look exactly like it does in Visual Studio for example).
What I refer to as "associating" a MEW Project with a version control
system is what I believe you call "Open project from source control". I've
included a dialog box capture as an attachement to this issue.

As you can see, the SVNURL and SVN MODULE completely determine what portion
of the repository that is to be checked out. The LOCAL PATH currently is
required to end with the same path as the SVN MODULE, which is at variance
with all other current Subversion interfaces. The LOCAL PATH is completely
independent of what is contained in that directory. I am not the only one
who will be annoyed and perplexed by this behavior.

I hope this explains the problem more fully.

John

When associating a project with an already checked out Subversion working
copy, currently the SVNURL + SVN MODULE define the full path to the remote
repository. However, currently the Local Path cannot be something other
than what is defined as the SVN MODULE.

For example this does not work:

SVNURL = http://svn.collab.net/repos/svn
SVN MODULE = trunk
LOCAL PATH = D:\WORKING\SVN-TRUNK\

What will happen is that the SVNSCC code will automatically append \trunk
to that code:

LOCAL PATH = D:\WORKING\SVN-TRUNK\\trunk

This is not consistent with either the svn commandline client,TortoiseSVN,
or RapidSVN.

Thanks

John Peacock