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

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

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


From: Andrea Arcangeli
Subject: Re: [Gnu-arch-users] Re: Linus Torvalds <address@hidden> Re: log-buf-len dynamic
Date: Fri, 3 Oct 2003 18:11:54 +0200
User-agent: Mutt/1.4.1i

On Fri, Oct 03, 2003 at 04:47:57PM +0100, Bruce Stephens wrote:
> Andrea Arcangeli <address@hidden> writes:
> 
> > 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.
> 
> I was also thinking of the case where you're taking modifications from
> someone who doesn't use any kind of SCM---they just have source trees
> and patches and things.  
> 
> If the information's in the source files, then there's a good chance
> they'll survive almost anything.  If it's separate, then there's a
> good chance it'll get lost, or mangled.

This problem is fixable. If I don't see the patchset ascii armored I
will press a single button in the mailer explaning them how to compile
install and generate a patchset to send by email. If they have `diff`
they sure are fine to run `tla` too to generate a readable ascii
patchset.

And for most diffs they're not renaming stuff, so it wouldn't be too
painful. The other diffs that I've to apply anyways, thanks to the
strict commits I hope they will fail commit since the file will be
tagged but it won't be there anymore.  So I can teach arch by hand with
move-tag.

> However, in the real world, only arch seems to use taglines, so there
> seems little chance of persuading Linus to add them to the linux
> sources, at least in the short term.

Yes, taglines would solve it too, but it would still be absolutely
unreadable in the email. tla has a chance to send a "readable" patchset
instead, much better than `diff` could ever do. And at the other end of
the wire it can import the ascii readable metadata separately from the
data when you merge the patchset you received by email. No data would be
lost. The email would contain only human readable payload, and no
tagline is needed.

> So yes, I agree.  This information is probably best in a file on its
> own, and it's easy to come up with such a format---it's pretty much
> what arch already uses (the ,,index files).  (Might need some
> modification to cover file names with spaces in and other horrors.)

the one he sends by email I think should be really indipendent from the
current format of explicit tags, but it should be derived from it of
course. It should be more like a "move foo.c foo2.c\nrm foo3.c\ntouch
foo5.c\mkdir xxx\nrmdir zzz" etc..

> I was just pointing out that if other SCM systems used taglines, then
> they'd be a real convenience---even when communicating with people who
> don't use any SCM.

but unreadable by humans. I mean you would need a tree unpacked in sync
with the guy who sent the changeset to apply it etc.. Merge the diff,
and ask arch what-changed.

Note, often I end up applying patches by hand and I get a flood of
patches to evaluate, so the more something I receive inlined in an email
is in a human readable format and the less it's in a machine readable
format the better. I don't want arch-id:
deadbeef-deadbeef-xxxxx-yyyyyyyyy to ever hit my email. Never. While I
want to get informations like "mv oldfile.c newfile.c" to actually see
what the patch is doing, and being able to see the diff at the same
time. That's an huge bonus. and it sounds doable with arch.

So yes, taglines let arch see the move even when the diff is generated
by `diff`, but I wouldn't claim it's optimal.

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]