>
>
> > 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.)
>
>
> Thanks for the ideas. I really appreciate it. I don't think the decision
makers in this case have ever seen a distributed versioning system with a
web front end or an integrated tool like Trac, so they aren't capable of
thinking outside of their text based frame of reference.
Unfortunately after a teleconference yesterday the program management made
it clear that they aren't interested in hearing the benefits of any new
approaches. The corporate 'approved' versioning system is a monolithic app
which is based on the old checkout-lock-checkin paradigm, and does the $log$
thing. So we're going to have to bend SVN to support that notion or just
drop it altogether.
>
> ---------------------------------------------------------------------
> 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-17 15:47:29 CEST