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

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

Re: [Gnu-arch-users] Re: taglines vs explicit


From: Stephen J. Turnbull
Subject: Re: [Gnu-arch-users] Re: taglines vs explicit
Date: Sun, 05 Oct 2003 20:00:13 +0900
User-agent: Gnus/5.1001 (Gnus v5.10.1) XEmacs/21.4 (Portable Code, linux)

>>>>> "Robert" == Robert Collins <address@hidden> writes:

    Robert> On Sun, 2003-10-05 at 18:15, Stephen J. Turnbull wrote:
    >> >>>>> "Robert" == Robert Anderson <address@hidden>
    >> writes: While both of them have their points, the last thing
    >> (eg) Linus wants to see is Andrea using strictly explicit,
    >> Miles using taglines with uuidgen taglines, and Pau using
    >> tagline with descriptive taglines, which is a distinct
    >> possibility if the kernel were to use tagline.

    Robert> You seem to have fallen into the same conflation trap.

    Robert> explicit suffers from -exactly- the same sample problem
    Robert> you propose for tagline.

Excuse me?  If you use explicit, Miles and Pau will get tree-lint
errors when they try to commit unadded files.  No?  True, they can add
tags to existing files if they want, but why would that be a common
behavior?  And if they do, under explicit you just remove the tag and
you're back within coding standard again, with no possibility of weird
breakage in file history.  (Granted, somebody who mv's a file will get
breakage, but that's not weird, that's CVS.  :-P)

My point is simply that the restricted behavior _is_ more restrictive,
as rwa said, and that this is sometimes desirable, for example in large
projects already familiar with similar restricted behavior.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.




reply via email to

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