John Peacock wrote:
>
> Rather than going down that road, I wonder if it wouldn't be enough to
> create a fallback to the existing path resolution. Suppose we take the
> following long query (as mentioned earlier in the discussion):
>
> svn diff
> --old svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch/gcc/file.c
> --new file.c
>
> where the WC in question was, say, checked out from:
>
> svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch/
>
>
> We could simplify that command to:
>
> svn diff
> --old gcc-4_0-branch/gcc/file.c
> --new file.c
(You mean "--new gcc/file.c" I think.)
> 1) First the "old" path would be searched for in the current WC (which
> is the existing behavior) and it wouldn't be found;
Ambiguities starting to creep in: behaviour depends on whether the thing is
found locally. If we suspect it is going to be found locally, maybe we want a
syntax to force it to be found relative to the other URL instead.
> 2) Next, the "old" path would be decomposed into the two directories and
> filename, and the fully qualified "new" path (from the WC files) would
> have the last two directories stripped off;
>
> 3) Then the common remaining portion of the "new" path would have the
> two specified directories from the "old" path appended and the diff once
> again attempted;
That doesn't work if the two full paths aren't the same length. For example,
with "--old gcc-4_0-branch/gcc/SUBDIR/file.c" it would strip three dirs and
then not find a match.
> 4) If this still doesn't work, the current error could be printed along
> with a suggestion to try a fully specified URL.
>
> 5) If both "old" and "new" contained path's that do not exist in the
> current WC, then they both have to contain enough information to locate
> the actual path in the repository, as offset from the current WC location.
>
> As long as either old or new parameter contained enough context to
> specify the common path in the repository, then the WC's repos_root term
> would always be sufficient to determine the fully qualified path at any
> point.
>
> Does that make any sense, or do I need to create some ASCII art and
> pseudo-code?
I understand what you say, but I don't think you've thought it through. It
sounds too hacky. No doubt it can be refined to address some of my concerns;
do you want to try to make it into a more solid proposal?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Nov 3 16:36:21 2005