> -----Original Message-----
> From: Andy Levy [mailto:andy.levy_at_gmail.com]
> Sent: Tuesday, September 16, 2008 3:33 PM
> To: Ryan Schmidt
> Cc: Robert P. J. Day; users_at_subversion.tigris.org
> Subject: Re: help me show others that there are valid reasons for not
> supporting a $log$ keyword!
>
> On Tue, Sep 16, 2008 at 15:29, Ryan Schmidt
> <subversion-2008c_at_ryandesign.com> wrote:
> > On Sep 16, 2008, at 11:04 AM, Robert P. J. Day wrote:
> >
> I suspect, from what the OP has written, that his management will opt
> for the former if you give them any possible opening to squeeze
> through.
>
Too true.
Simply state that implementing $log$ "can't be done" (it's not
practical.) "It cannot be done, so we either have to do without, or we
can use the following alternatives..."
Give them an alternative. One reason for putting $log$ into files is
because in a lot of systems, it's a pain to get the information from the
tool. However, Subversion makes it really easy to get meta-information.
For example: you can use the $URL$ keyword (which puts
"svn://server/repos/a/b/c/foo.java" into your file) and then simply run
"svn log svn://server/repos/a/b/c/foo.java" from the command line, via a
web browser (tortoise has a browser plugin, just type in the
svn://repos/some/foo.java and away you go,) or in a spiffy GUI like
TortoiseSVN to get the log history. This also has the advantage of
being up to date (log messages can be changed,) you can do diffs, run
annotate, etc.. _Everyone_ understands how web URLs work. $URL$ is a
web URL. Typing "svn log some_url" shouldn't be difficult.
People put $log$ in the file because of convenience. Show them that SVN
is convenient, but more so. Demo'ing the 'svn log/diff/annotate URL'
feature before a live audience (especially if you use a GUI) should go a
long way to winning over people.
Now if your customers cannot reach the subversion server, then modify
your export script/build package to run 'svn log' for each file and save
it as "foo.java.log". They get the log history. It's easy to
understand that foo.java.log is the log history for foo.java. If they
still complain about such a "simple and effective solution," then ask
them to explain what the problem is (being too lazy to open a 2nd file
isn't going to fly.) Worst case would be that they have some automated
process which is parsing $log$, although data-mining $log$ would seem to
be of dubious value.
You could have the build/export prepend the 'svn log' to each file,
however, eventually Someone(tm) _will_ cause havoc by checking in a file
with the log information, so don't do it. (Breaks diffs, breaks merges,
the log info is out of date immediately, the next export will add a 2nd
log history, etc.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-16 23:20:34 CEST