Ryan Schmidt wrote:
>>>> 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?
... OK up to here, but what I needed is what you said below:
> 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.
Well, I am in the habbit of trying not to work with mixed revision directories (apart from $HOME
itself which has lots of svn:externals => mixed). Generally commiting per low-level directory (to
keep patches small).
>> 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.
Yes, but when you work on 6+ machines and 2 OSes it is PITA trying to deploy such a solution...
And just a wild idea on how to implement what I need:
Add a <entry last-rev="XYZ" commited-rev="ABC" ... /> in .svn/entries
Update that on update (this file is updated anyway, so performance will not be that bad).
This way you can run `svn info` after the update, in case you forgot before!
Assuming thre are no mised revisions, use the top directory to get the log.
Hope this will be OK, as we are using XML.
Do you think adding such a feature can break things?
Will I get the time to implement that? Not very probabble :-|
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Sep 15 02:06:48 2005