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

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

[Gnu-arch-users] Re: taglines vs explicit (was Linus Torvalds <address@h


From: Andrea Arcangeli
Subject: [Gnu-arch-users] Re: taglines vs explicit (was Linus Torvalds <address@hidden> Re: log-buf-len dynamic)
Date: Fri, 3 Oct 2003 20:08:30 +0200
User-agent: Mutt/1.4.1i

On Fri, Oct 03, 2003 at 07:10:51PM +0200, Pau Aliagas wrote:
> On Fri, 3 Oct 2003, Andrea Arcangeli wrote:
> 
> > Miles sent a patch for cscvs a few days ago, he could send ascii armored
> > patchsets in the future instead.
> 
> I think that cscvs already tries to detect renames automatically.
> 
> > Probably they won't be much bigger than a compacted regular patch + 
> > changelog +
> > mv foo.c foo2.c at the end (again no unique-id:
> > xxxxx-xxxxxx-xxxxxx-xxxxx, that's a workaround).
> 
> You are wrong with the implicit tags. They are unvaluable in large 
> projects. Imagine that you are reorganising a part of your tree, move 
> files and dirs around, edit etc. now you want to sync with mainstream.
> 
> Unless there's some kinf of tagging, be it inlined, be it explicit, you'll 
> easyly lose track of the files to patch.

tla is the thing that track down the changes and permits to send a
rename aware diff.

> What do I mean? What you call "strict commit" is nothing else than 
> explicit tagging + untagged = junk. We are saying the same thing: we need 

yes.

> a tag per file. You chose to add it via a command (it really goes to a 

sure. We need a tag per file.

> .arch_ids/file). There's people, and I count among them, that prefers 
> inserting the tag inside the file and forget completely about it.

My point is that I don't even want to learn about it, so I don't need to
forget it ;)

> Semantically, we do the same thing, but whilst you'll have to mv the tag
> manually for renames, I'll just mv the file and be done. I too do have

yes.

> strict commit. And, if I want, I also can use the commands to tag files.

Yes.

> 
> 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.

> 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. 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.

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.

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/




reply via email to

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