[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

summer of code 2007

From: Charles Acknin <charles.acknin_at_gmail.com>
Date: 2007-03-13 17:08:46 CET

Hi folks!

I'm a student closely looking into GSoC and much interested in
Subversion since I've been using it through many projects. After a
look at the "What Needs Doing" page
(http://subversion.tigris.org/project_tasks.html), I started thinking
seriously about the task named "An augmented diff representation" to
such an extent that I've come up with an idea, some kind of proposal
that could be appended to the task itself:

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

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

Today we send patch as an attachment to roughly and hardly perform
steps 'b' to 'e' with mail readers. The current idea proposes to
enhance patch management and cohesion of Subversion collecting patches
in a centralized place (within the repository) and to avoid the mess
of mail readers when dealing with patch review like inline/attached
concerns.
]]]

I'd like to get feedback on this proposal/extension. Is it
worthy/useful? Could it be merged into the legacy proposal? Does it
fit within the time frame allocated to the GSoC?

Thanks

Charles

---------------------------------------------------------------------
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:09:07 2007

This is an archived mail posted to the Subversion Dev mailing list.