On Wed, Mar 14, 2007 at 05:53:10PM +0100, Charles Acknin wrote:
> On 3/14/07, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> >On Wed, Mar 14, 2007 at 12:32:26PM +0100, Erik Huelsmann wrote:
> >> I think the 2 use-cases (local changes vs patch-input) are as Malcolm
> >> says mutually exclusive. Before we start discussing actual
> >> implementations (I'm already sorry I added that example!), I'd like a
> >> list of requirements and a proposed solution to discuss. After that,
> >> we can discuss how to build that into Subversion. Agreed?
>
> To make things clear, after reading throughout this whole thread, it
> seems like the requirements are the following:
> a) keep patch(1) compatibility (this also involves not changing
> people's habits)
> b) have an output suitable enough for code review
Well, 'svn diff' currently produces (b), and sometimes works well enough
for (a), but sure.
> c) create an output that supports any change (versioning, directory
> tree, properties, files and binary-files) for later use by d)
> d) a tool that uses the output of c) to apply changes to a working copy
Yup.
> And here are the situations that might happen with versioning trees:
> 1) file: add, copy, delete, update
> 2) links: add, copy, delete, update
Links are just files that have a particular property set. Files can
change into links and vice versa without needing to delete the node.
> 3) directory: add, copy, delete, update
You missed "rename". We don't support it yet natively, but I really
would like to add support in from the start, since it's harder to do
that retrospectively.
> 4) property: add, delete, update
> 5) lock: add, delete
Locks aren't versioned, so no.
> What else? Do we really want to consider 5) as a change to be
> displayed by some diff flavor?
No. Locks can be considered to only exist in the repository at HEAD -
they're not part of the tree delta change.
> Hence Malcolm sounds right when saying there are (at least) two
> use-cases, and I suggest something slightly different to fulfill
> requirements:
>
> 1. a) and b) could be mixed together to release a patch that's
> backwardly patch(1)-compatible, that is, a) is compatible with b). At
> the same time, I guess `svn diff`'s default output could be fixed to
> an optimal use with patch(1): a file-copy would be represented from
> nothing, etc.
No, I don't think we should change 'svn diff's output by default. We've
got a lot of people hooking up 'svn diff' to mailers, etc, and if we
want to provide a more patch-compatible format, I think it should be
under a new option.
> This way we'd end up with an output so that patch(1) would able to
> cover situation 1). The most it can do, right?
Yes, so for example, a rename would be represented as a diff from the
old name to an empty /dev/null, and then another diff from /dev/null to
new name. Suboptimal, but 'works with patch'.
> I think SVK provides such an output. I did not check against rename
> (del+create?) though.
>
I'm not aware of exactly what SVK's format looks like.
> 2. c) and d) would implement a serialized format through -- as Erik
> suggested -- 'svn patch --create / --apply' command to cover 1) to 5).
> This format could be some sort of Subversion's delta or SVK's, that
> is, an compressed-base64-encoded chunk of data.
Exactly, and I think this is probably the much more interesting part of
the task - it's what I had in mind when I wrote the SoC task description.
Regards,
Malcolm
- application/pgp-signature attachment: stored
Received on Wed Mar 14 19:50:58 2007