On Mon, Feb 08, 2010 at 03:22:56PM +0100, Ulrich Eckhardt wrote:
> On Friday 05 February 2010, Stefan Sperling wrote:
> [ Overview of SVN 1.7's 'patch' command ]
>
> Stefan, thank you for that overview!
>
> I have a question that touches that topic and which I stumbled over sometime
> in the past about possible sources and targets of merge operations:
>
> 1. Source being a working copy with modifications.
> The idea is to use this to shelf some changes.
That is possible, to a degree. With 1.7, you will be able to use
svn diff + svn patch for offline shelving of textual modifications
to files. You can do the same today with svn diff + normal patch,
but svn patch will also handle files or directories which have been
added or deleted.
$ edit x # start cool feature
# ...oh wait, need something else first!
$ svn diff x > ~/shelved-x.diff
$ svn revert x
Reverted x
$ edit x # do something else
$ svn commit x -m "something else"
Comitted revision N
$ svn patch ~/shelved-x.diff
U x
$ edit x # continue cool feature
I've already used svn patch like this myself occasionally.
But it won't work correctly for copied or moved files or directories.
For post-1.7, we're planning to make svn patch handle copies and moves.
If we manage to do that, the above will work nicely even if you made
tree changes to the working copy.
Note that you would also want a queuing mechanism for your patches,
like mercurial patch queues:
http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html
With this, you could manage several patches at once and layer them
on top of one another.
There has also been talk among developers to implement "true" offline
commits in wc-ng (stored directly within the working copy meta data).
So it may be that implementing patch queues won't be necessary. We'll see.
> 2. Target being a non-working copy.
> I don't remember where I wanted to use this one, I believe I wanted to apply
> changes I made to an SVN vendor branch to a (non-versioned) release of that
> vendor or to some code in a completely different VCS.
Why not use the normal patch command then?
We're not trying to replace the normal patch command. We're creating an
augmented patch implementation for use with svn working copies.
svn patch is geared towards svn working copies. E.g. it won't know how
to add or delete files in a working copy of a different VCS, so it does
not offer any benefits over the traditional patch command for this use case.
Some other VCS have similar features (e.g. see git apply or hg import),
and I doubt they work on non-working copies.
Stefan
Received on 2010-02-08 16:04:52 CET