[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Diff syntax changes for issue #1093

From: Jack Repenning <jrepenning_at_collab.net>
Date: 2003-10-30 02:24:49 CET

At 4:35 PM -0500 10/29/03, Greg Hudson wrote:
>For background, read CMike's proposal at
>http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=48573 if
>you haven't already.
>
>I have a few Deep Thoughts, which I'll present in increasing order of
>complexity. Essentially, I want to adopt CMike's proposal, but with
>some simplification (point 1), a slight modification (point 2), and with
>a better description relative to the current syntax (point 5).
>
>1. Being able to do "svn diff -rX:Y foo@Z" seems really esoteric. It's
>a tough concept for users to understand, and I can't imagine it getting
>any use from the command line. So I don't think it's a good idea to
>support that. When the question of peg revisions comes into play, we
>should always peg paths to the WC, and should always peg URLs to the
>HEAD.

I'll grant you some wording like "uncommon," but this is a facility
I've often used, from the command line, with ClearCase. I think this
same scenario is quite likely with SVN. It arises from versioning
directories (knowing not merely that "this directory contains a file
of such a name and such contents" but actually "which is related to
certain ancestral nodes, and not to all those others"). Based on
ClearCase experience, I suspect the scenario will be fairly common,
more common than one might suppose reasoning just from, say, CVS
experience (where you can't get into these states).

I'd hate to see this syntax lost.

I'll illustrate in the rest of this message, but the examples will
probably be opaque to those without ClearCase experience, and I don't
really want to turn this into a ClearCase seminar ... if your
curiosity's irrepressably aroused, drop me a line by private email
and we can chat ;-)

In ClearCase, you don't have or need a specialized "diff" command,
because it presents itself as a versioned file system, and plain old
"diff" can read the files just fine:

        diff dir1/dir2@@/REL1/README/REL2 dir1/dir2@@/REL2/README/REL2

That compares two versions, but not necessarily two versions of the
same file. Each of these versions is a version of an "element"
(ClearCase speak for SVN "node") that, at least occasionally, was
visible as a file named README. We are comparing versions bearing
the label (== "tag") REL2, in both cases. We know that the "file
named README" of interest (there are, of course, many "files named
README" in the world) was at various times visible in dir1/dir2. We
have some reason to suspect that the actual file README present there
in REL1 was a version of a different element than the actual file
README present there in REL2.

The most common (and it's surprisingly common) use case is, someone
inexperienced made changes by

        cleartool rm file
        create file anew by some means or other
        cleartool mkelem file # mkelem is ClearCase speak for "add"
        cleartool checkin

This fractures the history -- you can't simply "diff
file@@/main/[23]" (as you could if history were preserved). This
causes consternation for downstream tools, such as smart diff/merge.
This, ultimately, causes the ClearCase guru to visit the ClearCase
novice's desk, run the complicated command above, try a few
unsuccessful times to explain the problem, and finish off by saying
"look, just change the file, don't remove and recreate it."

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835.8090
f: 650.228.2501
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 02:25:36 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.