I just found some design docs on an enhanced svn patch format, which,
I would assume, would fix the above issue.
https://svn.collab.net/viewvc/svn/trunk/notes/svnpatch?revision=36404&view=markup
I'm not sure when or if this code is scheduled to go into a release,
but it was merged from a branch to the trunk recently, so looks good.
On Wed, Apr 22, 2009 at 9:21 AM, Craig <supkichen_at_gmail.com> wrote:
> thanks all...so I wasn't going crazy.
>
> On Wed, Apr 22, 2009 at 1:43 AM, Stefan Sperling <stsp_at_elego.de> wrote:
>> There is a bunch of issues for this, too. One of them is
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2543
>
> thanks for that link. I think I finally understand what is going on.
> From the linked bug:
>
> "Also, there is no way to record the ancestry with traditional patch,
> thus there's no way to actually generate a 'correct' patch in this
> case." and "The result from a patch which includes the add is *not*
> the correct result, since the fact that the add stems from a rename is
> lost (i.e. the fact that the original add was *with history*)."
>
> So it seems there is currently no way to do this correctly, so it
> isn't done at all. That certainly seems like a bug or at least a
> serious limitation to me.
>
> Moving on, how does one work around this? I know the subersion project
> itself depends a lot on submitted patches. Surely these run into the
> same problems on occasion?
>
> regards,
> Craig
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1956789
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-28 04:54:49 CEST