[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Untangling the peg revision knot

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Mon, 01 Dec 2008 09:50:12 -0500

C. Michael Pilato wrote:
> David Glasser wrote:
>> On Fri, Nov 28, 2008 at 1:21 AM, Greg Hudson <ghudson_at_mit.edu> wrote:
>>> On Thu, 2008-11-27 at 01:49 +0100, Branko Čibej wrote:
>>>> The proposals I'm making come from some years of observing otherwise
>>>> quite brilliant programmers breaking their heads against SVN and peg
>>>> revisions. They're not necessarily a personal preference. This is not
>>>> about my opinion vs. yours, it's about things I've observed vs. the
>>>> current status quo.
>>> Having read the whole conversation, I have the following observations:
>>>
>>> * The usability issue seems to be especially relevant to legacy users
>>> who are used to saying "svn cmd -r REV URL" when they want (in the
>>> current usage model) "svn cmd URL_at_REV". I sympathize, but if we change
>>> the default now, we'll just be creating pain for the people who used svn
>>> between peg rev introduction and now.
>> I think this is a key point: to spell it out differently, "people
>> should usually be using @REV to specify revisions, and only using -r
>> REV in special cases". I think most people (myself included) think
>> about it the other way around, but in our current implementation this
>> is generally the way to go.
>
> Yep. (See my previous self-deprecating comment about the naughty svnbook
> authors who never adapted our examples appropriately.)
>
> I'll file an svnbook issue *right now* for updating our examples to use peg
> revisions instead of operative revisions where the semantics demand it.

Done. http://code.google.com/p/svnbook/issues/detail?id=15

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-12-01 15:50:26 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.