> "Patch awareness" might be useful but it doesn't seem like you or we have a
> very clear idea of what it means.
I deliberately did not go into too much detail in my first mail, and you are
right in that I do not have a detailed plan of what I want yet. At first, I
have looked at this mainly from a user's perspective, since I have no svn
development experience yet.
Parts of what I am writing down here are made up as I'm writing, trying to put
as much of my thought processes down here :-)
> 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 aware of that, yet since making a good design is half the fun (IMO), that
checks out ;-)
> 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?
The most obvious solution would be to just store unified diffs in as text
files in the repo in some way. This would of course ignore tree changes, so it
would only do as a quick-hack-solution.
Using a tree-aware contextual patch file format would make things more usable,
but still not very robust (I think).
Actually using svn's internal diff format, would seem as the best solution.
This way, the patch is stored just like it was commited already, and is
closely linked to the revision it was created against. Thinking of this, such
a patch is more like a one-revision-branch. The two differences with creating
a real branch I can come up with right now, are userfriendlyness and
authentication.
One can more easily apply, test and commit a patch and more importantly,
maintain status information about patches (applied yes/no).
With patches in the repository, one can allow everybody to submit patches,
while only letting the dev team merge patches and do commits. Optionally, you
could also limit the patch uploading to a group of people ("contributors"?).
Thinking of this, one could also do this by branching into an "upload" directory and
deleting the upload branches after they were merged. This last solution does
require different access rights for different directories. The main
disadvantage of doing things this way, is that people can flood your
repository with branches (and revs) which are not removable.
> 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?
I was thinking of only managing patches applied to a working copy, in that
working copy's .svn dir. But, now that you mention it, it might be useful to
store patches in a central (per-user) location (such as ~/.svn) so that they
can easily be applied to new working copies. Probably both can be supported,
starting with a non-central approach.
> 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?
The answer to your first question is sortof answered by my (ununderstable)
remark. What I mean, that if a patch is created for revision 10, and after
some time the patch is applied to revision 15, conflicts might occur. By
taking into account the changes between r10 and r15 in the merge process, I
expect one can reduce the number of conflicts and increase the reliability of
the merge process.
Also, the feature described below is not possible from a wrapper script (or
one would need to do very ugly diffing of diffs or something...)
> 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?
Yes.
> You also consider managing patches on the repository server. What features
> and implementation would this have in common with the WC-patches?
I realise now that essentially, these are two different features. Right now I cannot
really think of anything that would really overlap between these two features.
In that light, I think I would probably concentrate on the WC-Patches feature
first.
> Lastly, how does your patch awareness compare with the use of branches for
> patch management?
As stated above, patches are stored similar to one-revision-branches.
In another reply, John Peacock mentions SVK's patch management and diff
format. I have already looked at SVK and think there are a lot of good things
in svk. Yet it's patch management is nothing more than central storage of
patches in a repo. Patches are stored as normal text files in the repo, and
once applied, no special treatment is given to them.
As for the tree-aware diff format they are using (according to John), I have
not looked at that. When implementing WC-Patches, I will probably add support
for a tree-aware patch format too. I'll look at the svk format if it is usable
for svn.
[ From your other reply: ]
> By the way, I didn't mean that you should go away and design the whole thing
> yourself before the the Subversion project can consider your design. We
> will help with the design, but the more concrete your plans are, the more we
> will help (and criticise)!
So I'll just make them more concrete, one step at a time :-)
I appreciate you taking the time to look at my thoughts, since it is a great
help in organising them :-)
Gr.
Matthijs
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 8 20:14:31 2005