You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Näslund <da...@longitudo.com> on 2010/07/28 10:06:11 UTC
GSoC Progress report
Hi!
Property diffs
===============
* We can create parseable prop patches
* We can parse property patches
* We can match property patches
* We can write patched properties to tmp files
* We can install those prop changes to files and dirs (not the wc-root dir yet)
Todo
------
* Decide on how we want notification for property patches.
* Decide on how to handle SVN_ERR_ILLEGAL_TARGET (i.e. returned from
svn_wc_prop_set() when trying to set svn:executable on a dir or
svn:ignore on a file.
* Decide on how to handle SVN_ERR_BAD_MIMETYPE (if svn:mime-type is not
valid).
* Allow wc-root dirs to be patched for props
* Fix a bug in how 'svn diff' displays context lines for overlapping
hunks when dealing with property diffs. (diff_test 54)
* Make 'svn patch' notify if a property to be modified does not exist.
* Make 'svn patch' notify if a property to be deleted does not exist.
* Tests with different eol.
* Tests with many different kinds of props on a target (add/del/mod).
* Decide on how to handle binary props.
Git diff format
==================
* We can create add/del/mod/copy patches for WC-WC diffs (if using
--git-diff flag and --show-copies-as-adds for copies)
* We can create add/del/mod patches for URL->WC and URL->URL diffs
* We can parse git diffs.
Todo
-------
* Remove the --git-diff flag and make the git diff format standard. The
flag was introduced to avoid excessive use of #ifdefs and since I
wrongly interpreted the git unidiff format to not include hunks for
deleted paths. If someone has objections to use the git diff format as
standard, do speak up!
* Record copyfrom for URL->WC
* Record copyfrom for URL->URL
* Rearrange a bit in the patch code to allow us to keep the current
behaviour for unidiff where we delete files where all lines are
deleted and add files that did not previously exist. But we should
also be able to handle explicit add/del/copy/move operations that were
recorded from a git unidiff patch.
* base85 encode binary content
Note that we won't be able to track moves unless we start matching
copyfrom with deleted paths and that may get a bit involved. We might
just seattle for tracking copies at the moment.
Cheers,
Daniel
Re: GSoC Progress report
Posted by Branko Čibej <br...@xbc.nu>.
On 28.07.2010 12:06, Daniel Näslund wrote:
> * base85 encode binary content
>
Does git do that? Hmmm ... I'd have used base64 myself, not quite as
compact but a lot more existing tools and libraries understand it.
-- Brane
Re: GSoC Progress report
Posted by Branko Čibej <br...@xbc.nu>.
On 28.07.2010 21:55, Daniel Shahaf wrote:
> Stefan Sperling wrote on Wed, Jul 28, 2010 at 16:05:49 +0200:
>
>> But there's no harm in making svn patch interpret existing move information
>> in git diffs. We can carry out a corresponding copy + delete.
>> We won't be generating move git diff headers ourselves, but we should
>> be interoperable with git diff and hg diff as much as we can.
>>
> hg diff? I don't recall hearing of 'hg diff' on this list before... are we
> trying to be able to parse 'hg diff' output as well? Or how does 'hg diff'
> come into the picture?
>
IIRC Mercurial uses git-compatible diff format these days.
-- Brane
Re: GSoC Progress report
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jul 28, 2010 at 10:55:39PM +0300, Daniel Shahaf wrote:
> Stefan Sperling wrote on Wed, Jul 28, 2010 at 16:05:49 +0200:
> > But there's no harm in making svn patch interpret existing move information
> > in git diffs. We can carry out a corresponding copy + delete.
> > We won't be generating move git diff headers ourselves, but we should
> > be interoperable with git diff and hg diff as much as we can.
>
> hg diff? I don't recall hearing of 'hg diff' on this list before... are we
> trying to be able to parse 'hg diff' output as well? Or how does 'hg diff'
> come into the picture?
hg can produce the same unidiff format extensions as git diff:
$ hg rename alpha alpha-renamed
$ hg diff -g
diff --git a/alpha b/alpha-renamed
rename from alpha
rename to alpha-renamed
$
So with us adopting the format as well, it becomes more and more of
a de-facto standard for expressing tree changes in unidiff.
Stefan
Re: GSoC Progress report
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Wed, Jul 28, 2010 at 16:05:49 +0200:
> But there's no harm in making svn patch interpret existing move information
> in git diffs. We can carry out a corresponding copy + delete.
> We won't be generating move git diff headers ourselves, but we should
> be interoperable with git diff and hg diff as much as we can.
hg diff? I don't recall hearing of 'hg diff' on this list before... are we
trying to be able to parse 'hg diff' output as well? Or how does 'hg diff'
come into the picture?
Thanks,
Daniel
Re: GSoC Progress report
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jul 28, 2010 at 12:06:11PM +0200, Daniel Näslund wrote:
> Hi!
>
> Property diffs
> ===============
> * We can create parseable prop patches
> * We can parse property patches
> * We can match property patches
> * We can write patched properties to tmp files
> * We can install those prop changes to files and dirs (not the wc-root dir yet)
This is very nice! Great work.
> Todo
> ------
> * Decide on how we want notification for property patches.
> * Decide on how to handle SVN_ERR_ILLEGAL_TARGET (i.e. returned from
> svn_wc_prop_set() when trying to set svn:executable on a dir or
> svn:ignore on a file.
> * Decide on how to handle SVN_ERR_BAD_MIMETYPE (if svn:mime-type is not
> valid).
> * Allow wc-root dirs to be patched for props
> * Fix a bug in how 'svn diff' displays context lines for overlapping
> hunks when dealing with property diffs. (diff_test 54)
> * Make 'svn patch' notify if a property to be modified does not exist.
> * Make 'svn patch' notify if a property to be deleted does not exist.
> * Tests with different eol.
> * Tests with many different kinds of props on a target (add/del/mod).
> * Decide on how to handle binary props.
This list is ordered nicely from top to bottom. The binary props part is
not that important to me. I think we can punt on that for now, until
everything else works fine.
> Git diff format
> ==================
> * We can create add/del/mod/copy patches for WC-WC diffs (if using
> --git-diff flag and --show-copies-as-adds for copies)
> * We can create add/del/mod patches for URL->WC and URL->URL diffs
> * We can parse git diffs.
Nice.
> Todo
> -------
> * Remove the --git-diff flag and make the git diff format standard. The
+1
> flag was introduced to avoid excessive use of #ifdefs and since I
> wrongly interpreted the git unidiff format to not include hunks for
> deleted paths. If someone has objections to use the git diff format as
> standard, do speak up!
I'd really prefer not to bother our users with useless command line
flags. The extra information in the diff output is just noise for
standard patch tools. Remember that we've also totally changed the
way svn diff prints property changes. Changing svn diff output is OK.
> * Record copyfrom for URL->WC
> * Record copyfrom for URL->URL
> * Rearrange a bit in the patch code to allow us to keep the current
> behaviour for unidiff where we delete files where all lines are
> deleted and add files that did not previously exist. But we should
> also be able to handle explicit add/del/copy/move operations that were
> recorded from a git unidiff patch.
Yes.
> * base85 encode binary content
Again, last item :)
> Note that we won't be able to track moves unless we start matching
> copyfrom with deleted paths and that may get a bit involved. We might
> just seattle for tracking copies at the moment.
Well... we can worry about generating move information in svn diff once
svn actually supports them in a reasonable manner.
But there's no harm in making svn patch interpret existing move information
in git diffs. We can carry out a corresponding copy + delete.
We won't be generating move git diff headers ourselves, but we should
be interoperable with git diff and hg diff as much as we can.
Nice progress!
Stefan
Re: GSoC Progress report
Posted by Stefan Sperling <st...@elego.de>.
On Wed, Jul 28, 2010 at 12:06:11PM +0200, Daniel Näslund wrote:
> Hi!
>
> Property diffs
> ===============
> * We can create parseable prop patches
> * We can parse property patches
> * We can match property patches
> * We can write patched properties to tmp files
> * We can install those prop changes to files and dirs (not the wc-root dir yet)
This is very nice! Great work.
> Todo
> ------
> * Decide on how we want notification for property patches.
> * Decide on how to handle SVN_ERR_ILLEGAL_TARGET (i.e. returned from
> svn_wc_prop_set() when trying to set svn:executable on a dir or
> svn:ignore on a file.
> * Decide on how to handle SVN_ERR_BAD_MIMETYPE (if svn:mime-type is not
> valid).
> * Allow wc-root dirs to be patched for props
> * Fix a bug in how 'svn diff' displays context lines for overlapping
> hunks when dealing with property diffs. (diff_test 54)
> * Make 'svn patch' notify if a property to be modified does not exist.
> * Make 'svn patch' notify if a property to be deleted does not exist.
> * Tests with different eol.
> * Tests with many different kinds of props on a target (add/del/mod).
> * Decide on how to handle binary props.
This list is ordered nicely from top to bottom. The binary props part is
not that important to me. I think we can punt on that for now, until
everything else works fine.
> Git diff format
> ==================
> * We can create add/del/mod/copy patches for WC-WC diffs (if using
> --git-diff flag and --show-copies-as-adds for copies)
> * We can create add/del/mod patches for URL->WC and URL->URL diffs
> * We can parse git diffs.
Nice.
> Todo
> -------
> * Remove the --git-diff flag and make the git diff format standard. The
+1
> flag was introduced to avoid excessive use of #ifdefs and since I
> wrongly interpreted the git unidiff format to not include hunks for
> deleted paths. If someone has objections to use the git diff format as
> standard, do speak up!
I'd really prefer not to bother our users with useless command line
flags. The extra information in the diff output is just noise for
standard patch tools. Remember that we've also totally changed the
way svn diff prints property changes. Changing svn diff output is OK.
> * Record copyfrom for URL->WC
> * Record copyfrom for URL->URL
> * Rearrange a bit in the patch code to allow us to keep the current
> behaviour for unidiff where we delete files where all lines are
> deleted and add files that did not previously exist. But we should
> also be able to handle explicit add/del/copy/move operations that were
> recorded from a git unidiff patch.
Yes.
> * base85 encode binary content
Again, last item :)
> Note that we won't be able to track moves unless we start matching
> copyfrom with deleted paths and that may get a bit involved. We might
> just seattle for tracking copies at the moment.
Well... we can worry about generating move information in svn diff once
svn actually supports them in a reasonable manner.
But there's no harm in making svn patch interpret existing move information
in git diffs. We can carry out a corresponding copy + delete.
We won't be generating move git diff headers ourselves, but we should
be interoperable with git diff and hg diff as much as we can.
Nice progress!
Stefan