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

[Andrea Arcangeli]

On Fri, Sep 26, 2003 at 05:36:00PM -0700, Tom Lord wrote:
> 
> 
>     > From: Andrea Arcangeli <address@hidden>
> 
>     > Sorry but I think tagline is the worst mode. I prefer it's unable to
>     > merge, than to see a file called hello.c to have a comemnt me.c that
>     > could stay there forever just because ages ago it was called me.c. How
>     > ugly it is when you go read the code? Also I'm unsure what happens if
>     > you move it across directories.
> 
> Heh.  `tagline' doesn't require that at all.... it's just what my
> emacs template that generates tags happens to do for no particular
> reason.
> 
> Whether or not `tagline' is good really depends on how you're used to
> managing sources.   `tagline' does a pretty good (not perfect, but
> pretty damn good) job of eliminating a need to ever run any revision
> control commands just because you've moved files around.   So, for

yes I see that, but I need the revision control command anyways, or I
can't do the strict checkins... so the autogenerated IDs in the metadata
outside the files wouldn't impose any restriction, since I need the
strict checkins anyways.

What I'm saying is, since I sure need the strict checkins for multiple
reasons, there's no need for me to even think of which could be the best
or worst tagging mode. I've to live with the tla commands anyways. so
there's no point for me to pollute the source with an unique ID. And
there's no need for me to be asked to generate an unique ID either, tla
can choose it better.

So I just ask tla to go in 'strict-commit-mode' in ~/.arch... and it'll
just stop me asking for what tag mode I prefer. It'll just autotag
everything with unique id etc.. IMHO this is a much better default than
the current one, but that's just my opinion ;). Being strict is much
more reliable to avoid merging garbage into a commit.

Of course after the commits are stricts the -j -u options and similar
can go away, since the inventory will know for sure what's "known" and
not "junk".

IMHO it would be reasonable to even leave this strict mode as the only
option, I don't think it would break backwards compatibility too much,
and some people will sure prefer the old behaviour, but I think this
would be a better default. However I don't want to argue about these
bits, as far as I can use it my way I'm just fine ;)

> example, you can use your favorite directory-editor/file-manager to
> shuffle sources and you don't have to teach it to fork/exec tla
> instead of using rename/unlink/rmdir(2).

I see that. Actually a LD_PRELOAD could do that too, but I guess it'd be
overkill.

>     > you're still thinking at a small project methinks.
> 
>     > With the kernel there are tons of exceptions, somebody wrote a dontdiff
>     > (writing the dontdiff is the very same problem of defining what is junk)
>     > but it has to be maintained and it keeps breaking all the time, see my
>     > last version (and I had to stop using it because it just keeps getting
>     > garbage every once in a while so it forces me to check every diff).
>     > Likely the below won't work for 2.5 for example. The kernel is a big
>     > moving target.
> 
> It's funny.   Not something worth arguing over.
> 
> But from where I sit: _you're_ the one applying small project thinking
> to a large project.
> 
> Imposing (gasp!) the horrifying discipline (shocking!) of `inventory'
> would make the moral equivalent of `dontdiff' robust -- seems like a
> good thing to do for a large tree in a busy project.
> 
> Somebody wants to add some new name in some part of the source or to
> the things that might wind up in the source tree -- with an
> `inventory' discipline, they have to think about it and make the
> trade-offs up front.  Without that discipline, it's a free-for-all and
> any contributor can add to the hair for everyone else.
> 
> Your observations about having to abandon `dontdiff' illustrate that
> the process currently used is horked.

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.

And I don't want to risk that a simple `>foo.c' on the bash goes into
the tree.

> If anything, it'll be a good sign when people start saying things
> like:  "Say, we can get a separate distribution that contains just
> inventory, the tag management tools, mkpatch/dopatch, and the
> to<->from email changeset tools?"
> 
>     [long list of dontdiff globs]
> 
>     > this has no way to scale, the above has to be part of arch too to work
>     > distributed, it can't be a local knowledge because it changes remotely
>     > too.
> 
> "The question is," said Humpty Dumpty, "who is to be master - that's all."
> 
> A little coding standard or two can answer that question with "nobody
> in particular --- it's not an issue any more."

Again, this is about forgetting to add these new .h autogenerated files
to the dontdiff too.

It's not about coding standard, it's about generating a new file, and
because you're developing fast and the thing works you checking without
updating the make distclean. That's a bug too, and this way you can
catch it before the file is propagated.

> 
> 
>     [sample tagline tag]
> 
>     > how ugly can that be? It's a totally broken idea to put metadata mixed
>     > with the data. Files are there to be nice to be read. we must not
>     > pollute our eyes with metadata, 
> 
> You mean like copyright notices?   Really, just stick it at the bottom
> of the file and you'll hardly notice it's there.
> 
> 
>     > that's why all the metadata is in
>     > {arch}, so an ls as well gets the less possible pollution. I also
>     > dislike the metadata for emacs indentation at the end of the file.
> 
> 
> I agree that minimizing these things is best.   But there are trade-offs.
> 
> 
>     > sorry but I think the tagline is the very worst method. I'd sure prefer
>     > names to tagline ;).
> 
> 
> ";)" means you're joking, right?   
> 
> arch can enhance the project with the liberty to reorganize sources in
> a managable way.   To use `names' method is to decide that such
> reorganization is not important.

I doubt this would work, and I really prefer the strict checkins.

There is no way I can maintain an huge regexp.

And I do really believe this is also about the size of the project and
the moltitude of users doing development, strict is safer. After I've
strict the pollution in the data can't provide any further value.

> 
> 
>     > It can work well in a small project where you all use arch, but with
>     > linux and a moltitude of users using all sort of different tools the
>     > data has to be clean, and the checkins have to be strict IMHO.
> 
> Well, allegedly BK can handle tree-deltas, right?   I think you might

dunno.

> want to consider what I suggested:  inventory, tags, and changeset
> tools as something that can be factored out and used by users of any
> (or no) revision control system.
> 
> Perhaps even if there's no likelihood of Linus using arch anytime
> soon, he might nevertheless use `dopatch'.

I'm quite convinced if there's no strict checkin, Linus wouldn't
consider it, I actually wouldn't consider it either knowing more or less
how things goes on in practice (i.e. dontdiff maintainance and random errors)

I'm perfectly fine to have everything optional, I'm not trying to force
the strict mode on anyone, however I do believe the strict model to be
superior because safer. Adding file is so rare, that doing a few tla add
shouldn't be really a problem.

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