[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: fedora core 2 will include subversion (and not

From: Colin Walters
Subject: Re: [Gnu-arch-users] Re: fedora core 2 will include subversion (and not gnu arch)
Date: Thu, 26 Feb 2004 19:13:15 -0500

On Thu, 2004-02-26 at 17:37, Brian May wrote:

> My version of cat-log says it requires a parameter.

Right, as I said, the scripts were untested :)

> Also, if given a parameter of "xyz.c", I think the above would match
> entries with "abcxyc.c", "xyzbc" both in the *-files headers as well
> as the summary.

Also true.  It should be sufficient to prefix and suffix the regexp with
a space though (at least until tla starts supporting filenames with
spaces in them, not sure what will happen then).

> Personally, I would like tla to look up the file ID of "foo.c" in the
> currently checked out version, and use this ID to do the comparison
> (and if it doesn't exist, treat the file as new or deleted).

I agree, that is probably the most common interpretation - here you're
placing more precedence on the latest revision, and you're interested in
the file identity.  But is that always what you want?  If I was
interested in asking simply "how has the content at this filename
changed over time", I might think file-delta did what I want, but it

tla is exactly right in not even attempting to bolt on commands with
ambiguous semantics like this.  Compare with Subversion, where they
tried, and as Ben Collins-Sussman says in "Dispelling Subversion FUD"¹

"'svn diff' doesn't follow history. Subversion makes a lot of noise
about the way branches (copies) of files and directories maintain
historical connections to their source, but only 'svn log' actually
follows that history, not 'svn diff'. You can work around the problem by
using 'svn log' to discover the proper arguments to 'svn diff'. But it's
still an annoyance."

They just decided that they had to emulate the CVS command set as much
as possible, even where it doesn't make sense or is ambiguous.  I'd call
that a mistake.

Personally, I think the right way to solve it is with a GUI browser that
makes the distinctions clear.  For example, you could click on a file
and select "Applicable Changesets" (or something), and see a list of
changesets that affected that file identity, including renames.

If you wanted to answer the second question, you might have a split-pane
view of two different patch trees, and select "Diff".

> So if for instance, if the history is
> patch-15 foo.c --> bar.c; baz.c --> foo.c
> patch-45 bar.c --> dog.c
> and the current checked out version in patch-60, and I request the
> differences between dog.c in patch-10 and patch-30, I would want it to
> find the diff between foo.c in patch-10 and bar.c in patch-30. Is this
> possible?

Of course it's possible - just do 'tla get foo--bar--1.0--patch-10
foo-10 && tla get foo--bar--1.0--patch-30 foo-30 && diff -u foo-10/dog.c

But this is a good example of more ambiguity.  Does this hypothetical
"file-delta" command look your working tree or not (if any)?


Attachment: signature.asc
Description: This is a digitally signed message part

reply via email to

[Prev in Thread] Current Thread [Next in Thread]