Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> My impressions was that part 2 of what you said is pretty much what was
> concluded during that last thread. :)
Well, this will be a very short discussion, which is okay too. :-)
> There is another slight hurdle though. The option parsing code in main.c
> currently won't support the same option twice, so -r 4 -r 9 won't work with=
> out
> at least a little re-write. I know our code won't handle it, I'm not sure
> the APR functions used for options.
We can either rewrite it, or allow colon-separated values, i.e.,
$ svn diff -r 7 /* diff from working to 7 */
$ svn diff -r :7 /* diff from working to 7 */
$ svn diff -r 7: /* diff from 7 to working */
$ svn diff -r BASE:7 /* diff from base to 7 */
$ svn diff -r 3:7 /* diff from 3 to 7 */
$ svn diff -r 7:3 /* diff from 7 to 3 */
Formally, when the colon is omitted, it is assumed to be on the left
of the revision, and when a revision is omitted, it is assumed to be
"WORKING". As a special case, when no -r option is given, diff from
base to working.
-K
> On Thu, Oct 11, 2001 at 03:58:24PM -0500, kfogel@collab.net wrote:
> > I believe there was a long thread about this before, but it didn't
> > seem to resolve conclusively, and I'd like to restate the issue and
> > get some feedback on possible implementations.
> >=20
> > Soon, as soon as issues 382 and 414 are resolved, we will be finishing
> > the rest of `svn diff'. Right now, `svn diff' only shows local
> > modifications -- it can show the diff between your base revision and
> > your working file, but it can't do
> >=20
> > a) diff between your working-or-base-file and some other rev, nor
> > b) diff between two arbitrary revisions in the repository
> >=20
> > First, let's talk about interface. Here are some examples of diff
> > commands, examples being the easiest way to express what I'm thinking.
> > These are rather extensive, please feel free to skim them and go to
> > where I talk about implementation of (b), which is actually the main
> > point of this mail. :-)
> >=20
> > $ svn st -u foo.c
> > _ * 17 ./foo.c
> > Head revision: 20
> > $ svn diff foo.c
> > ... shows diff from .svn/text-base/foo.c to ./foo.c, works now.
> > $ svn diff -r 20 foo.c
> > ... shows diff from local foo.c to revision 20 of foo.c in repos.
> > $ svn diff -r 17 foo.c
> > ... same as "svn diff foo.c" :-).
> > $ svn diff -r 5 foo.c
> > ... shows diff from working ./foo.c to rev 5 of foo.c; even though
> > rev 5 is earlier than the base of the working version, we still
> > show the diff in this order for consistency. In other words,
> > running "svn diff -r REV FILE(S)" always produces a patch that,
> > when applied to your working file, results in rev REV of that
> > file.
> > $ svn diff -r 5 -r WORKING foo.c
> > ... same as above, but reverses the direction of the diff. The
> > keyword "WORKING" as a revision means "use the working file",
> > as opposed to the pristine base.
> > $ svn diff -r 5 -r BASE foo.c
> > ... obviously, shows changes from rev 5 to BASE (which is 17),
> > ignores local mods.
> > $ svn diff -r BASE -r 5 foo.c
> > ... same as above, but reverses direction of diff.
> > $ svn diff -r HEAD -r 5 foo.c
> > ... I think we're getting the idea here...
> > $ svn diff -r 17 -r HEAD foo.c
> > ... yes, it's certainly clear what this does...
> > $ svn diff -r HEAD -r BASE foo.c
> > ... you can even do this, totally ignores local mods...
> > $ svn diff -r 3 -r 19 foo.c
> > ... a more familiar way of requesting a diff.
> >=20
> > Fine, I think we get the idea. The three special rev keywords are
> > "BASE", "HEAD", and "WORKING", and of course they should work when
> > given in lowercase too. By combining these, and using one or two -r
> > flags, you can get any diff in any direction you need.
> >=20
> > Implementing (a)-style diffs is pretty straightforward. You already
> > have one of the necessary files locally, either as text-base or as
> > working file. So if you run
> >=20
> > $ svn diff -r REV foo.c
> >=20
> > or any of the similar commands, the server can just send the
> > difference (as svndiff) between BASE and REV, allowing the client to
> > create REV from that and run diff locally; the client would also take
> > care of the logic about whether or not to include local changes in the
> > diff. We avoid running `diff' on the server, which is good, since
> > it's the centralized bottleneck.
> >=20
> > But in implementing of (b)-style diffs, we have a tougher choice. If
> > you run:
> >=20
> > $ svn diff -r REV1 -r REV2 foo.c
> >=20
> > there are two ways svn can do it:
> >=20
> > 1. The server produces the diff, however it wants, and sends the
> > diff back to the client. In practical terms, this is going to
> > mean the server creates both files and runs `diff', which for
> > now is an external program but could conceivably be librarized
> > into the server someday. (In this case, librarization of diff
> > would be a bigger win for the server than for the client, since
> > saving server overhead is usually worth more than saving client
> > overhead.)
> >=20
> > 2. The server sends over the BASE->REV1 svndiff and the BASE->REV2
> > svndiff, the client creates both revisions locally, and runs
> > diff locally.
> >=20
> > CVS uses method (1). Until recently, I thought Subversion should do
> > the same thing. Now I'm not so sure; maybe it's better to only burden
> > the server with sending svndiff data to the client, and let the client
> > generate the human-readable diffs. This should result in no more
> > network usage than plan (1), and transfers at least some of the work
> > to the client, which seems a Good Thing.
> >=20
> > I guess I'm leaning toward (2) now. Thoughts?
> >=20
> > -Karl
> >=20
> > P.S. As an optimization, we can one day detect when a requested
> > revision number results in the same data as the local base revision
> > (i.e., if the file didn't change between revs 3 and 10, and its base
> > rev claims 6, then using rev 8 could -- with sufficient bookkeeping --
> > result in no network usage at all). But that's for later.
> >=20
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: dev-help@subversion.tigris.org
> >=20
>
> --=20
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kevin Pilch-Bisson http://www.pilch-bisson.net
> "Historically speaking, the presences of wheels in Unix
> has never precluded their reinvention." - Larry Wall
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> --vkogqOf2sHV7VnPd
> Content-Type: application/pgp-signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE7xgWEgJlk/lQdbnARAnvNAKCUXsT3I3t4t/sSU4N3eH4tye0e0wCePyFf
> GFAAqSZDfqmxTHO8w2QynV0=
> =VmvT
> -----END PGP SIGNATURE-----
>
> --vkogqOf2sHV7VnPd--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:44 2006