Alan Barrett wrote:
> On Tue, 08 Nov 2005, Jim Blandy wrote:
>> # Two directories are "parallel" if it makes sense to compare
>> # corresponding files in them. A trunk and a branch or tag taken from
>> # that trunk are parallel, as are two branches from the same trunk.
>
> Yes, this definition of "parallel" is exactly the right way of looking
> at the problem.
>
> I think that Greg's idea of transformation rules required the two
> directories to have a common ancestor (at which there would be a dirprop
> describing the transformation rule), whereas your idea doesn't need
> a common ancestor (placing the necessary dirprops at the "trunk" or
> "branches/foobranch" or "vendor/release" level, not at the "project"
> level).
>
> I noticed two unsolved problems: If several branches are each declared
> as parallel to the trunk, how do we know that the branches are also
> parallel to each other? And how do we know how many directory
> components are part of the branch specifier, as opposed to part of the
> directory within the branch?
>
> --apb (Alan Barrett)
This approach is (somewhat) similar to the strawman I was sketching in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=107942 (which
was a crossposted reply to gcc, so the subject may not have gotten very
many people to look at it).
I punted both of those issues by making the user say, ala patch, how many
path components to whack off the front (essentially either 1 (/trunk), 2
(/{branches,tags}/*), or perhaps 3 (if you have branches or tags sorted
into groupings).
The places I was stuck on were:
I was expanding one option into a value for old and new, so I didn't have a
good way to specify the distinction between '.' and URI@base as the 'local'
copy
I also didn't have anything that felt good for reversing the arguments.
Continuing to use separate --old and --new, but having a special syntax that
references the other one solves both of those, I think...
So, combining the two strawmen, we'd have something like -N:path as a valid
form for specifying --old and --new. Using an option-like syntax for the
argument to --old/new feels agreeably special - filenames that start with
'-' already need escaping with ./-file in many cases. It also feels pretty
natural to let -N:* remove N of something
To spec this a little tighter, we'd look at both old and new, and if both
are the special 'parallel' syntax (start with -), that's either an error or
they are both relative to cwd. The former has the advantage of (slightly)
less magic, the latter would make it easy to compare two tags, neither of
which is the wc url but both of which are relative to it. That could be
handy for merge... I think I'm leaning toward the latter. Otherwise, the
relative one is computed against the one that specs an absolute URL (which
coudl be an explicit absolute URL, or a wc path of any sort)
Anyway, to an example:
# svn diff --old . --new -1:/branches/foo@peg bar.c baz.c
Once we've picked an absolute path, that's the base for generating the
relative ones. So in this case our base is '.'. Then we need to get the URL
and repository root from the absolute one:
# svn info . (the absolute url)
URL: svn://root/trunk/subdir
Repository-Root: svn://root
whack Repository-root off the front of URL, and seperate a peg if any:
/trunk/subdir @peg
prune the specified number of components (1, in this case) and replace them
with the prefix, and reattach the peg
/branches/foo /subdir @peg
giving
# svn diff --old . --new svn://root/branches/foo/subdir_at_peg bar.c baz.c
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 9 16:02:28 2005