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 17:33:21 +0200
User-agent: Mutt/1.4.1i

On Thu, Oct 02, 2003 at 07:18:02PM -0700, Tupshin Harper wrote:
> Miles Bader wrote:
> 
> >Tupshin Harper <address@hidden> writes:
> > 
> >
> >>Agreed that this is research, but it does have interesting 
> >>possibilities. First of all, I should have referred to partial file 
> >>content move instead of code move. So if you have any pairings of 
> >>content deletes and similar content adds, then detect, and (with or 
> >>without human intervention), record that pair of deletes and adds as a 
> >>single "content move".
> >>   
> >>
> >
> >It might be interesting to see, but at least for arch, a file's the
> >smallest named entity anyway, so what would you do with this
> >information?
> >
> >-Miles
> > 
> >
> First of all, I will not claim that this is fully thought out, however....
> 
> * Removes storage redundancy. Currently a 50 line content move is 
> represented as a 50 lines of deletion and 50 lines of addition. This 
> would allow those 50 lines to be stored once
> 
> * Stores more information. It is valuable information that content was 
> moved from one location to another. If somebody looks at the change 
> history, this would make it more obvious what took place
> 
> * Could allow for more intelligent conflict resolution tools in the 
> future. A tool that could show the diff in its current context and its 
> previous context could make the resolution process easier, particularly 
> when multiple content moves are involved in a single conflict.

one other reason is to be able to actually audit the changes to the file
that happened at the same time of the rename. I think this is the major
reason infact: the auditing. In a project like the kernel the auditing
is by far the most important thing to preserve. Reading patches is a
fundamental thing that allows to evaluate the changes.  When you've a
rename in the middle of the patch, you can't read the patch anymore. so
you've to apply it and diff by hand the new filename against the old
filename. So it'd be nice to send patchsets by email, that preserve
inlined the whole changes and they send some _readable_ metadata at the
end like "move foo.c foo2.c".

this patchset format would be like an ascii armor format, even more
readable than a patch, it will be very aesthetical much bigger in bytes
than the normal tar.gz patchset, with the minimal info needed to apply a
patchset without losing information in another tree with a command
equivalent to a merge. Then we can basically obsolete diff and patch
(well not really obsolete, tla uses them, but they'll sit at the lower
layer, and we'll work only at the upper layer).

Miles sent a patch for cscvs a few days ago, he could send ascii armored
patchsets in the future instead.

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

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]