Re: svn diff - revert - patch does not restore wc state
On Mon, 9/10/18, Julian Foad wrote: Subject: Re: svn diff - revert - patch does not restore wc state To: users@subversion.apache.org Date: Monday, September 10, 2018, 3:49 PM Timur Khanipov wrote: > [...] I hope the > 'shelve/unshelve' commands will eventually mature and be able to handle the > situation I described. I also think that these command should finally learn > to save modifications to a separate wc-independent file [...] Hello. I am actively working on the Shelve feature (thanks to Assembla for funding this development) and I agree with both of your points. We are planning to release Subversion 1.11 in October with improvements to Shelving, although still not supporting copies and moves. After that I will be improving it further. If you will consider participating in some way, you might like to start by reading the Wiki pages (starting at https://cwiki.apache.org/confluence/display/SVN/Shelving+and+Checkpointing+Dev ) and the development mailing list (see http://subversion.apache.org/mailing-lists.html ). - Julian == Since you're on the topic of shelve and not restoring everything, I noticed something that looks like a minor bug. I shelved a bunch of files and noticed that some of those files were still marked as modified and when I did diff on them I got something like this: ---somefile.txt(rev 123456) +++somefile.txt (working copy) -sometext \ No newline at end of file +sometext That is, when I shelved, it seems to have added (or at least not reverted) a newline at the end of the file. Not a big problem, but shelve should probably not act this way. BR, Chris
Re: Erroneous "diff --summarize" output?
Hi Johan, I'll file a bug report then! BR, Chris On Wed, 9/5/18, Johan Corveleyn wrote: Subject: Re: Erroneous "diff --summarize" output? To: "Chris" Cc: "Subversion" Date: Wednesday, September 5, 2018, 3:51 PM On Wed, Aug 8, 2018 at 9:27 AM Chris wrote: > > I just noticed some strange output from diff --summarize that to me looks like a bug, but I'm not sure. > What I'm doing is that I'm changing a file in a subdirectory, committing it and then reverse-merging that change so I'm back to the same content of my working copy as before. Running svn diff against the previous revision shows no diffs as expected, but when I do the exact same command but add --summarize, it says the file that I changed is modified and the directory it is in has property changes. > The attached reproduction script illustrates the difference. Is this a bug or am I misunderstanding how summarize is supposed to work? Hi Chris, Thanks for reporting this. I think this is indeed a bug ... somehow the 'diff --summarize' seems to do something wrong when determining the working-copy revision (but regular 'diff' does it right). That's if I'm correctly interpreting the second usage of 'diff'. From 'svn help diff': [[[ 2. diff [-c M | -r N[:M]] [TARGET[@REV]...] ... 2. Display the changes made to TARGETs as they are seen in REV between two revisions. TARGETs may be all working copy paths or all URLs. If TARGETs are working copy paths, N defaults to BASE and M to the working copy; if URLs, N must be specified and M defaults to HEAD. The '-c M' option is equivalent to '-r N:M' where N = M-1. Using '-c -M' does the reverse: '-r M:N' where N = M-1. ]]] So, "If TARGETs are working copy paths, N defaults to BASE and M to the working copy". But, if I'm following your test script, at the end the working copy is at revision 3. And if not, it certainly is after I execute another 'svn update' at the working copy root. If I do: svn diff -r 1 A indeed, it shows nothing. If I do: svn diff -r 1 --summarize A it shows: M A\mu M A But if I do: svn diff -r 1:3 --summarize A it shows nothing. So it seems, with the --summarize option, 'diff' doesn't seem to determine correctly the "M" revision of the range (should be "3" in this case, the working revision of the working copy). This issue seems a bit similar: https://issues.apache.org/jira/browse/SVN-4631 (svn --xml --summarize -rBASE:n reports incorrect output) But I'm not sure whether it's the same. I think you should file a new issue, and attach your reproduction script to it. -- Johan
Re: svn diff - revert - patch does not restore wc state
Chris wrote: > I shelved a bunch of > files and noticed that some of those files were still marked as > modified and when I did diff on them I got something like this: > >---somefile.txt(rev 123456) >+++somefile.txt (working copy) >-sometext >\ No newline at end of file >+sometext Assuming you saw that with v1.10, that's another deficiency of building shelving on top of diff and patch. For the version coming in 1.11 I've completely changed the implementation (it doesn't use diff/patch any more) and I'm pretty sure bugs of that kind are gone. Please let me know if you see anything like that when you first get a chance to try a recent trunk build or 1.11. Thanks. - Julian
Speakers needed for Apache DC Roadshow
We need your help to make the Apache Washington DC Roadshow on Dec 4th a success. What do we need most? Speakers! We're bringing a unique DC flavor to this event by mixing Open Source Software with talks about Apache projects as well as OSS CyberSecurity, OSS in Government and and OSS Career advice. Please take a look at: http://www.apachecon.com/usroadshow18/ (Note: You are receiving this message because you are subscribed to one or more mailing lists at The Apache Software Foundation.) Rich, for the ApacheCon Planners -- rbo...@apache.org http://apachecon.com @ApacheCon
