You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2002/04/26 13:07:19 UTC
update output idea
Hey, I just had a fleeting thought, wanted to see what folks think.
I've run this idea by kfogel and cmpilato, and they both like it.
More than once, an svn newbie has asked, "how do I find out what
version my working copy is at?"
The answer has always been, "well, there's no one magic way to know if
your working copy is all at one revision. you might have a
mixed-revision working copy, you just can't tell."
Usually, I also tell folks to run 'svn st -vn' at the top of their
tree. Generally every file in trunk/ will have the same working
revision number... and that's a pretty good guess. Most likely your
whole tree is at that revision.
So here's a new take on the situation: what if 'svn update' actually
printed a final feedback line, the way 'svn commit' does?
% svn update
Updated to revision 1788.
%
Then, after an update, you'd know exactly how recent you are (ignoring
your local mods), as opposed to using 'svn status' to hazard a guess.
It would be effortless to do this -- the update-editor already
receives a 'target revision' from the server right at the beginning of
the editor drive. Heck, checkouts would print the final line too,
since it's the same editor.
Anyone have objections? If not, I'll file it as a bite-sized task.
Or I'll just do it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea - some more options
Posted by Alexis Huxley <ah...@gmx.net>.
> > I'll add that we do plan to have --silent option at some point too,
> > don't we?
>
> Oh, we have it now. `svn whatever > /dev/null' :-)
Some other options to consider:
cat > ~/.svnrc <<EOF
--silent
EOF
svn whatever ...
or
export SVN=--silent
svn whatever ...
or
Instead of 'svn whatever > /dev/null' - how about instead
'svn whatever 2> /dev/null'?
That last option would be my choice; (a) it leaves stdout untainted and
the output therefore more script friendly while not deviating from
'philosophy' in the area scripts are generally interested in
(stdout) and (b) it requires no app-specific ways of shutting it up
(as do the first two suggestions above).
On further consideration, I agree that adherence to 'silence is
golden' would be an inconsistency sufficiently big to be a bad move.
But if it can take a step in that direction at no expense to users
(rather than scripts) then it makes SVN more integratable into scripts
and increases its possibilities, doesn't it?
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by cm...@collab.net.
Kevin Pilch-Bisson <ke...@pilch-bisson.net> writes:
> > Besides, the "silence is golden" argument is bogus here unless it's a
> > call to change the UI for all of Subversion. If that's not the case,
> > I'd argue that consistency across the UI is much more useful
> > attribute, and as has been pointed out already, this change is
> > consistent with the output of other Subversion subcommands.
> I'll add that we do plan to have --silent option at some point too,
> don't we?
Oh, we have it now. `svn whatever > /dev/null' :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Kevin Pilch-Bisson <ke...@pilch-bisson.net>.
On Fri, Apr 26, 2002 at 10:12:34AM -0500, cmpilato@collab.net wrote:
> Besides, the "silence is golden" argument is bogus here unless it's a
> call to change the UI for all of Subversion. If that's not the case,
> I'd argue that consistency across the UI is much more useful
> attribute, and as has been pointed out already, this change is
> consistent with the output of other Subversion subcommands.
I'll add that we do plan to have --silent option at some point too, don't we?
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Re: update output idea
Posted by cm...@collab.net.
Peter Davis <pe...@pdavis.cx> writes:
> Doesn't 'svn update' print out each file that it patches, adds, or deletes
> anyway? So really, considering how it behaves currently, it would look like:
>
> % svn update
> A ./foo
> M ./bar.txt
> Updated to revision 1788
> %
>
> So by your argument, 'svn update' should output nothing at all
> without a '-v'. Update is already a noisy command, so why not add a
> little more noise? Maybe noise is bad in Unix Philosophy, but on
> some level, none of this is noise -- it's useful information that
> the user *needs* to see with or without a '-v'. '-v' should be
> reserved for debugging-type information; useful information should
> be output regardless.
I hear ya. There is no way I'd ever run update without all its output
silenced. I use the output of update to know whether I need to re-run
gen-make.py (if new source files were added, or some deleted), whether
or not someone is working in code that's "close" to what I'm working
on (The "merged" status, or worse, a "conflict"). I mean, we're
talking about changing the contents of my disk without any
foreknowledge of what those contents will be -- by golly you better
believe I want to watch what's going on!
Besides, the "silence is golden" argument is bogus here unless it's a
call to change the UI for all of Subversion. If that's not the case,
I'd argue that consistency across the UI is much more useful
attribute, and as has been pointed out already, this change is
consistent with the output of other Subversion subcommands.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
+1 on printing out the new revision at the end of the update; it's
useful information, and symmetrical with "svn commit"'s output.
Peter Davis <pe...@pdavis.cx> writes:
> This would be a very useful and convenient addition, and I can't see how it
> would hurt anything unless there are scripts that try and parse the
> output of
> 'A ./foo', etc.; such a script is too hackish to survive anyway.
If there are not such scripts, there soon will be (there are a great
many for CVS), and they would have no trouble adjusting for such a
trivial change.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Michael Wood <mw...@its.uct.ac.za> writes:
> > update since 1789. I might run an update and none of these files
> > would change, but all the 1798's would change to 1798's.
> ^^^^ ^^^^
> Perhaps you should have used a different example ;)
Hee hee! And I thought I was being careful, too, sigh... :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Karl Fogel <kf...@newton.ch.collab.net> writes:
> "svn st -v" output tells you both the highest revision number the
> local file has seen, and the revision in which the file last changed.
> It does *not* tell you the current head of the repository (you seem to
> think it does, but you have to add the "-u" flag for that). So if one
> understands the output of "svn st -v", one will not be confused.
By the way, didn't mean that to sound as harsh as it came out, Mark.
I just wasn't sure if you were misunderstanding "svn st -v", or if I
was misunderstanding your mail.
Anyway, in "svn st -v", the numbers on the individual file lines
always refer to something about that file, not something about the
repository. But if you add the "-u" flag, then (among other things)
at the end the status output it shows you the repository head
revision. Here's a real life example, somewhat abbreviated:
floss$ svn st -nvu
__ 1789 1789 kfogel .
_ 1789 1259 jerenkra ./BUGS
_ 1789 1784 sussman ./CHANGES
_ 1789 1600 kfogel ./COMMITTERS
_ 1789 1219 kfogel ./COPYING
__ 1789 1753 kfogel ./HACKING
_ 1789 1 svn ./IDEAS
__ 1789 1780 striker ./INSTALL
_ 1789 1738 jerenkra ./Makefile.in
_ 1789 1319 kfogel ./PORTING
__ 1789 1363 sussman ./README
_ 1789 1669 kfogel ./autogen.sh
_ 1789 1777 cmpilato ./build.conf
_ 1789 1738 jerenkra ./configure.in
Head revision: 1798
Head is 1798, but (as you can see) it looks like I haven't done an
update since 1789. I might run an update and none of these files
would change, but all the 1798's would change to 1798's.
Hope that helps,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Mark <cm...@yahoo.com> writes:
> I don't know what the user can do with that info, a 'svn log -r1788 foo
> bar.txt' may likely not return anything if they where not involved in commit
> 1788.
>
> I don't know, I guess most on the list thought it was a good idea, I must be
> missing something. I am still trying to get used to a "svn st -vn" on a file
> telling me the the repository revision is 1796 but the file in my workarea is
> 1741, but it is up-to-date.
"svn st -v" output tells you both the highest revision number the
local file has seen, and the revision in which the file last changed.
It does *not* tell you the current head of the repository (you seem to
think it does, but you have to add the "-u" flag for that). So if one
understands the output of "svn st -v", one will not be confused.
The point of that extra line at the end is to tell you how far along
in the repository history you are. That way if you're looking at some
other source of information (say, browsing recent commits in the
repository, or seeing that a bug was committed in revision X), you can
remember that your tree is already past revision X, so you know you
got the fix.
It doesn't answer all questions, it's just a piece of information
that's useful in some circumstances, and costs little to give (one
line of vertical space is relatively cheap).
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Mark <cm...@yahoo.com>.
--- Peter Davis <pe...@pdavis.cx> wrote:
> On Friday 26 April 2002 06:16, Alexis Huxley wrote:
> > > % svn update
> > > Updated to revision 1788.
> > > %
> % svn update
> A ./foo
> M ./bar.txt
> Updated to revision 1788
> %
I think this might be confusing to users. What is the user hasn't updated for
12 commits, and the user is only updating a portion of the workarea that he/she
is working on. So, if the last time that foo was updated was commit 1781 and
bar.txt last commit was commit 1779, what does the notice of the lasted commit
revision of 1788 tell the user the files wher updated to that revision.
I don't know what the user can do with that info, a 'svn log -r1788 foo
bar.txt' may likely not return anything if they where not involved in commit
1788.
I don't know, I guess most on the list thought it was a good idea, I must be
missing something. I am still trying to get used to a "svn st -vn" on a file
telling me the the repository revision is 1796 but the file in my workarea is
1741, but it is up-to-date.
Mark
__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Peter Davis <pe...@pdavis.cx>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Friday 26 April 2002 06:16, Alexis Huxley wrote:
> > % svn update
> > Updated to revision 1788.
> > %
>
> I thought the Nth tenet of The Unix Philisophy was "Silence is golden",
> ok, I mean I know a lot of svn commands are not, but ..
>
> I really only want to see output if (a) I specifically request it
> with a '-v' or (b) there is an error.
Doesn't 'svn update' print out each file that it patches, adds, or deletes
anyway? So really, considering how it behaves currently, it would look like:
% svn update
A ./foo
M ./bar.txt
Updated to revision 1788
%
So by your argument, 'svn update' should output nothing at all without a '-v'.
Update is already a noisy command, so why not add a little more noise? Maybe
noise is bad in Unix Philosophy, but on some level, none of this is noise --
it's useful information that the user *needs* to see with or without a '-v'.
'-v' should be reserved for debugging-type information; useful information
should be output regardless.
This would be a very useful and convenient addition, and I can't see how it
would hurt anything unless there are scripts that try and parse the output of
'A ./foo', etc.; such a script is too hackish to survive anyway.
- --
Peter Davis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8yVczNSZCJx7tYycRAoUNAJsGQo2d54yXuJ8tKfGWB6vVjZzl3wCdGLHp
Z44OnkEm54CS2l5Bg0Ha4Mw=
=QrD0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Alexis Huxley <ah...@gmx.net>.
> % svn update
> Updated to revision 1788.
> %
I thought the Nth tenet of The Unix Philisophy was "Silence is golden",
ok, I mean I know a lot of svn commands are not, but ..
I really only want to see output if (a) I specifically request it
with a '-v' or (b) there is an error.
My 2 eurocents ..
Alexis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Ben Collins-Sussman <su...@collab.net>.
Michael Wood <mw...@its.uct.ac.za> writes:
> How about making "svn status" give you that information? :)
>
Meaning, 'svn status' prints a line that tells you whether you have a
mixed-revision working copy, or a working copy all at one revision?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Michael Wood <mw...@its.uct.ac.za>.
On Fri, Apr 26, 2002 at 08:07:19AM -0500, Ben Collins-Sussman wrote:
[snip]
> So here's a new take on the situation: what if 'svn update'
> actually printed a final feedback line, the way 'svn commit'
> does?
>
> % svn update
> Updated to revision 1788.
> %
>
> Then, after an update, you'd know exactly how recent you are
> (ignoring your local mods), as opposed to using 'svn status'
> to hazard a guess.
[snip]
How about making "svn status" give you that information? :)
--
Michael Wood <mw...@its.uct.ac.za>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2002-04-26 at 19:00, Karl Fogel wrote:
> Or just indent, with spaces or some other char:
>
> U foo.c
> U bar.c
> U baz.c
> U qux.c
> --- Updated to revision 1788.
Another option, more consistent if arguably less pretty, is to designate
a character for informational messages:
U foo.c
U bar.c
U baz.c
# Working directory updated to revision 1788.
I'm not sure what the character should be; 'I' (information) is CVS for
"Ignored because it's a symlink", I think. 'M' (message) is of course
"modified." Some punctuation symbol like "+" or "*" or "#" could work;
each has vague precedent, I think.
Just a thought.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Karl Fogel <kf...@newton.ch.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> I'm all right with this, except for the phrase. Specifically, I want to be
> able to determine what each line is, based on the first character. The 'U'
> conflicts with an update for a single file.
>
> Could maybe say: Now at revision 1788.
Or just indent, with spaces or some other char:
U foo.c
U bar.c
U baz.c
U qux.c
--- Updated to revision 1788.
(I think the "updated to xxx" phrasing is the most natural, so would
like to keep it, if we can have our cake and eat it too.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Apr 26, 2002 at 08:07:19AM -0500, Ben Collins-Sussman wrote:
>...
> So here's a new take on the situation: what if 'svn update' actually
> printed a final feedback line, the way 'svn commit' does?
>
> % svn update
> Updated to revision 1788.
> %
I'm all right with this, except for the phrase. Specifically, I want to be
able to determine what each line is, based on the first character. The 'U'
conflicts with an update for a single file.
Could maybe say: Now at revision 1788.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Ben Collins-Sussman <su...@collab.net>.
Daniel Stenberg <da...@haxx.se> writes:
> On 26 Apr 2002, Ben Collins-Sussman wrote:
>
> > So here's a new take on the situation: what if 'svn update' actually
> > printed a final feedback line, the way 'svn commit' does?
> >
> > % svn update
> > Updated to revision 1788.
>
> I think that could be useful.
>
> I take it that if nothing is updated, it'll be quiet?
If your entire tree was already at HEAD, it'll be quiet.
If your tree still required revision bumping (but no patching), it
would print the new revision.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: update output idea
Posted by Daniel Stenberg <da...@haxx.se>.
On 26 Apr 2002, Ben Collins-Sussman wrote:
> So here's a new take on the situation: what if 'svn update' actually
> printed a final feedback line, the way 'svn commit' does?
>
> % svn update
> Updated to revision 1788.
I think that could be useful.
I take it that if nothing is updated, it'll be quiet?
--
Daniel Stenberg - http://daniel.haxx.se - +46-705-44 31 77
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org