[ 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
