I'm afraid this was my bad -- I blindly applied the patch and svn
deleted the 0 byte files and failed to manually do the svn move
instead.
I believe the trunk version of svn includes an "svn patch" command
(that is sorely needed). It'd fix this as well as eg forgetting to
svn add new files in a patch, failing to carry over changes to svn
props, etc.
Mike
On Tue, Jun 16, 2009 at 4:11 AM, Uwe Schindler<u...@thetaphi.de> wrote:
> The problem is, when you applied the patch, the files are already
> deleted/created by "patch2 and the SVN client is loosing the move operation
> (he only sees a new unversioned file and one missing file). As your link
> notes, you cannot replay the changes already done (by the patch command). So
> the committer must do the rename back and then do it using the svn command
> again. On Windows with TortoiseSVN, this is simple, but it goes onto your
> nerves.
>
> I think there is a patch for SVN available that extends the patch generation
> by adding not only properties (which are not applied on patching with the
> native "patch" command, too). I think the current version of "svn diff" adds
> this file changes (it creates patch files containing the old and new
> filename in the diff), but there is no command to apply it ("svn patch" or
> something like that, that is a svn replacement for native "patch").
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -----Original Message-----
>> From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
>> Sent: Tuesday, June 16, 2009 10:00 AM
>> To: java-dev@lucene.apache.org
>> Subject: Re: losing history
>>
>> Uwe is right! As long as you us diffs (patches) and have any kind of
>> svn cp / svn mv done to you repository the will not be
>> reflected in the diff. I don't think that there is any way of doing
>> this currently except of the committer is doing it by hand (again)
>> when applying the patch.
>> This is related: http://subversion.tigris.org/faq.html#wc-change-detection
>>
>> simon
>>
>> On Tue, Jun 16, 2009 at 8:05 AM, Uwe Schindler<u...@thetaphi.de> wrote:
>> > I think the problem here is that the file was not renamed in SVN. As
>> patches
>> > in JIRA normally do not contain the rename (because they cannot applied
>> with
>> > all actions like renames automatically done), I think the rename got
>> lost.
>> > Renames only work correct, if the person who did the rename in his local
>> > repository also commits the change.
>> >
>> > If you want to see the old directory names, go into web SVN view and
>> show
>> > the directory log of the directory where the file was in. Or just
>> specify
>> > the revision number and start browsing in this old version.
>> >
>> > Normally SVN renames should work like this: see commit 784981
>> > Here you can see the history is preserved, but only because I did the
>> > move/rename locally and committed from my own computer. To view the full
>> > history do not specify "stop on copy/rename".
>> >
>> > -----
>> > Uwe Schindler
>> > H.-H.-Meier-Allee 63, D-28213 Bremen
>> > http://www.thetaphi.de
>> > eMail: u...@thetaphi.de
>> >
>> >> -----Original Message-----
>> >> From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik
>> >> Seeley
>> >> Sent: Tuesday, June 16, 2009 2:24 AM
>> >> To: java-dev@lucene.apache.org
>> >> Subject: losing history
>> >>
>> >> I thought SVN's rename was supposed to preserve history?
>> >> I just wanted to look up the history of MultiTermEnum, and when I went
>> >> to the file (now in DirectoryReader renamed from MultiSegmentReader)
>> >> but all the history is gone before the last rename. IntelliJ and "svn
>> >> log" both showed only 3 versions.
>> >>
>> >> Could I at least get it by specifying the old name from the command
>> >> line? guess not...
>> >> $ svn log ./src/java/org/apache/lucene/index/MultiSegmentReader.java
>> >> svn: 'src/java/org/apache/lucene/index/MultiSegmentReader.java' is not
>> >> under version control
>> >>
>> >>
>> >> tips?
>> >>
>> >> -Yonik
>> >> http://www.lucidimagination.com
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: java-dev-h...@lucene.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
