Mark Phippard wrote:
> On Wed, Nov 26, 2008 at 2:11 PM, Branko Čibej <brane_at_xbc.nu> wrote:
>
>> I already posted an example of an IMHO wrong default for the URL_at_HEAD
>> case. Now here's one for the WC_at_BASE case:
>>
>> svn log
>>
>> This doesn't show commits newer than the BASE of the current directory
>> -- *even* if the latest commit was yours but happened not to bump thad
>> directory's BASE. Now if that isn't an unexpected default, I don't know
>> what is.
>>
>
> In this case, you are confusing the peg and operative revisions. The
> peg revision does not control what revisions that log returns, it
> instead canonically defines the path whose history you want to see.
> For the WC, I do not think there is ever a scenario where BASE would
> not be right.
>
Yes I did confuse those two; sorry. Could be that this peg rev confusion
confuses me too much. If I were closer to the code, I'd likely have
counter-arguments at the tip of my tougue.
> I think the problem with your HEAD argument is that you are still
> basing it on your assumptions from a given scenario. You give this
> example:
>
>
>> For example, take the example of "svn ls"; I expect this:
>>
>> svn ls -r12 svn://example.com/frob
>>
>> to be equivalent to this:
>>
>> svn ls -r12 svn://example.com/frob_at_12
>>
>
> To me that really does not make sense. For this to even be an issue
> you have to be saying that the path svn://example.com/frob either does
> not exist at all in HEAD or at a different location. OK, that is
> pretty common. But which let's say it has been renamed. Are you more
> likely to know the name and location where it existed at r12 or at
> HEAD? It is typically a lot easier to know about HEAD than some past
> revision.
>
I don't buy that. The most common use of "svn ls -r" and "svn co -r" has
been to get at code from obsolete and now-deleted branches. Your second
argument about renames doesn't fit either; yes, you may know that some
ancient thing was renamed, but it's a lot more likely that you *don't*
and happen to know the old name, or know it was renamed but aren't sure
of the new name. The @HEAD default only makes sense if you know just the
new name and not the old one. From my experience, based on the
vocabulary if interesting new phrases I've learned over the years from
people trying use those commands, I'd say that last it by far the least
common use case.
(The usual way to get both URL and REV are to do an svn log -v, find the
set of commits you're looking for, and copy rev and path from there,
never caring about later deletions or renames or whatnot.)
> There are always examples where each of the possible defaults makes
> more sense to a user. I think having a policy where the default is
> consistent and predictable is defensible and makes sense.
>
I challenge you on the "predictable" part from the point of view of the
common or garden user who's not acquainted with the code or the
intricacies of the peg-rev algorithm.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-26 20:32:05 CET