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
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
And here are the situations that might happen with versioning trees:
1) file: add, copy, delete, update
2) links: add, copy, delete, update
3) directory: add, copy, delete, update
4) property: add, delete, update
5) lock: add, delete
What else? Do we really want to consider 5) as a change to be
displayed by some diff flavor?
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.
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?
I think SVK provides such an output. I did not check against rename
(del+create?) though.
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.
Does that make sense?
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 14 17:53:26 2007