>>> I just found out I am waisting my time to track exactly what got
>>> updated on `svn up`...
>>>
>>> Will it be easy to implement a bit more info on the update MSG,
>>> like:
>>> Updated _from_revision_XYZ_ to revision ABC.
>>> instead of the current:
>>> Updated to revision ABC.
>>
>> My hunch is that it won't be _fast_, for the same reason that causes
>> "svnversion" to take a long time to run.
>
> Ou! Didn't even know that such a command exists!
> Checked now all "commands", that was the last to learn :-)
> Tried it now and yes, it does its thing, but veery slow on a big
> checkout dir.
>
>>> In this way it will be easy to see how much log entries have to
>>> be read since last update.
>>> Include that for "Updated external to revision CFD." as well.
>>>
>>> What I am doing now is:
>>> svn info <= see current revision
>>> svn up
>>> svn log -r $currev:HEAD
Not every file in a working copy is always (or even usually) at the
same revision. svn info only tells you the revision of the directory
in (or on) which you execute it, not any of its subdirectories, not
any of its files. To learn about the range of revisions throughout
your working copy, you need svnversion. To accurately handle mixed
revisions (which happens almost all the time, so it's not an edge
case you can just ignore), the svn update command would have to print
the current revision of each item on the update line.
$ svn update
U foo.c (was at revision 12)
U bar.c (was at revision 21)
Updated to revision 23.
That's clearly too verbose, but probably any change to show this sort
of information (even just adding a column with the item's former
revision) would be too verbose.
What would you do with the information anyway? Would you go and look
at the log of foo.c from 12 to 23, and then look at the log of bar.c
from 21 to 23? What if there weren't 2 files but 200? Would you
really scroll back through svn update's status messages, and type 200
svn log commands?
Maybe it would suffice if you just saw the output of a single svn log
command, from revision {earliest revision of any file in this working
copy} to HEAD. If so, then the (first) value output by svnversion is
probably that number. Note that this could still show you log
messages you didn't want to see (e.g., in the example above, if bar.c
was previously updated in revision 15, you'd also see the log message
about that, even though your bar.c had already included that change).
But if that's ok, then there you are.
> Are there client-side hooks like the server-side?
> Didn't find any in .subversion/config :-(
>
> Google found: http://www.onlamp.com/pub/a/onlamp/2005/01/06/
> svn_homedir.html
> "because there is no way to add a client-side hook in Subversion,
> or CVS for that matter."
You answered your own question.
> If there are, I'd just put a wrapper pre-commit that runs this:
> export P=`svn info |perl -ne 'next unless (/^Revision: (\d+)$/);
> print "$1\n"'`
> and post-commit:
> svn log -r $P:HEAD
>
> Anybody ever considering cliend-side hooks? (for the stadard CLI
> only)?
Many times, as you'll see in the archives. It's not been done so far
because it's not trivial and I don't think the developers are
convinced of its utility, because there's nothing preventing you from
writing a wrapper around the svn command-line client to do what you
want, which should have exactly the same effect.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Sep 14 23:16:45 2005