Matthijs Kooijman wrote:
> I have been thinking of working on subversion for a while since I started
> using it, and I thougth the Google Summer of Code would be a nice occasion.
>
> I'll give a short description of what I would want to do, and if you can get
> all the way through, I'd like to hear some opinions.
"Patch awareness" might be useful but it doesn't seem like you or we have a
very clear idea of what it means. Could you describe your ideas in more
detail? The questions I ask below are intended to be the questions that you
should ask yourself in order to design the feature; I'm not looking for easy
answers. Be aware that this design phase might well amount to half of the
total work involved in implementing the feature.
> I am thinking of making svn "patch aware" (doesn't that sound buzzy? ;-)
Are you planning to design a tree-aware textual patch file format, or to find
and use such a format, or not to handle textual patch files but just store them
in an internal binary format, or ignore tree changes for now and leave that for
a later extension?
Are you planning to add a patch manager to Subversion, that provides commands
for storing, listing, finding, using and deleting patches in a central storage
place, or is the user going to store the patches as plain files wherever he
wants to keep them?
> This means that one can use svn to apply patches.
Are you planning to be able to apply and unapply patches in a manner that is
functionally different from a script that automatically applies a normal
textual (or tree-aware) patch file and fails if it doesn't apply cleanly, or
are you focussing on providing the infrastructure and user interface to more
tightly integrate that equivalent functionality?
> This has the advantage that
> the revision the patch was created with can be taken into the merge.
What do you mean by that?
> Furthermore, svn can record the patch as being applied. This can optionally
> affect subsequent diff, commit and maybe other commands. For example, if I
> have a small patch that enables some additional debugging information that I
> want to have applied to my working copy, I let svn apply it. When I make more
> changes and then commit those changes, the changes to the working copy from
> the applied patch could be ignored.
So the Subversion client is aware of patches that have been applied to the
working copy and not yet committed. "The changes in this WC relative to its
base revision consist of patches A and B, and any other changes not part of
those patches are the work in progress." So it would contain a patch manager
like I described above, with the patches being stored locally to the user?
You also consider managing patches on the repository server. What features and
implementation would this have in common with the WC-patches?
Lastly, how does your patch awareness compare with the use of branches for
patch management?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 8 12:19:59 2005