On Wed, 2 Jul 2025 at 16:31, Johan Corveleyn <jcor...@gmail.com> wrote: > > [ Rearranged into bottom-posting, which is the habit on this list; > please continue with bottom or inline replying ... more below ] > > > > >> Ondra Medek wrote: > > > >> > > > >> >Hello, > > > >> > > > > >> >I have an existing file `exist.txt`, nonexistent file `noexist.txt` > > > >> >and a file which has been deleted `deteted.txt`. I have a SVN working > > > >> >copy which is at a revision with `deteted.txt` still existing, > > > >> >however, someone else has deleted it in the repository already. I.e. > > > >> > > > > >> >$ ls . > > > >> >deteted.txt exist.txt > > > >> > > > > >> >When I do svn info -r HEAD to get remote revision of these files, the > > > >> >deleted file breaks the output: > > > >> > > > > >> >$ svn info --show-item last-changed-revision -r HEAD deteted.txt > > > >> >exist.txt > > > >> >svn: E160013: File not found: revision 10, path '/deteted.txt' > > > >> > > > > >> >No result, just error. When I change the param order, I have the > > > >> >result for the existing file: > > > >> > > > > >> >$ svn info --show-item last-changed-revision -r HEAD exist.txt > > > >> >deteted.txt > > > >> >1 exist.txtsvn: E160013: File not found: revision 10, path > > > >> >'/deteted.txt' > > > >> > > > > >> >However, when I do the same with nonexistent file, I have the output > > > >> >for the existing file always regardless of the param order: > > > >> > > > > >> >$ svn info --show-item last-changed-revision -r HEAD noexist.txt > > > >> >exist.txt > > > >> > > > > >> >svn: warning: W155010: The node '...\noexist.txt' was not found. > > > >> > > > > >> >1 exist.txt > > > >> >svn: E200009: Could not display info for all targets because some > > > >> >targets don't exist > > > >> > > > > >> > > > > >> >I would welcome `svn info -r HEAD` would behave for the deleted files > > > >> >the same way as for nonexistent ones. > > > >> > > > > >> >Thanks > > > >> >Andy > > > > >On Mon, 16 Jun 2025 at 12:43, Lorenz via users > > > ><users@subversion.apache.org> wrote: > > > >> > > > >> Hi, > > > >> > > > >> think about it: how would subversion reference a file that no longer > > > >> exists in the repositiory? > > > >> > > > >> Anyways, have a look at > > > >> https://svnbook.red-bean.com/en/1.6/svn.advanced.pegrevs.html > > > >> > > > >> Lorenz > > > >> -- > > > >> > > > > Ondra Medek wrote: > > > >Hello Lorenz, > > > > > > > >`svn info` should handle deleted files the same way as nonexistent > > > >files, i.e. print a warning (to stderr) and continue processing the > > > >next file (param). So, for nonexistent files, the order of params does > > > >not matter, the stdout contains output for existing files and warnings > > > >are printed to stderr. See the beginning of my first post about > > > >deleted files - when a deleted file is the last file param, then it > > > >works as expected, stdout contains output for all existing files. > > > >However, when the deleted file is the first file param, then the > > > >output (stdout) is empty - no other file param is processed. > > > > > > > >Note: the warning may be different for deleted and nonexistent files, > > > >it does not matter. Important for me is that `svn info` would process > > > >all file params even after it hits a deleted file. > > > > > > > >Andy > > > > > > > On Tue, 17 Jun 2025 at 13:34, Lorenz via users > > <users@subversion.apache.org> wrote: > > > > > > Hi, > > > > > > the non-exiting file case is handled by the client. > > > It generates a warning that the file does not exist in the local > > > database and/or in the file system. > > > I would assume there are different messages for the two cases. > > > > > > in the deleted file case the wrror is generated by the server. > > > The files exists in the local database and filesystem, but not on the > > > server in the head-revision. > > > > > > I am undecided if the client should proceed in case of an server > > > error. > > > > > > Lorenz > > > -- > > > > > On Tue, Jun 17, 2025 at 4:35 PM Ondra Medek <xmed...@gmail.com> wrote: > > > > IMO it's necessary to distinguish server errors: > > - "data errors" like files have been deleted. Then issue a warning and > > continue processing. > > - and other errors (e.g. internal server error etc.) where processing may > > stop. > > > > Andy > > Sorry for the late reply. I agree that the behaviour could be improved here. > > From a usability and consistency point of view (making abstraction of > how it all works, and whether errors happen clientside or serverside), > I agree processing of further arguments shouldn't stop because of a > "E160013: File not found: revision 10, path '/deteted.txt'", just like > it doesn't stop on "W155010: The node '...\noexist.txt' was not > found." > > I'm not sure whether processing should stop in case of non-data errors > (connections probs, internal server error, ...). I think the simplest > behaviour would be to continue processing all arguments anyway (too > bad if all 1000 args fail with the same "cannot connect" error). > Anyway, not so sure about that. > > In any case, I believe a report in our issue tracker would be useful. > @Andy: could you file an issue please? If you need to request Jira > account creation, do mention this discussion on users@ in your > request, and include a link to it in the actual issue (preferably a > link to the relevant thread on > https://lists.apache.org/list.html?users@subversion.apache.org) > > Thanks, > -- > Johan
Thanks for the reply. I've created Jira bug https://issues.apache.org/jira/browse/SVN-4920 --- Andy
