Karl Fogel wrote:
> Nuutti Kotivuori <firstname.lastname@example.org> writes:
>> Actually I must disagree a bit on the way this is done.
>> The thing that is the important distinction, in my opinion, is that
>> did the revision number change or not. It's confusing to see
>> "Updated to revision N" when the revision was the same as before -
>> but it's not as confusing to see that when the revision _was_
>> changed, just that there were no changes.
>> So I vote for either three messages - update with changes, update
>> without changes and update but no new revision - or that the
>> different messages comes only in the case where there is no new
> I don't agree, quite.
> The important thing is that the user know what revision they are at
> after the update. Given that no actual changes were received, why
> is it useful to know whether the working copy was at some other
> revision(s) *before* the update? That revision mixture is gone
> forever, the update is done, so who cares? The important thing is
> that you are now at revision X.
Well, atleast I, with my current way of working, am stressing to
remember the last revision number and am comparing the new revision
number against that in my mind to see if it changed.
It might be just a remnant from cvs days, but I run 'svn up' quite
often. I should probably be running 'svn st -u' instead - but actually
that does not give me the information that I want either, though 'svn
st -v existing_file' does. Um, let me explain.
The single piece of information that I quite often wish to obtain is
that "Are there any newer revisions in the repository than my current
working copy?" If the answer to that is yes, then I usually do want to
atleast see what those new revisions were by checking the log
messages, even though they might have not been relevant - and if they
were relevant, I want to do an update at the top of the tree. And I
want to do this checking just about anywhere in my working copy.
Right now I just type 'svn up' at random places in my working copy and
hope I remember the last revision so I can do a global one if needed.
> By saying "At" instead of "Updating" in that circumstance, the
> output is deliberately uninformative on the question of whether any
> revisions changed to get to X. This is more accurate than the old
> output; instead of claiming that something changed when maybe
> nothing changed, it just doesn't say either way.
The output wording has been well picked indeed.
> If you want the output to distinguish between all three
> possibilities, go for it. Personally, it doesn't seem that
> important to me, so I'm not planning to write the patch myself...
Actually, I'm not so sure as to what I really want - maybe I need to
go into that further before I do anything. If the above case is
solved, then it's just a gut feeling that I want to be notified when
something changes even in the svn internals in the working copy - as
opposed to a real no-op which happens when there were no new
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue May 7 23:50:33 2002