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

[Julian Foad <ju...@btopenworld.com>]

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

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

[Julian Foad <ju...@btopenworld.com>]

kfogel@collab.net wrote:
> Julian Foad <ju...@btopenworld.com> writes:
> 
>>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

> IMHO, issue #777 should be resolved.  Optionally, a new Post-1.0 issue

OK, I've closed it as "fixed".

> could be opened about log proceeding in the presence of unversioned
> arguments, but as you point out, this is really a special case of a
> more general question.  But is that general question important enough

I have not opened a new issue about bringing all subcommands into line in this respect, but I might do some time.

- Julian


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

[kf...@collab.net]

Julian Foad <ju...@btopenworld.com> writes:
> I have been looking for open issues that are easy to close.

Have I kissed you yet today?

> 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?

IMHO, issue #777 should be resolved.  Optionally, a new Post-1.0 issue
could be opened about log proceeding in the presence of unversioned
arguments, but as you point out, this is really a special case of a
more general question.  But is that general question important enough
to be worth spending time on?  I don't think so; we have many more
important bugs than this.  No one's going to be prevented from getting
work done because an svn command didn't handle an unversioned target
gracefully.

Regarding open pre-1.0 issues -- if you see one that's assigned to
sussman, cmpilato, or kfogel, but it's not marked as 'STARTED', then
it's likely available if you want it.  Just post first to check.  Ben
can answer for me and Mike while we're on our respective vacations
:-).

Thanks for looking for issues!

-K

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org