Hi, and welcome!
On 3/13/07, Charles Acknin <charles.acknin@gmail.com> wrote:
> Once the serialization format is designed and implemented -- that is,
> task's boundaries as stated in "An augmented diff representation"
> descriptive paragraph -- we might land up with a new rich-diff
> support, i.e. a diff that will support any change on a working copy,
> from structural changes to metadata's, as with Subversion's delta
> format. Above all, this new diff will be able to *display* those
> changes.
Yes, an augmented diff representation would ideally store information
about both structural changes (directory add/remove...) and metadata
tweaks. In my perfect world, this augmented representation would be
backwards compatible with the unified diff format, in much the same
way that SVK does it: by tagging on some extra data that GNU
diff/patch politely ignore, but that convey extra information for
readers who understand it. That doesn't prevent coming up with another
format that might be more readable and whatnot, but imo backwards
compatibility with GNU diff/patch for the basic delta information is
important.
> Now the idea is to use this rich-diff-display facility to help
> integrate the patch shipment within Subversion: a user could submit (
> != commit ) a patch from his svn client to the repository so that:
> a) the patch is put under revision control
I'm split on the use of version controlling a pending patch. Usually,
the review process for a patch implies many fundamentally
uninteresting changes: "Tweak this function name", "you need an extra
new-line here", "don't put a space-before-parenthesis"...
I don't see the point of version controlling these changes (and even
if you do want to, you can use svn branches to do that). However, a
server-side "shelf" for storing unversionned patches might be
interesting. I'm just wondering if that should be in the core svn, or
as a third party tool.
> b) from any client everybody can view it; this is where the
> rich-diff-display facility joins the party
> c) from any client everybody can use it: get a copy of the patch
> from rep to wc, apply and test it
> d) meanwhile, the community can still talk about the patch through
> the mailing list, referring to the patch in the same way we do it for
> a bug ( #id and/or link )
> e) once the patch is stable, user with commit access can apply it (
> == commit ) to the rep
Coming back to the above comment, a lot of this could be done with a
tool external to Subversion on the client and server. I'm not saying
it should be that way, but we have a tradeoff: should it be in the
core svn, or should it live as a third party tool?
Also, integrating such a patch store into Subversion raises a lot of
design issues. For example, how do you keep submissions open to
everyone without opening a breach for denial of service attacks?
So, overall, I think that it might be interesting to integrate patch
management more, but I also think that this might be better as a
separate add-on project. As such, it's probably not a good idea to add
that to the augmented diff task.
However, you're more than welcome to apply for the augmented diff
representation task, and either convince us that patch management
should be in the svn core, or develop a streamlined patch manager as a
separate tool. In any case, having a diff representation that can
contain all the information on all kinds of changes svn can make is a
prerequisite.
- Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 13 17:57:48 2007