You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Kalin KOZHUHAROV <ka...@thinrope.net> on 2005/09/14 06:49:29 UTC
[RFE] "Updated _from_revision_XYZ_ to revison ABC"
Hi there.
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.
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
And of course, sometimes I forget to run `svn info` before `svn up` and have to guess what was the
last revision.
Might need a bit of tweaking when there are mixed revisions, but then show the revision that you get
with `svn info` (without arguments that is on current directory).
What do you think?
Kalin.
P.S. Or is any other easy workaround for this? A shell/grep script might work for simple cases (no
externals)...
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [RFE] "Updated _from_revision_XYZ_ to revison ABC"
Posted by Eric Hanchrow <of...@blarg.net>.
Yes, but when you work on 6+ machines and 2 OSes it is PITA trying
to deploy such a solution...
Actually, it might not be so bad. Here's what I'd do:
* Write a wrapper around "svn" that does what you want. Use a modern
portable language such as Perl, Python, Ruby, etc.
* Check that wrapper in to subversion in a directory like
svn://server/users/kalin/local/bin
* Ensure that the 6+ machines all have a working copy of
svn://server/users/kalin/local/bin, and that it's on their PATH
(perhaps you should have them keep their home directories in
subversion too; see "svn_homedir" which you cited earlier)
* use your wrapper in preference to svn
And just a wild idea on how to implement what I need:
Add a <entry last-rev="XYZ" commited-rev="ABC" ... /> in .svn/entries
That might work, but it seems dangerous to much with subversion's own
internal data structures. I'd keep that information separate.
--
Humor can be dissected as a frog can, but the thing dies in the
process and the innards are discouraging to any but the pure
scientist.
--E.B. White
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [RFE] "Updated _from_revision_XYZ_ to revison ABC"
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 14, 2005, at 7:04 PM, Kalin KOZHUHAROV wrote:
>>
> 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 you aware that *every* time you run 'svn commit', you end up with
a mixed-revision working copy? You might want to read this new
section in the book:
http://svnbook.red-bean.com/nightly/en/svn.basic.in-
action.html#svn.basic.in-action.mixedrevs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [RFE] "Updated _from_revision_XYZ_ to revison ABC"
Posted by Kalin KOZHUHAROV <ka...@thinrope.net>.
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
Re: [RFE] "Updated _from_revision_XYZ_ to revison ABC"
Posted by Ryan Schmidt <su...@ryandesign.com>.
>>> 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
Re: [RFE] "Updated _from_revision_XYZ_ to revison ABC"
Posted by Kalin KOZHUHAROV <ka...@thinrope.net>.
* I always foget to CC the ML :-)
Eric Hanchrow wrote:
> What I am doing now is:
> svn info <= see current revision
> svn up
> svn log -r $currev:HEAD
>
> Me too.
>
> 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.
> What do you think?
>
> I predict the developers will say "write a wrapper script around svn
> that runs 'svnversion' before doing 'svn up'".
Well that will be an overkill I guess.
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."
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)?
Kalin.
--
|[ ~~~~~~~~~~~~~~~~~~~~~~ ]|
+-> http://ThinRope.net/ <-+
|[ ______________________ ]|
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: [RFE] "Updated _from_revision_XYZ_ to revison ABC"
Posted by Eric Hanchrow <of...@blarg.net>.
What I am doing now is:
svn info <= see current revision
svn up
svn log -r $currev:HEAD
Me too.
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.
What do you think?
I predict the developers will say "write a wrapper script around svn
that runs 'svnversion' before doing 'svn up'".
--
But users will not now with glad cries glom on to a language that
gives them no more than what Scheme or Pascal gave them.
-- Guy Steele, http://www.sun.com/research/jtech/pubs/98-oopsla-growing.ps
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org