Issue 777 resolved? ("'svn log' bombs out if any arg is unversioned")

I have been looking for open issues that are easy to close.

Issue 777 says "'svn log' bombs out if any arg is unversioned". The original problem was that it bombed out SILENTLY, but that has been resolved - it throws an error. The issue is still open, with the observation that it would be nice if it got logs for all the versioned arguments. While that might be nice, there is little point in changing it without also bringing into line the other subcommands which have similar behaviour.

1. I would suggest either the issue be closed as "resolved", or expanded in scope to "subcommands need to treat unversioned-file arguments in a consistent manner". Would you like me to do one of these?

2. (The subject of the rest of this message.) Any opinions on what the most appropriate behaviour is and whether the same behaviour can be appropriate for all or most subcommands?

It may get a little complicated - there are lots of variations like file doesn't exist in WC, doesn't exist in repository, doesn't exist in the specified revision but does in HEAD, etc. Nevertheless it is probably easy to generalise, saying something like "every subcommand shall process each valid argument and give a warning for each invalid argument".

At the bottom there is a summary of the present behaviour of many subcommands.

I would say that processing only some of the valid files (e.g. those before an uncontrolled file but not those after it) is bad behaviour: it can be hard to recover from that. The two sensible options seem to be:

  (a) Process each valid file and give a warning for each invalid file.

  (b) If any file is invalid, abort with an error (that mentions at least one of the invalid files) without processing any files.

Option (a) is probably easy to impliment once we agree an appropriate form of notification. Option (b) is surely the cleanest and best way, but requires checking every argument before starting, which may be inefficient or something.

Note that while "svn commit" is atomic, this only means that it has to commit all or none of the valid files; it could be made to commit all valid files but reject invalid ones. That's probably not acceptably safe - but it's a possibility.

The idea was mentioned in issue 777 of each API function returning a list of the arguments that it failed to operate on. That sounds nasty to me, although in the abstract sense it is equivalent to printing a warning for each failure. Hmmm.

Of course it is not essential to have this cleaned up for release 1.0, but ... well ... you know, it's sub-optimal, as someone used to say a lot.

What I would want to do for a start is to get all the error and warning messages consistent, and make each subcommand process either all valid files or no valid files (whichever seems easier for that particular subcommand). Any strong views (apart from "Work on one of the really important but difficult bugs instead!")?

- Julian

Here is a summary of the present behaviour of several subcommands. "A" and "Z" are controlled files; "U" is an uncontrolled file.

Summary: Processes: Error/warning:
svn cat A U Z A - - 'U' has no URL
svn commit A U Z - - - Can't find an entry [...] /home/[...]/U
svn delete A U Z A - - 'U' is not under revision control
svn diff A U Z A - - 'U' is not a versioned resource
svn info A U Z A - Z U: (Not a versioned resource)
svn list A U Z A - - 'U' has no URL
svn log A U Z - - - 'U' is not under revision control
svn proplist A U Z A - Z warning: 'U' -- not a versioned resource
svn propset ... A U Z A - - 'U' -- not a versioned resource
svn resolved A U Z A - Z warning: Not under version control: 'U'
svn revert A U Z A - - warning: 'U' is not a versioned resource
svn update A U Z A - Z warning: 'U' is not a versioned resource

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 31 23:54:02 2003