[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: tla changes
From: |
Miles Bader |
Subject: |
[Gnu-arch-users] Re: tla changes |
Date: |
05 Jan 2004 12:53:45 +0900 |
Brian May <address@hidden> writes:
> For instance, not only does it list {additions,deletions,renames} to
> source files, but it also lists {additions,deletions,renames} of the
> corresponding .arch-ids/*.id files, too.
>
> I consider this unnecessarily, as it should be implied that the *.id
> files will have been changed with the corresponding source file.
I kinda agree, but note that there _are_ situations in which you can end
up with a change to a .id file, but no corresponding change to a source
file (I don't remember the exact situation, I think it had to do with a
file that stopped being a source file because of a =tagging-method
change).
In such a case, I think it should still list the .id file change -- that
is, for every change, there should be _some_ indicator in the `tla
changes' output (`tla changes' output should never be empty if there is
in fact some change), even if in some cases related changes are on
occasion merged.
Given this, I can think of a few issues:
(1) Is it acceptable to have `inconsistent' output like this
(sometimes .id files are listed, sometimes they aren't)?
I think for a human this is OK, but maybe there are some automatic
uses of changeset output that could get confused; having an option
to force `complete' output should probably cover those cases though.
(2) The changeset summary output is produced incrementally (sometimes,
at least), so I wonder if there are times when it might not be
_able_ to see both halves of change and know to suppress one of
them.
-Miles
--
"Most attacks seem to take place at night, during a rainstorm, uphill,
where four map sheets join." -- Anon. British Officer in WW I