[Gnu-arch-users] Re: taglines vs explicit (was Linus Torvalds <address@hidden> Re: log-buf-len dynamic)

[Andrea Arcangeli]

On Fri, Oct 03, 2003 at 08:42:42PM +0200, Pau Aliagas wrote:
> On Fri, 3 Oct 2003, Andrea Arcangeli wrote:
> 
> > tla is the thing that track down the changes and permits to send a
> > rename aware diff.
> 
> Usually arch projects are distributed with the arch information in their 
> tar.gz releases. You can of course eliminate all the arch files before 
> packaging, but I don't think you should.

see the other emails I sent on the matter.

the point is to preserve the human behaviour of patches.

> 
> > > People recommended you to use tagline instead of exlicit beacause it's a 
> > > superset of its functionality: you can do the same (tag manually or stric 
> > > commit as you like t call it) and ou can have tags in your files.
> > 
> > My question is why do I need the tag in the files if tla does everything
> > automatically already? You acknowledge I've to tag-move explicitly
> > anyways for the strict commit to work.
> 
> In no way I acknowledge this, not at all. You can have "strict commit" 
> with tagline or explicit, undistinctively, if you state that 
> untagged-source = junk.

I see what you mean. But what if a temporary file has a 'arch-id'
inside?

We can do things like "cat file.c.xx > file.c" then the tag will go in
both, and tla will find the clash. That's not strict commit anymore.

As said I really want to execute add/move/delete-tag, it's a feature. As
such I've to keep tagline disabled. I don't want to depend on file
contents for the revision control.

> > > Moreover, imagine that I start feeding you a new driver for the kernel. 
> > > Probably I'd stick a tagline inside :) and you'd have to live with it. 
> > >
> > > Better let both trees be "star-mergeable". And this will happen, peopl 
> > > will start tagging their linux trees from the master one.
> > > 
> > > There's no automatic procedure for moving from one method to the other, 
> > > so 
> > > that if you chose one, You'll have to stick with it (or suffer a massive 
> > > delete/add).
> > > 
> > > Please, think twice about it. If want to have a master arch tree of the 
> > > linux kernel, it would much better with taglines, even if most of the 
> > > files are explicitly tagged.
> > 
> > I'm not convinced.
> 
> Choosing the tagline tagging method , you have a superset of explicit, so 
> you give more freedom to people tagging from the archive. It has no 
> implications for you: you use explicit for your files, I use tagline for 
> the files I send. I's that easy. I don't like to tla mv :)

;)

I see you don't like tla mv. But I feels more reliable to me and really
how many times did you execute it with the kernel? There will be one
time that you will execute a dozen of them in a row, you check
everything is correct in the inventory, and you finally commit. That
sounds a reasonable procedure to me.

> > There's no technical reason for why taglines should be better. Even the
> > "send the patch to Linus that renames something" isn't optimal with
> > taglines, you want to send a "patchset ascii armored" instead with a
> > standard protocol to define renames, and even things like directory
> > creation or file deletion that patch can't express. As for the problem
> > of import from CVS, that's because Larry isn't exporting the rename
> > metadata in a standard format.
> 
> You mixup things. The generated patchset is no diffferent in any case.
> Try mkpatch.

I will.

> > My point is that there's no technical reason for requiring to merge data
> > with metadata, except to avoid running move-tag after moves, but I
> > prefer that people is forced to run move-tag, so the probability of
> > screwed commits is lower and on the long run it can pay off. The renames
> > are frequent but really not *that* frequent (at least in linux) to
> > really require an automated parsing during commit. I bet BK also forces
> > explicit tagging, and I never heard a single complaint.
> 
> I only advocate for a bit more of freedom: create the archive with tagline 
> method, add explicitly all the files, but leave the door open to new 
> contributions coming in the form of inlined tags. You lose nothing.

I just feel unreliable with taglines. And I risk pain if somebody sends
two files with the same arch-id to Linus from two different projects
(though it's a very small risk). And you force me to watch those
metadata garbage that annoys me ;)

Though if you advocate strongly I can live with it (but if it was me to
choose they would be explicit w/o taglines ;).

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/