[Mark Grosberg wrote:]
> Can we re-open the issue with voting? Perhaps the originator of the issue
> has some input?
Sorry, I don't follow this mailing list, so I wasn't aware of the
patch or discussion until Sander Roobol added a pointer to this to the
issue.
Anyway, my reaction is of course: great! Thanks Mark for doing this!
Now, to sway the others...
We're all clear on that this feature does provide something that's not
possible using other mechanisms - 'svn commit --targets' certainly
gets you mostly there. However, as has been pointed out, it's a
convenience feature. Why are there 3 ways to provide a log message
(-m, -F, and the editor) when -F would suffice? Presumably for the
same reason: each is a more convenient way to do things in different
cases. Now of course one doesn't want to go overboard, adding all
sorts of bells and whistles just because they might be convenient to
somebody. But as a long time CVS user, this was probably the most
strikingly useful feature I found when I started using perforce; and
it seems I'm not the only one. I found it extremely intuitive (though
they don't provide a nice message right in the editor saying that you
could actually edit the list) and ended up using it quite often
(granted, that was partly because of perforce's sucky command line
that doesn't allow you to specify a list of files). And while I
generally believe in the unix command-line philosophy of lots of
simple tools that you can hook together, this feature just feels
extremely natural - you're in the editor providing information for the
commit, so why can I only provide half (the log message) and not
everything (log message + file list)?
Also, I think Colin Watson gave a good example:
> There's another benefit to the Perforce approach for Subversion;
> it'll be an easy way around the problem of trying to commit a
> propchange to a directory when you've also changed some files in
> that directory. Instead of 'svn ci --depth 0' and suchlike (which
> with all due respect I think is a neat but horribly unintuitive idea
> - I wouldn't swear offhand to it being '--depth 0' rather than
> '--depth 1', for instance, which isn't a good sign), you could just
> 'svn ci' and delete all the file modifications from the list,
> leaving only the propchange. Dead easy, and you could teach it to a
> user in ten seconds just by demonstration.
The more straightforward the UI, the more folks will use it and like
it. In fact, the above example and the --depth stuff shows that even
the current tools aren't sufficient: because -F still walks the
directory if you list a directory in there (is this a bug?), there is
in fact no way (even with --depth?) to check in changes to just the
directory and selected (but not all) files underneath it.
For those worried about folks shooting themselves in the foot: how
about a config directive, not compile-time, but in .subversion/config
to enable or disable this feature (just the UI part, not the core)?
I'd prefer this to default to being on, and if you find that for some
reason too many folks do end up shooting themselves then you can
always change the default to off - but I doubt that'll be a problem.
Cheers,
Ronald
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri May 23 11:57:47 2003