Re: [Gnu-arch-users] Re: give us a hand with arch

[Andrea Arcangeli]

On Sat, Sep 27, 2003 at 02:25:09AM -0500, Charles Duffy wrote:
> On Fri, 2003-09-26 at 20:43, Andrea Arcangeli wrote:
> > it's not that simple. Lots of files are autogenerated. You can have an
> > arch that needs a new autogenerated file. This one will be only known
> > by make distclean (after the developer remebers to add it the first time
> > his diff is screwed or similar)
> > 
> > basically every project where source files are often autogenerated
> > you'll run into the same problem. You will need a 'dontdiff' again.
> 
> ...unless you have a convention that autogenerated filenames much have
> some particular prefix, and have *one* regex to match that.
> 

true. As you can imagine there is no convention at the moment about the
auto generated files, as far as I know we never needed such a convention
actually.  Even assuming this is the way to go, we can hardly assume
that everybody will use arch, at least in the short term, and if
bitkeeper uses strict commits (I tend to think it's the case since I
recall I've read in some email floating in l-k Larry mentioning bk
rm/add ala cvs so I assume it's keeping track of what's in and out the
repository), those conventions won't be of any value in the first place
for the bitkeeper users. Also it's just hard to enforce a codying style
in all subsystems, enforcing regexp and name conventions for
autogenerated files and scripts sounds not immediatly feasible (even if
we really wanted to). We have all sort of autogenerated files, link
scripts, .c files, .h files, entere directories etc.. And still you can
do a mistake (even while running patch -p1 while you receive an email
with a patch attached like it happened to me recently) that the strict
commit would trap more reliably.

Oh, of course compiling the kernel out of the tree would also make this
more or less a non-issue (though it wasn't possible yet in 2.[56] the
last time I tried, somebody worked on that area so there are at the very
least patches to make it possible), but still I'd prefer the strict
commits over a regex, even if I would compile the kernel out of the
tree, and in turn all the autogenerated files would be outside the arch
tree. And many other projects have to be compiled inside the tree, we
can't expect to convert all of them istantly, nor to all enforce
istantly a convention on the autogenerated files as one or more
developers switch to arch and as they get used to the right way (and at
the moment I'm not really convinced that's really the right way
personally). Enforcing conventions to make the tree more readable sounds
fine, but this one sounds more a workaround for the lack of strict
commits to me than a real benefit in terms of maintainance (but I could
be wrong).

My point is that I see many more benefits in having the strict commits,
the regex maintainance avoidance and higher reliability is just the
biggest one, even while compiling outside the tree.

Andrea - If you prefer relying on open source software, check these links:
            rsync.kernel.org::pub/scm/linux/kernel/bkcvs/linux-2.[45]/
            http://www.cobite.com/cvsps/
            svn://svn.kernel.org/linux-2.[46]/trunk