On Fri, Feb 05, 2010 at 10:08:02AM -0700, Alan Leung wrote:
> Hi,
>
> I am interested in a svn patch command and noticed that something
> related was committed to trunk based on the discussion in
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=511
>
> I built the version 1.7.0-dev from trunk this past week and did some
> testing.
>
> However, from what I can determine, svn patch neither
> applies SVN property differences nor regular file differences
> properly? Can someone please confirm and/or clarify about the
> current svn patch functionality available? I realize this is not
> an final release.
>
> I can provide the exact steps/commands I used if that helps.
The current implementation has diverged significantly from the
original ideas proposed in issue #511, and the initial 'svn patch'
implementation which was developed on a branch and merged to
trunk at the beginning of 2009.
Right now, we're aiming at reproducing the functionality of the UNIX
patch command, plus some gimmicks we can make it do without extending
the unidiff format. Once the basic feature set is working in 1.7,
we'll look at extending it for 1.8 and beyond.
What it can do now:
- It can apply unidiffs to a working copy, with stripping leading
path components from the patch targets (like patch -pX),
line offset searching, and fuzzy matching.
(Not sure why applying file content does not seem to be working
for you? If it does not, please let us know what's going wrong).
- It can do a dry-run, like svn merge, so you can check for rejects
before actually applying the patch.
- It knows how to 'svn add' and 'svn delete' files, but infers
related information by looking at the patched result only.
- It creates .svnpatch.rej files for hunks which are rejected.
The files are reported as conflicted in the output but are not
yet marked as conflicted in the working copy.
- It handles svn:keywords and svn:eol-style transparently.
You do not need to do anything to make it apply patches to files
with keywords expanded, or apply patches containing expanded or
unexpanded keywords (assuming you've specified the keywords in
svn:keywords on the patch target correctly).
It should preserve whatever EOL-style you set in svn:eol-style,
no matter what EOL-style the patch file is using.
If no svn:eol-style property is set on the target file, it should
use whatever newline character the patch adds to the target file.
(But we still have to write proper unit tests for all EOL cases
to make really sure they all work.)
- It can apply patches in reverse, like patch -R (as of r907016)
What it cannot do yet, but is planned for 1.7:
- Mark files which had rejects as conflicted in the working copy.
- Combine deletions such that if a patch removes an entire subtree from
a working copy, that subtree will be deleted with a single svn delete
operation.
What it cannot do, and likely won't for 1.7 (but maybe 1.8):
- It cannot apply differences to svn properties. Sorry.
- It does not know about copies or moves
(We're planning to add support for git/mercurial-style diff format
extensions to handle copies and moves, as well as applying
differences to svn properties with similar, custom, extensions
to the unidiff format -- this also implies adding corresponding
support to svn diff).
Note that svn diff has learned a new --show-copies-as-adds option,
to make it produce patch files suitable for application with svn patch
even if files have been copied or moved (but for now, svn patch will
just add those files, not copy or move them).
Help with testing or development is definitely very welcome.
We're already pretty close to completing the basic feature set,
so wide testing can be encouraged at this point.
Development is still pretty active, please update at least daily while
testing. You can also check the commit mailing list for new commits
related to svn patch.
Thanks,
Stefan
Received on 2010-02-05 20:06:31 CET