On Sat, 23 Aug 2003 08:46:49 -0700 (PDT), "Kumaran Santhanam"
<kumaran@tigris.org> said:
> > IIRC, the conclusion was that it would cause more potential grief than
> > it would save.
> >
> > Here's an alternative: svn commit --targets <file>
> >
> > You can build a wrapper around svn commit that runs "svn status",
> > builds you a file list, calls $EDITOR, lets you edit the list, and
> > then pulls the list back out and calls svn commit --targets.
>
> Thanks for the info.
>
> While I agree on the use of wrapper scripts in the short-term, I
> feel that it's more elegant long-term to integrate useful
> features into the SVN client. My reasoning is as follows (this
> also goes for the last discussion about external diff programs).
I understand your point, and you set me to thinking. The commit list
idea was good enough for me, so, I wrote such a script. I sent it to the
users list, and the posting is at
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=938.
>
> As open-source people, we are all used to hacking on our various
> boxen. As such, we are not averse to using external scripts,
> aliases, environment variables and the like. A few SH and Perl
> scripts don't cause us any concern, and we often write many of
> those per week just in the course of our normal work.
I agree with you completely. I do not write as many scripts in the
course of my work, but I sometimes write one or two.
>
> In the corporate developer world, the picture is much different.
> Many of these folks are running certain non-POSIX operating
> systems, and it is uncomfortable for them to deal with external
> scripts and wrappers. In fact, they may not even have capable
> script interpreters available on their machines. Of course, I
> could create a binary that would replace their SVN and pass
> through commands, but that's very little difference from updating
> SVN itself.
>
> The features I propose are intended to be very minor code changes
> that can make a big difference to the user experience. The
> easier SVN is to setup and use, the more acceptance it will gain.
> Average users are generally resistant to creating custom wrappers
> for their favorite tools or functionality. The fewer times they
> have to ask "Why can't I do ... ?", the better their perceived
> experience will be.
I consider myself an experienced user, but not a C/C++ developer (altough
I develop using Java). I have installed and setup Subversion using
Apache not once, but three times. Each time, I did not have any
problems. The documentation is excellent and the book contains a
treasure throve of information. The lists are helpful and the developers
really take the time to listen to their users.
But as the SVN developers have said before, if they agree to every "Why
can't I do X ?", the software will be so bloated as to be almost
unusable. The first feature that comes to mind is the repository
browsing. Almost everyone, myself included, would like mod_dav_svn to
allow browsing the history and properties of each files. But, the
developers have consistently refused to do so. I understand their
concerns completely, even though this would be a useful feature.
This is the open-source world. Someone will write a script that does
what is wanted (like I did for the commit list feature), and then the
script is picked up and updated by someone else. In the end, the script
implements feature X, but also feature Y and Z. Why do you think that
the corporate world fears change ? Every time a user comes with a "Why
can't I do X", the feature list changes, and development grinds to a halt
because of feature X.
>
> I'd love to hear what others on the list think.
Have a nice day !
François Beausoleil
Developer of Java Gui Builder
http://jgb.sourceforge.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 23 18:13:50 2003