gnu-arch-users
[Top][All Lists]
Advanced

[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




reply via email to

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