Re: [Gnu-arch-users] Re: Re: Linus Torvalds <address@hidden> Re: log-buf-len dynamic

[Andrea Arcangeli]

On Fri, Oct 03, 2003 at 01:33:10AM +0100, Bruce Stephens wrote:
> Charles Duffy <address@hidden> writes:
> 
> > On Thu, 2003-10-02 at 18:26, Bruce Stephens wrote:
> >> I presume humans only need to be involved when you're trying to import
> >> a new tarball or something (where BitKeeper can't know how files have
> >> been moved around).
> >
> > ...the example you provide being also useful as a case-in-point
> > regarding the advantages of tags internal to the source.
> 
> Yes.  (I almost commented on that.)  This is a case where taglines
> would be of use, and could be used by things other than arch.

and that's again the wrong way to do it.

the right way to do it, is to have the metadata exported in a standard
format, so other SCM can import it.

There's no point in carrying this metadata in a rpm package, your eyes
should never hit the metadata while coding, nor you should waste disk
space with it.

The metadata only makes sense when you've something like arch or
bitkeeper doing something useful with it and as such it should be
separated, not in /usr/src/linux or in /usr/include/linux, that's what I
call _data_, not an unique-id: xxxxxxxx-xxxxxxx-xxxxxx needed only while
doing development under a SCM.

Now there's no standard format to encode this information, cvs hasn't it
either, and that's why you want to pollute the data, because that's the
only solution available with the current software. This is reasonable,
but it's not the best solution, it's more a temporary workaround than a
solution IMHO.

Again, don't take me wrong, I'm fine taglines exists, I'm just trying to
explain why you are using them mixed with the data, and that there would
be better ways to achieve the same object without the user being forced
to see the metadata with its eyes.

If Larry will export the tree in plaintext changesets we should ask him
to export the tags too (they have to be explicit or we would have
already noticed), so we can import them properly issuing the tla
move-tag before the commits.

In the meantime since we lose this info with cvs, we can use the perl
script that Paul Hedderly wrote, while importing from cvs the first
time. So the "explicit" metadata will be generated in the primary arch
tree and everybody will get it by fetching the tree. It'll be very
costly to generate it, but we should do it once for all. I presume
rewriting the algorithm in C can boost it since it's very cpu bound.

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/