> > - A general attitude of "if you can just grep log results on the
> > client then the server doesn't need feature X" - that's great if (a)
> > you want every client to have to produce their own, sometimes complex,
> > grep commands and (b) you have a very fast connection (some of us are
> > in a different country from the server and not on a particularly quick
> > connection).
>
> I do not believe that there is any such attitude. If it has been
> suggested to you before to use the log where you might prefer to use
> a property, then this is because the log solution has worked for many
> people before. For example for storing the bug ID that the revision
> fixes. However, if you prefer a property, nothing prevents you from
> using one. I believe TortoiseSVN even includes a field for that,
> which integrates with Bugzilla. It could probably be made to
> integrate with other bug trackers as well.
>
> The attitudes that do exist, and which are perfectly reasonable and
> to be expected are:
>
> - Requests for which workarounds already exist are less important
> than requests which are actual crashing bugs or new features that
> have been oft requested and which are difficult or impossible to work
> around.
> - Developer time is limited.
> - It must be completely agreed what a feature should do before it can
> be implemented. This means there must be a discussion and ultimately
> a design document specifying how the feature is to behave in every
> instance. Many requests that come up time and time again on the list
> have never reached an agreement as to what exactly they are supposed
> to do, and have therefore failed to be implemented.
I have to disagree. Several responses to such requests have followed
the lines of "No, we don't need a feature request, this is already
supported by grepping the log or checking out the whole repository" -
consider such discussions as searching for files or file content in
the repository or finding out where files have been copied or moved
to.
It's absolutely reasonable to state that, when no such feature is
available or proposed, a fully formed proposal be submitted as an
enhancement request.
Of course what people making such proposals then need to accept is
exactly as you've stated. Time is limited and critical faults and
features in high demand need to be serviced first.
--
Talden
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 18 22:46:48 2007